These are chat archives for symengine/symengine

20th
Jul 2016
Srajan Garg
@srajangarg
Jul 20 2016 05:44
There is no support for Integration and ODEs yet
@isuruf Can you have a look at the top of the Pow visit of the ExpandVisitor. There we have conditions for each of the symengine polynomials (that if the exponent is a +ve integer, and base is a polynomial, then call pow_upoly)
Is there an easier way to do this in general for all polynomial types?
assuming pow_upoly is overloaded for all of them
something like is_templatized_from<UPolyBase>
or do I need to make some sort of is_Poly function, just like how it is implemented for NUmbers
Srajan Garg
@srajangarg
Jul 20 2016 05:50
@certik cotire uses MIT License, so we can use it without any documentation/written dependancy changes?
How exactly do I include it in on a 'legal' basis?
Isuru Fernando
@isuruf
Jul 20 2016 14:48
@coder0xff, Teuchos is not needed, unless you are compiling in Debug mode. There is a thin class (RCP) implemented in SymEngine that is compatible with Teuchos, but does no checks.
@spencerlyon2, I think you need to add a convert(::Type{Basic}, x::string) and it should work
Brent Lewis
@coder0xff
Jul 20 2016 14:51
What is special about debug mode? I ask because I'd like to migrate to the C++11 standardized pointers if all else is equal.
Spencer Lyon
@sglyon
Jul 20 2016 14:52
@isuruf thanks for the tip — I actually have everything hooked up on SymEngine.jl side, I’m just working through some incompatibility in how Julia expressions are represented as strings and what symengine accepts.
I think I will either have to change parts of the string representation of Julia Exprs or the semantics of basic_parse
Isuru Fernando
@isuruf
Jul 20 2016 14:53
Ah, just the usual debug flags, we use teuchos by default in debug mode. We can use C++11 shared_ptrs, few minor changes should make it able to switch to C++11 shared_ptrs at compile time
@spencerlyon2, what kind of strings are not parseable?
Spencer Lyon
@sglyon
Jul 20 2016 14:54
If you do this in Julia string(:(1*foo)) you will get back the string ”1foo”. Here symengine tokenizes 1foo to be a symbol, rather than 1*foo
Also this is valid In julia ex = :(foo * -bar) (string form “foo * -bar”), here symengine complains about multiple operators in a row.
Isuru Fernando
@isuruf
Jul 20 2016 14:56
Second one should be valid. I guess it is a bug
Spencer Lyon
@sglyon
Jul 20 2016 14:56
Oh ok good to know
Isuru Fernando
@isuruf
Jul 20 2016 14:56
For the first one, my first solution given in the issue should work
Spencer Lyon
@sglyon
Jul 20 2016 14:57
which issue?
Spencer Lyon
@sglyon
Jul 20 2016 14:58
hmm
Isuru Fernando
@isuruf
Jul 20 2016 14:58
Few minor tweaks to figure out if a Julia Symbol is actually a variable symbol can remove the need for the Dict
Got to go now. About to board a flight back home
Spencer Lyon
@sglyon
Jul 20 2016 14:59
Ok. I was going to comment that it seems like using the Dict probably won’t be too efficient.
Ok no problem. I actually already have two fixes for that first problem.
One is only helpful to my application and the other just changes the behavior of the Julia printer so :(1*foo) is printed as "1*foo”
Brent Lewis
@coder0xff
Jul 20 2016 15:39
I may be spending a lot of time in this chat, so I should introduce myself and my purpose. My name's Brent. I'm working on creating a programming language http://plange.tech . After considering many CASes, my intent is to use symengine within the implementation of the plange compiler to achieve generalized constraint solving, such as identifying and solving ODEs (examples on the home page). I'm working in C++, and I plan to port everything I need from python into C++. Will this work be useful in upstream symengine, or are only select things planned to move from python to c++? I ask because upstream adoption would clearly be beneficial for me in terms of peer review/testing/etc.
Isuru Fernando
@isuruf
Jul 20 2016 15:47
Hi, Brent, we would be happy to have ODE support in symengine
Regarding porting python to C++, we've been porting stuff that is slow in Python, but if a user wants to use it in C++ or C or Ruby or Julia we will have to port it eventually. We'll be happy to review and merge work on ODEs.
Brent Lewis
@coder0xff
Jul 20 2016 15:52
What about, say, integration or inequalities? Is there any functionality that must not be ported to c++?