Hi @irislq , let us know if you need help setting up.

Hello @irislq , I have written up an overview: https://github.com/symengine/symengine/wiki/expression-series-expansion

Please feel free to add your plans so we have some coordination.

Please feel free to add your plans so we have some coordination.

@isuruf What do you think?

@rwst, looks good. All 3 starting points are good IMO. I added one as well

I just got an email from a Piranha user that did some celestial mechanics computations that resulted in series with up to 8 million terms

The Flint series PR is in: #780. Do we have Flint on Travis?

@rwst, yes. Test 6

can I work on a

`RealDouble`

to `Rational`

function?
Yes

@srajangarg No way can you convert that. The first has finite precision, the second is exact.

But for that PR, I think @isuruf meant you can take in

`double`

as `RealDouble`

when someone wants to represent say

`1.665`

, how is it currently done?
it can always be represented as

`1665/1000`

(or a simplification), right?
As 53-bit integer. E.g. is

`0.5`

actually `0.50000000000000000001`

but our 53 bit don't show all of it? You cannot know this if you only get the 53 bit.
Either,

`RealDouble(1.665)`

or `Rational(1665, 1000)`

Shouldn't Rational be defacto? as it's exact?

It'S NOT!

@srajangarg, but how do you know that

`1.665`

is exact
I'm confused. What if a user wanted exactly this number?

well technically a floating-point number is represented as a fraction internally

he should input the rational, as all CAS do

and we are never dealing with irrational numbers, so shouldnt everything be representable in

`Rational`

?
Then the user has to give

`1665/1000`

We do deal with irrational numbers like

`sqrt(2)`

`"1.665"`

as a string should work too :)
what I wanted to suggest is, if the user wants to store a number, (which he's specifying through a string) it should be

`Rational`

. (as it will have finite digits)
and not as a

`RealDouble`

(which sort of messes up the precision)
@bluescarni Why, it only shows you have an inexact number. Tell me, if you allow this, how would you input the inexact

`1.665`

?
@srajangarg You will surprise the user, and users don't want to be surprised.

sorry I was being facetious :) rational would be best of course

Haha is that the real reason? :p

I'm still confused

@srajangarg Tell me, if you allow this, how would you input the inexact 1.665?

just pointing out that

`Rational(0.5)`

is different from `Rational("0.5")`

@srajangarg, for example, user can either give

`x/2`

or `0.5*x`

. These two are fundamentally two different things. First means `x`

divided by two. Other is `x`

times a an inexact number, which implies whole thing is inexact
Why would you ever want the inexact 1.665?

for numerics

it can be converted into it's 'comparable' form whenever it is to be evaluated, no?

No, you lose the precision information.

@isuruf that makes things a little clear, but I'm not able to think of a scenario where a user would do that

@srajangarg, having symbolics where numerics are needed is costly and unnecessary. For example,

`(sqrt(0.5)+2)**3.3`

as it is, is not really needed. you only want the numeric value
Agreed

Oh so does

`Add`

in `RealDouble`

simplify on it's own?
I was not aware of this :)

@Sumith1896, if you do

`(sqrt(0.5)+2)**3.3`

in symengine, it should give the computed value
Yes. Makes sense.

@srajangarg I hope this clears up stuff

I have not had a detailed look at #772 but could you convert

`^`

to `**`

?
Let's keep it uniform

Okay, will do that

It's not going to be easy, as the whole thing was written assuming operators are 1 character

plus this coincides with multiplication character

will have a look

@isuruf views?

@isuruf @certik Few days ago I got it clarified with Sameer that symengine can now be installed with

`gem install`

and the notebook PR can be merged. In the same PR I suggested that the same line in `gems.yml`

should be changed. I will inquire again.
Do we go for

`^`

or `**`

? I'm fine either ways.
Well, I can get it done with

`**`

as I'm anyways converting the user supplied string to the one which will be parsed
@Sumith1896, I think we should have both.

`**`

is needed, because if the user prints an expression and later wants to pass that, he/she can't because `pow(a, b)`

was printed as `a**b`

I'll just replace all instances of

`**`

with `^`

So it's chill

Yes, both will be good

@srajangarg, one other detail is if you will support doubles in scientific notation

Haven't thought about it yet

I still havent worked out doubles (in decimal format) yet too

Those two are the last pieces I think

@abinashmeher999, I wasn't aware of the PR. Looks good

I just sent another PR to fix that line in

`gems.yml`

. SciRuby/sciruby#46