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.)

See, https://github.com/isuruf/symengine/tree/series

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.
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?
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