These are chat archives for symengine/symengine

30th
Jun 2014
Ondřej Čertík
@certik
Jun 30 2014 01:54
@isuruf, as Thilina said, I would follow the same API as primesieve for things that we want to implement ourselves. I think just a basic implementation is enough, and I would use primesieve as the recommended library for high performance.
Ondřej Čertík
@certik
Jun 30 2014 02:48
@thilinarmtb good point. So the question is how to simplify 2*2^(-1/2) to 2^(1/2)?
Sushant Hiray
@sushant-hiray
Jun 30 2014 02:49
I'm just looking into why this issue did not come up earlier
ok @thilinarmtb so the thing is, if you first insert {2, 1}
then while inserting {2, -1/2} it would merge with the {2, 1} automatically
as they will have the same hash.
Earlier while fixing a similar problem I tried using a for loop at the end, but it deteriorates the performance. So you should just stick too into inserting everything first and then simplifying the coef_
Ondřej Čertík
@certik
Jun 30 2014 02:52
I see, so the thing is that in the master, we do {2: 1} + {2: -1/2}, which simplifies to {2: 1/2}, which is what we want as that is sqrt(2). In your PR, the {2: 1} gets taken out immediately to the coef, and then {2: -1/2} is left in the dictionary, so the result remains as 2*2^(-1/2).
But what about 8*2^(-1/2), that's not going to simplify even in master.
So our master is not doing a full simplification either.
Sushant Hiray
@sushant-hiray
Jun 30 2014 02:53
True
we will have to draw a line on how much to simplify
If we consider simplifying stuff like 8*2^-1/2, it will boil down to finding the primefactors and then inserting them accordingly, which is pretty much costly by default
Ondřej Čertík
@certik
Jun 30 2014 02:56
Exactly. Given the fact, that we do not factor automatically currently for all cases, the 2/sqrt(2) just happens to work by accident, I think we should simply go ahead and finish @thilinarmtb's PR, and just modify the sec test
That way, at least csympy works for all cases correctly.
Then the big question is how to efficiently implement factorization of square roots and similar
and whether to do it automatically or not.
Sushant Hiray
@sushant-hiray
Jun 30 2014 02:57
Yes, I will send a follow up PR once Thilina's PR is merged
Ondřej Čertík
@certik
Jun 30 2014 02:58
The algorithm is the following --- factor the coef (costly) and combine with numeric factors in the dictionary.
so 8 - > 2^3 and this gets combined with 2^(-1/2)
Then other things are sqrt(2)*sqrt(8)
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:00
Ideally this is expected, so in SymPy is it done this way?
Ondřej Čertík
@certik
Jun 30 2014 03:00
sympy does this automatically
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:01
so essentially it boils down to the fact that if we are inserting a number into dict, just factor it and insert
then all cases should be handled
Ondřej Čertík
@certik
Jun 30 2014 03:01
@sushant-hiray exactly! Just got the same idea
What about rationals?
And complex numbers?
Also, one needs to then extract the final number from a dictionary
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:02
For rationals I guess insert the num and den separately
then they can be handled as integers itself
Ondřej Čertík
@certik
Jun 30 2014 03:04
Right
I still think that one should not factorize, unless there are some fractional powers in the dictionary
otherwise it's just a waste of time to factorize and multiply together
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:07
so one way to go forward is too do what thilina is doing, once the dict is made completely, check for fractional powers with numbers, if they exist then just insert the prime factors of the coef
Ondřej Čertík
@certik
Jun 30 2014 03:07
How about a different approach: when you put in 1/sqrt(2), then before putting it in, write it always as 1/2 * sqrt(2), then insert 1/2, and sqrt(2) separately. so 1/2 goes into coef, and sqrt(2) stays in the dictionary
In other words, maybe the rule is --- never put any negative powers (of integers/rationals) into the dictionary?

This seems to be what Sage is doing, e.g. consider:

sage: sqrt(3)/sqrt(15)
1/15*sqrt(15)*sqrt(3)

while in SymPy, that gets simplified:

>>> sqrt(3)/sqrt(15)
sqrt(5)/5

Which means, that SymPy is doing more, but Sage is doing less, probably for efficiency reasons.

Ondřej Čertík
@certik
Jun 30 2014 03:13
So unless I am mistaken, the rule in Sage/GiNaC seems to be: convert negative fractional powers of integers/rationals to positive powers, collect numbers and leave the positive fractional powers in the dictionary, do not attempt to combine or factor.
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:13
Yes that seems to be the case
Ondřej Čertík
@certik
Jun 30 2014 03:23
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:26
nice! Lets see what they have to say
Ondřej Čertík
@certik
Jun 30 2014 03:26
Have to go to bed. Thanks @sushant-hiray for feedback about this. This is very important to get right, and so far I am leaning to do what Sage is doing, i.e. never any automatic factorization (which is slow). In other words, do what one can to obtain reasonably simplified results quickly, and for the rest, the user needs to call a function
Sushant Hiray
@sushant-hiray
Jun 30 2014 03:28
Sure! I'll open up an issue and summarize the discussion there. We can then decide what steps to take.
Thilina Rathnayake
@thilinarmtb
Jun 30 2014 08:29
@certik , @sushant-hiray : Sorry, I couldn't take part in the discussion. I guess the approach of not keeping negative powers in the dict_ is good. I'll update the PR to do that.
Sushant Hiray
@sushant-hiray
Jun 30 2014 08:50
Sure we can do that for now. Once you are done, I'll update the trignometric tests. You can just comment which ever of them are failing
Sushant Hiray
@sushant-hiray
Jun 30 2014 09:50
I just opened #224 summarizing the discussion.