These are chat archives for symengine/symengine

Oct 2015
Ralf Stephan
Oct 30 2015 07:41

@isuruf : Is there a specific reason that printing Basics is done in printer.cpp instead of the specific classes? Doesn't this break encapsulation? In Pynac there is this idiom, e.g.:

void symbol::do_print(const print_context & c, unsigned level) const  
        c.s << name;


void symbol::do_print_latex(const print_latex & c, unsigned level) const;
...etc. also do_print_tree(...), do_print_python_repr(...)


/** Base class for print_contexts. */
class print_context
        GINAC_DECLARE_PRINT_CONTEXT(print_context, void)
        print_context(std::ostream &, unsigned options = 0);
        virtual ~print_context() {}

        std::ostream & s; /**< stream to output to */
        unsigned options; /**< option flags */
Ondřej Čertík
Oct 30 2015 14:15
@rwst we follow the same design as in SymPy. Essentially the idea is to decouple algorithms (printing, numerical evaluation, ...) from the classes. That way, you can have as many printing solutions as you want. If, on the other hand, you implement these algorithms as methods on these classes, then you can't really create a different printer, i.e. if let's say you prefer to print ^ instead of **, you need to modify/extend the classes themselves. At some point, you have to stop adding things to the classes, since there is almost infinite amount of algorithms that you can do on the symbolic tree.
Ralf Stephan
Oct 30 2015 14:19
@certik , Thanks, it shows that I did near exclusively Sage for the last two years.
Björn Dahlgren
Oct 30 2015 14:37
@isuruf @certik what are the plans regarding the conda recipes, should we split them into two recipies: libsymengine and and have the latter depend on the former?
Isuru Fernando
Oct 30 2015 16:22
@bjodah, yes, we should have separate recipes. What should be the names for the two packages? symengine and python-symengine?
Björn Dahlgren
Oct 30 2015 16:26
sounds good to me :+1: - explicit :)
Ondřej Čertík
Oct 30 2015 18:02
@bjodah, @isuruf I agree about conda.
@rwst I think Sage must have the same issue. I think it's just how to best design the software so that one can easily add symbolic algorithms/functionality, without touching too many things in the core.
Ralf Stephan
Oct 30 2015 20:01
@certik , Sage's core is its abstract algebra (categories) and the coercion system, but printing of objects is done exclusively from what the object's __repr__ methods return. I'm not convinced this should be outside the object's class.