These are chat archives for symengine/symengine

22nd
Dec 2015
Isuru Fernando
@isuruf
Dec 22 2015 09:14

@rwst, @certik, I'm working on a generic series expansion class using templates. It's almost done. Idea is that you only define a few operations for series like multiply polynomials with a max degree, get coef, etc. Other methods like series_sin would be defined using these basic operations.

I've subclassed it for piranha with pp_t as the container and works fine. (i.e. it can be replaced for series method right now). For a series expansion using Expression, all I need now is a ExprPolynomial with some basic functionality. (or Expression can be used as the container after adding an integrate method.)

Ralf Stephan
@rwst
Dec 22 2015 09:38
@isuruf That's great. I do not have much experience with templates so cannot make founded criticism.
Isuru Fernando
@isuruf
Dec 22 2015 09:47
@rwst, I went through your code extensively and I have some questions.
1. `series_reverse`, this method is not used. Are you planning to use it in the future?
2. Laurent series, what needs to be done here? I don't have much experience with it. How do you represent `e^(1/x)`?
3. `series_nthroot`, if `ldegree` is divisible by n, then this is possible right?
Ralf Stephan
@rwst
Dec 22 2015 10:05
@isuruf 1. It is used in `series_invfunc` for user convenience, no plans. 2. I haven't thought about this. Offhand it depends on the order term, i.e. `1/(x^5-x^6)` gets ordered normally and f(1/x) the reverse, 3. no the coeff of the lowest degree term, depending on which ring the coeffs are in, i.e. for reals the coeff must have a real root, for rationals a rational root.
Isuru Fernando
@isuruf
Dec 22 2015 10:20
Ah, I didn't see the usage at `series_invfunc`. For `series_nthroot`, for rationals, if there is a rational root, and if `ldegree` is divisible by `n`, then this is possible. Current implementation requires a non-zero constant term.
Isuru Fernando
@isuruf
Dec 22 2015 11:56
@rwst, for eg. 3rd root of `(27x^3+x^4+O(x^5))`
Francesco Biscani
@bluescarni
Dec 22 2015 13:13
@isuruf nice job! Just FYI, for design considerations you might be interested in this: https://github.com/darioizzo/audi It's an automatic differentiation library based on Piranha. The reason I am mentioning it is that it uses a different approach for the truncation: rather than setting a global variable (i.e., via Piranha's truncation mechanism), it embeds the truncation limit within the series object, so it avoids some of the problematic aspects of having a global state. In other words, each series carries around with itself the truncation limits, which becomes a property of the object.
Isuru Fernando
@isuruf
Dec 22 2015 13:19
@bluescarni, yes that's the design. Basic operations like mul and pow can be defined by the subclass. In piranha subclass, for each operation, `set_auto_truncate_degree` is called.
Ralf Stephan
@rwst
Dec 22 2015 13:39
@isuruf Yes I meant the constant term must have such a root.
Isuru Fernando
@isuruf
Dec 22 2015 14:07
@rwst, when considering the constant term for eg. `sin(1+x**2)` should we use the above way in audi, i.e. `sin(x**2)*cos(1)+cos(x**2)*sin(1)` or just `2tan(t)/(tan^2(t)+1)` where `t` is `(1+x^2)/2`
Ralf Stephan
@rwst
Dec 22 2015 14:16
@isuruf `sin/cos(1)` are the basic reals that appear in the series. If there is a simpification that is significantly shorter then yes. However I'd rather that series code stays elementary and these simplification rewrites are done by a function called by the user.
Isuru Fernando
@isuruf
Dec 22 2015 14:33
@rwst, I didn't get you. You are saying not to let `tan` handle the constant term, but to use `sin(1)` and `cos(1)`?
Francesco Biscani
@bluescarni
Dec 22 2015 14:33
OT/fluff: ordered a raspberry PI 2 for xmas, looking forward to try Piranha on it :p
Isuru Fernando
@isuruf
Dec 22 2015 14:34
@bluescarni, did you try compiling Piranha with MSVC 15 update 1? I get `type_traits` check failures
Francesco Biscani
@bluescarni
Dec 22 2015 14:35
@isuruf no not yet. I need to get a Windows VM running, hopefully I'll have time to do it after Christmas. To be honest I am expecting it will still not work, as AFAIK MSVC still does not support fully expression SFINAE
Isuru Fernando
@isuruf
Dec 22 2015 14:38
Yes, there's only partial support.
Francesco Biscani
@bluescarni
Dec 22 2015 14:38
did you have a chance to try the MSVC clang support?
that might work
Isuru Fernando
@isuruf
Dec 22 2015 14:39
Is it there in update 1?
Francesco Biscani
@bluescarni
Dec 22 2015 14:40
Isuru Fernando
@isuruf
Dec 22 2015 14:41
Great. I'll try that. Btw, this is just the front end right, so that it is ABI compatible?
Francesco Biscani
@bluescarni
Dec 22 2015 14:42
that's my understanding, but I have no first-hand experience
it's possible that piranha's CMake macros get confused.. I have nothing specific in mind, but I never anticipated using clang on windows in the build system so there might be some bugs lurking there
Ralf Stephan
@rwst
Dec 22 2015 16:07
@isuruf Effectively, since `sin` of constant is not implemented (except in `rs_series`) there is no precedent and no plan. So please go ahead.
Ondřej Čertík
@certik
Dec 22 2015 17:03
@rwst, @thilinarmtb I gave you both push access to the symengine repositories. Thilina already had it, but I guess once we moved to the symengine org., he lost it. @rwst you can now merged reviewed PRs yourself.
@isuruf thanks for trying it in Mathematica. It looks like that once something returns `SeriesData`, then it acts like a number ---- any operation will get immediately converted to `SeriesData` and collected appropriately into just one `SeriesData`. I think that is a good design. it looks like your `series` branch allows that. Before we merge it, we should have at least 2 implementations, e.g. Piranha and let's say our Basic expressions. I think you almost have it.
Isuru Fernando
@isuruf
Dec 22 2015 17:08
In my branch, `sin(x) + sin(x).series(x, 10)` won't automatically evaluate `sin(x)` on the left
I'm working on Basic expressions, as it turns out there needs some more work to make it work with constant terms in functions like `sin`
All the work now has been to convert @rwst's work to something generic
Ondřej Čertík
@certik
Dec 22 2015 17:10
It's still the same problem with double dispatch --- how to dispatch + to our class if one of the operands is a series.
Isuru Fernando
@isuruf
Dec 22 2015 17:13
Hmm, if `series` was outside of `Basic` then it is easy to do, but when it is a `Basic` it requires more work as that scenario is not yet implemented and requires changes in core classes and methods
When working with `series` we don't need it as a `Basic` as it "absorbs" all the other types and converts them into `series`. This is not the case in `Polynomial` however
Ondřej Čertík
@certik
Dec 22 2015 17:21
Well, given that Series converts everything to Series, why not to have it outside of Basic? At least for now.
Ondřej Čertík
@certik
Dec 22 2015 17:30
The only reason to keep it as a subclass of Basic would be to represent things like (Series(...))^2 unexpanded. But since Mathematica expands everything, and it seems we agreed this is the way to go, then Series should be separate. And it would have a method to convert back to Basic, essentially the SymPy's `removeO()` would convert Series to Basic.
rijuldhir
@rijuldhir
Dec 22 2015 18:10
Hi,
Can i get some easy bugs to fix