These are chat archives for symengine/symengine

20th
May 2016
myluszczak
@myluszczak
May 20 2016 05:23
@shivamvats The second option has been implemented in PRs #924 and #913. The tests are running now.
Siddharth
@bollu
May 20 2016 07:35
The API is supposed to simplify e^(i * pi) to -1 right? Because I'm binding it to haskell through the C FFI, and this expression isn't getting simplified
i and e seem to work properly alone (as in, 1/i == -i, e ** 0 = 1 and things like that
Isuru Fernando
@isuruf
May 20 2016 07:35
No, that isn't implemented yet
Siddharth
@bollu
May 20 2016 07:36
oh, I see
where should I implement it in that case?
I mean, I'm interested in seeing this implemented anyway :)
also, symbol_set is used to create a new symbol, correct? Symbol in the sense of symbolic math symbol, right?
Isuru Fernando
@isuruf
May 20 2016 07:37
I'm not sure. We haven't had any simplification routines yet
@bollu, yes
Siddharth
@bollu
May 20 2016 07:37
hm, so usually, there is a separate layer for simplification?
I guess I'll see how Sympy does it in the first place?
and then try and use a similar design
Isuru Fernando
@isuruf
May 20 2016 07:38
Yes, SymPy does the simplification automatically
Siddharth
@bollu
May 20 2016 07:38
alright, I'll take a look at how they do it
Francesco Biscani
@bluescarni
May 20 2016 07:42
@srajangarg in general you want to mark as noexcept the methods involved with move semantics (move constructor and move assignment). This allows the compiler to generate more optimised code (e.g., when storing objects in a standard container)
Isuru Fernando
@isuruf
May 20 2016 07:44
Also destructor is also marked in most cases. (it's needed because of a gcc bug)
Francesco Biscani
@bluescarni
May 20 2016 08:02
yep it's automatically noexcept from 4.8 I think
Siddharth
@bollu
May 20 2016 08:09
also, the FFI does not catch a 0/0 error
well, the C++ layer
I'd like it if there was some way to check for this
because right now, sending a x / 0 situation to basic_div causes a crash
Isuru Fernando
@isuruf
May 20 2016 08:18
yes, exception handling is not there in cwrappers right now
@raijthv is going to add them this summer in his GSoC project
Siddharth
@bollu
May 20 2016 08:18
ah, alright
Isuru Fernando
@isuruf
May 20 2016 08:19
You can talk with him and coordinate it
Siddharth
@bollu
May 20 2016 08:19
I've bound the basic stuff now - I tried covering everything "relevant" though there is stuff dangling like some of the more exotic trig functions
Isuru Fernando
@isuruf
May 20 2016 08:38
Thanks. I'll look through the PR
I'm curious, does x + 1 work where x is a Symbol?
Siddharth
@bollu
May 20 2016 08:39
let me try
*Symengine Symengine> let x= symbol "x"
*Symengine Symengine> x + 1
1 + x
Yep, works
Isuru Fernando
@isuruf
May 20 2016 08:40
And 1 + x also right?
Siddharth
@bollu
May 20 2016 08:40
Symengine Symengine> let x = symbol "x" Symengine Symengine> 1 + x
1 + x
*Symengine Symengine> :t (1 + x)
(1 + x) :: BasicSym
*Symengine Symengine> let x = symbol "x"
*Symengine Symengine> 1 + x
1 + x
*Symengine Symengine> :t (1 + x)
(1 + x) :: BasicSym
yep, you can see that the type is correct
Isuru Fernando
@isuruf
May 20 2016 08:41
Great.
Siddharth
@bollu
May 20 2016 08:42
the reason it manages to pick the right type is because of the type constraints. It know that (+) works on Num, and it knows that BasicSym < Num. Hence. the right hand / left hand should also be BasicSym. It auto-converts using the fromInteger :: Int -> BasicSym
*Symengine Symengine> :t (+)
(+) :: Num a => a -> a -> a
*Symengine Symengine> :t (+ x)
(+ x) :: BasicSym -> BasicSym
*Symengine Symengine> :t (x +)
(x +) :: BasicSym -> BasicSym
Isuru Fernando
@isuruf
May 20 2016 08:42
One comment, you need to differentiate between 1/2 and 0.5. One is a Rational and the other is a RealDouble. @rajithv is supposed to wrap RealDouble, RealMPFR, ComplexDouble and ComplexMPC
Siddharth
@bollu
May 20 2016 08:42
You can see the type get specialised when I partially apply it
Isuru Fernando
@isuruf
May 20 2016 08:42
That's great
Siddharth
@bollu
May 20 2016 08:43
I see, I thought we always wanted Rational. So in that case, all Haskell-floats will become RealDouble, while explicitly constructed Rational will become rational? what about / operator? It yields a Rational I imagine
Isuru Fernando
@isuruf
May 20 2016 08:44
Does Haskell have arbitrary-precision floats or just machine precision ones?
Siddharth
@bollu
May 20 2016 08:45
it does have arbitrary precision in terms of Ratio AFAIK. It has both. Ratio is like Rational.
There is also a scientific package for this stuff
I'll probably want to look into neat interop with that and SymEngine
Isuru Fernando
@isuruf
May 20 2016 08:46
Right. Rational is a bit different from arbitrary precision floats.
Siddharth
@bollu
May 20 2016 08:47
Ratio / Rational is exact arithmetic with rational numbers, while arbitrary precision is "real" base-exponent with just an arbitrary number of bits for the mantissa, correct?
Isuru Fernando
@isuruf
May 20 2016 08:47
yes
Siddharth
@bollu
May 20 2016 08:48
yeah, so in that case, I think I will have to interop with scientific for RealDouble.
also, I think the FFI has not been written yet for matrices and polynomials?
I'll work on that this week
Isuru Fernando
@isuruf
May 20 2016 08:48
Nope
Siddharth
@bollu
May 20 2016 08:49
all right, I'll get to it
thanks for the feedback!
Isuru Fernando
@isuruf
May 20 2016 08:49
It uses MPFR library
RealDouble is the machine precision one. RealMPFR is the arbitrary precision one
Siddharth
@bollu
May 20 2016 08:49
The build seems to be passing - just 2 more travis machines to build on
Isuru Fernando
@isuruf
May 20 2016 08:49
Haskell also has wrappers for MPFR if I remember correctly
Siddharth
@bollu
May 20 2016 08:49
ah, alright. I'll keep that in mind. And yes, it probably does
however, I think scientific has a neater arbitrary precision API? I'll check it out and make an issue with the pros/cons on the issue tracker?
Isuru Fernando
@isuruf
May 20 2016 08:50
Yes, that'll be good
@bollu, for now everything is a BasicSym type right?
Siddharth
@bollu
May 20 2016 08:57
@isuruf yes
I plan on breaking up Complex if I can
but the problem is that sympy in general gives me no type info
so I need to constantly query the api for the type
I'm not a fan of the overhead
symEngine*
Isuru Fernando
@isuruf
May 20 2016 08:59
Right. You'll need to use basic_type everytime you call a ffi function
The only problem with everything having one type, is you can't add member functions specific to that one type
hash97
@hash97
May 20 2016 15:00
I want to contribute.How do I start?
Srajan Garg
@srajangarg
May 20 2016 16:29
@hash97 Go through the wiki in on the github repository. Then, look at some past issues/PRs to see how stuff works, and ask specific questions here, and try and solve the issues once you are comfortable with the library.
hash97
@hash97
May 20 2016 17:00
thank you @srajangarg .
Shivam Vats
@shivamvats
May 20 2016 19:21
@myluszczak Great!
@isuruf I had read about FFT a long time back. Will brush it up and let you know if I have some ideas.