@shivamvats The second option has been implemented in PRs #924 and #913. The tests are running now.

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
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?
I'm not sure. We haven't had any simplification routines yet

@bollu, yes

I guess I'll see how Sympy does it in the first place?

and then try and use a similar design

@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)
Also destructor is also marked in most cases. (it's needed because of a gcc bug)

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
yes, exception handling is not there in cwrappers right now

@raijthv is going to add them this summer in his GSoC project

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

I'm curious, does

`x + 1`

work where `x`

is a Symbol?
```
*Symengine Symengine> let x= symbol "x"
*Symengine Symengine> x + 1
1 + x
```

Yep, works

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

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
```

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`

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
Does Haskell have arbitrary-precision floats or just machine precision ones?

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

Right.

`Rational`

is a bit different from arbitrary precision floats.
`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?
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

thanks for the feedback!

`RealDouble`

is the machine precision one. `RealMPFR`

is the arbitrary precision one
The build seems to be passing - just 2 more travis machines to build on

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?

@bollu, for now everything is a BasicSym type right?

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*

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

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

@isuruf I had read about FFT a long time back. Will brush it up and let you know if I have some ideas.