These are chat archives for symengine/symengine

22nd
Jan 2016
Srajan Garg
@srajangarg
Jan 22 2016 09:39
should `sqrt(1+(1/x)^2)` be simplified to `sqrt(1+x^2)/abs(x)` or kept as is?
and similarly for `1/sqrt(1+(1/x)^2)` to `abs(x)/sqrt(1+x^2)`
Ralf Stephan
@rwst
Jan 22 2016 09:46
Above all, make it a root of a fraction first (`sqrt((x^2 + 1)/x^2)`). This is usually called normalization. Simplification is not a well defined concept.
Srajan Garg
@srajangarg
Jan 22 2016 10:09
I'll do that, but should I simplify `sqrt(x^2)` as `abs(x)` wherever occuring?
Sumith Kulal
@Sumith1896
Jan 22 2016 10:11
You mean directly?
Srajan Garg
@srajangarg
Jan 22 2016 10:11
or does `sqrt()` do that itself? or is it not a 'simpler' form altogether
Kalevi Suominen
@jksuom
Jan 22 2016 10:11
Will `x` always be real?
Srajan Garg
@srajangarg
Jan 22 2016 10:12
x is a `Basic`
can be anything
Sumith Kulal
@Sumith1896
Jan 22 2016 10:12
Then, we don't simplify
``````>>> from sympy import *
>>> x = symbols("x")
>>> sqrt(x**2)
sqrt(x**2)
>>> sin(x)
sin(x)
>>> sin(asin(x))
x``````
This might clear up.
Srajan Garg
@srajangarg
Jan 22 2016 10:16
cool
``````>>> sin(acos(x))
sqrt(-x**2 + 1)
>>> sec(acsc(x))
sec(acsc(x))
>>> sin(atan(x))
x/sqrt(x**2 + 1)
>>> sin(asec(x))
sin(asec(x))
>>> sin(acot(x))
1/(x*sqrt(1 + x**(-2)))
>>> cos(asec(x))
cos(asec(x))
>>> tan(asec(x))
tan(asec(x))``````
SymPy simplifies some, doesn't others? What's the deal?
Sumith Kulal
@Sumith1896
Jan 22 2016 10:24
Weird

I'm most surprised of

``````>>> cos(asec(x))
cos(asec(x))``````

this

Srajan Garg
@srajangarg
Jan 22 2016 10:34
while this works
``````>>> sec(acos(x))
1/x``````
I'll go ahead and simplify all of them for now?
Francesco Biscani
@bluescarni
Jan 22 2016 10:37
``````>>> sin(acos(x))
sqrt(-x**2 + 1)``````
This looks good with respect to the usual choices for branch cuts of `acos`
Srajan Garg
@srajangarg
Jan 22 2016 10:37
also to note sympy reports it as `sqrt(1 + x**(-2))`, whereas here we want it normalized? `sqrt((1 + x^2)/x^2)` Is that correct?
Sumith Kulal
@Sumith1896
Jan 22 2016 10:45
I'm not sure as to what to be done here
But by standard I don't think we take common denominator
We usually have methods
Give me a moment
Ah!
``````In [5]: sqrt(1+x**(-2))
Out[5]: sqrt(1 + x**(-2))

In [10]: together(_)
Out[10]: sqrt((x**2 + 1)/x**2)

In [11]: apart(_)
Out[11]: sqrt(1 + x**(-2))``````
SymPy behaves this way
Srajan Garg
@srajangarg
Jan 22 2016 11:00
So what should I do?
Ralf Stephan
@rwst
Jan 22 2016 13:44
You need not normalize. I just wanted to point out above that there are several steps to the result which the user wants to make explicitly. Sage will leave the expression as it is, too.
Francesco Biscani
@bluescarni
Jan 22 2016 13:45
@rwst so I have some basic polynomial GCD running in a prototype in Python
I am using the Subresultant Polynomial Remainder Sequence approach, keeping it simple for now :)
Ralf Stephan
@rwst
Jan 22 2016 13:46
@bluescarni Cool. So the understanding has improved.
Francesco Biscani
@bluescarni
Jan 22 2016 13:46
and instead of recursion for handling the multivariate case I am mapping multivariate polys to univariate via Kronecker substitution and doing the computations there
yes it's getting better
I think now at least I know the names of the basic algorithms :)
I think I'll go ahead and implement it soon, it's probably not optimal or anything like that, but as long as it works correctly it's a first step
apparently the best algorithm to use is highly dependent on the situation
this paper has some performance measurements: http://http.cs.berkeley.edu/~fateman/papers/phil8.ps
Ralf Stephan
@rwst
Jan 22 2016 13:49
Lots of possible parameters, sparseness/degree, no. of vars, I guess.
Francesco Biscani
@bluescarni
Jan 22 2016 13:49
yes sparseness concerns me most of all
as when you map multivariate to univariate the resulting polynomial can be highly sparse
and this potentially is quite bad for performance
I'll make a plain simple implementation first, test it out and see if makes sense to go for other approaches
but just having the thing working at this stage is enough
Ralf Stephan
@rwst
Jan 22 2016 13:51
+1
Francesco Biscani
@bluescarni
Jan 22 2016 13:56
here's the toy code just for reference https://gist.github.com/bluescarni/73f54ecde182df6be762
``````>>> from fractions import Fraction as F
>>> a = encode({(8,):F(1),(6,):F(1),(4,):F(-3),(3,):F(-3),(2,):F(8),(1,):F(2),(0,):F(-5)})
>>> b = encode({(6,):F(3),(4,):F(5),(2,):F(-4),(1,):F(-9),(0,):F(21)})
>>> gcdsspr(a,b)
{0: Fraction(260708, 1)}``````
Akash Trehan
@CodeMaxx
Jan 22 2016 14:10
@certik can you restart appveyor build for #736 and maybe review it as well.
Ondřej Čertík
@certik
Jan 22 2016 15:39
@srajangarg good question. I know @rwst also hit this question regarding simplifications of things like `sin(pi/8)`. I just wrote this up in details in a long comment here: https://github.com/symengine/symengine/pull/778#issuecomment-173947110, let me know what you think.
@srajangarg To answer a few things from here, based on my comment on github:
• `sqrt(x^2)` is not equal to `abs(x)` for all complex numbers. I wrote it up here why: http://www.theoretical-physics.net/dev/math/complex.html#examples, as you can see, `sqrt(x^2)` can be written using just `x`, but you need to multiply by a messy `(-1)^...` factor, so it's best to just leave `sqrt(x^2)` as is. If `x` is real, then `sqrt(x^2) = abs(x)`, but `x` must always be treated as complex.
• For the same reason, probably best to leave `sqrt(1+(1/x)^2)` as is
• As to trig simplifications, sympy seems a bit inconsistent. I have suggested what we should do in my comment at github.
Ondřej Čertík
@certik
Jan 22 2016 15:46
@bluescarni cool, that will be very useful. Do you plan to also implement polynomial factoring, like `x^2+2*x+1 ->(x+1)^2`, but multivariate? SymPy has that, and it's used if you want to simplify expressions.
Francesco Biscani
@bluescarni
Jan 22 2016 15:51
@certik down the road eventually yes, if things go well with GCD and similar. I need eventually to be able to decompose the denominators of rational functions into factors for research purposes (KAM theory and things like that)
partial fraction decomposition would also be nice
the thing is that I am not sure Piranha's data structures are really the best for these computations, so performance might not be optimal
we'll see
my understanding is that for computations is better to use only GCD computations rather than full factorizations in rational functions, but then it's useful to be able to factorize in order to understand, e.g., where the poles in the denominator are
Björn Dahlgren
@bjodah
Jan 22 2016 17:34
Hi all, I searched the code base for Min and Max functions (I want to use them with Lambdify from symengine.py - i.e. equivalent of sympy.Min and sympy.Max), but I couldn't find any such structure. Has it simply not been added yet or is there another way of achieving the same effect?
Isuru Fernando
@isuruf
Jan 22 2016 18:02
@bjodah, it's simply not added yet. It should be easy to add though