Xaver's profile - activity

see this post http://thingwy.blogspot.de/

kcrisman wrote: I don't know that an "answer" is really appropriate here. It's pretty well-known among power users that symbolic manipulation is something that Maple and Mma do better than Maxima (which provides our simplification). It's unfortunate

Actually this is far more of an answer than I was expecting from an open source project. Thank you very much indeed. I am surely not a power user of sage but I am a power user of mathematica with several tens of thousands of lines of code written for research and teaching in theoretical physics over the years and using it surely not only but definitely also for symbolic manipulation. Actually I didn't even know of sage since very recently a student of mine asked about it. Reading the "Tour of Sage" and the "Tutorial" in the docs and the frequently reoccurring benchmarks against mathematica in other parts of the docs, I was mislead to think ".. wow this might be an open source replacement ..". So it played around with sage in my spare time, attempting just some very 1st and trivial things.

Some of my related questions you can find in this forum. I learned, stuff like: sage can't get elementary functions like the log() straight, or, plotting more than just the cos() gets you into trouble, and now I read that I should not use sage for symbolic manipulations.

So yes, you gave an answer - one which will also help my students (which can have their university licenses of mathematica for free anyway).

Update: see this http://thingwy.blogspot.de/

@G-Sage TAB completion produces both, full_simplify() and simplify_full() and they both return the same results - moreover the doc says: simplify_full(...) File: sage/symbolic/expression.pyx (starting at line 6553) Applies simplify_factorial, simplify_trig, simplify_rational, simplify_radical, simplify_log, and again simplify_rational to self (in that order). ALIAS: simplify_full and full_simplify are the same

@Jason Grout so that would imply that if one was to plot something like F(imag(G(...,imag(..))), or other nested constructs containing imag() parts, one would have put all of the imag()'s on a hold prior to plotting? That could get quite cumbersome.

I have this function

    sage: f=imag(I*(sqrt(-cos(l) + 1)*cosh(sin(1/2*l)) - 
sqrt(2)*sinh(sqrt(sin(1/2*l)^2)))*sin(1/2*l)^3/((-cos(l) 
+ 1)^(3/2)*e^(1/2*I*l)))

i.m.h.o. this not something terribly complicated. I wanted to plot it. So I do

sage: time plot(f,l,0,10)
..nice plot..
Time: CPU 9.28 s, Wall: 9.41 s

I.e. I was waiting almost 10s for this (on an intel core duo CPU P9500 @ 2.53GHz) laptop!? I thought that maybe fast_callable would help:

sage: ff=fast_callable(f,vars=[l],domain=CC)
sage: time plot(ff,0,10)
..same nice plot..
Time: CPU 13.24 s, Wall: 13.50 s

So that's even worse. Now I compare to Mathematica

In[8]:= Timing[Plot[Im[(Sin[l/2]^3*(I*Sqrt[1 - Cos[l]]*Cosh[Sin[l/2]] - 
        I*Sqrt[2]*Sinh[Sqrt[Sin[l/2]^2]]))/(E^((I/2)*l)*(1 - 
         Cos[l])^(3/2))], {l, 0, 10}]]

Out[8]= {0.019997, ..same plot again..}

~500 times faster ... what am I doing wrong?

@kcrisman, where ever it comes from, let it be Sage or Maxima, my feeling is that just amending the documentation of 'assume' is not a real solution of this (complex ;) ) problem. It is the log() ... it is most basic math ... and it is not working correctly. This should be fixed. Is this just a bug in the log(), or in how 'limit' works, or in 'assume', or maybe even in other elementary functions? I consider this 'bug' as @jdc puts it, as rather frightening. I was on the verge of using Sage to analyze the analytic properties of some far more involved functions in the complex plane then just the log(). Now I fear one should better stay away from that. Please keep me posted on this issue.

@John Palmieri: with z=r * e^(i * phi), where r=|z|, we have log(z)=i*phi+log(|z|). As always we have to chose how to count phi. The 1st and 2nd example agree with sage having the branch cut on the negative real axis with phi=+pi in the upper half and -pi in the lower half plane. The 3rd example still agrees with that but the real part is not log(|z|), which would be log(ec-w), but log(w-ec), which is not even defined, since w-ec is real and negative. The last example shows that Mathematica does this right. It has Log[ec-w], which is ok.

For the log() to be defined properly in the complex plane we need to agree on where its cut is located. So, for sage it is easy to check that the cut is located on the negative Re-axis (as is most common), namely

sage: var('eps')
sage: limit(log(-1+i*eps),eps=0,dir='+')
I*pi
sage: limit(log(-1+i*eps),eps=0,dir='-')
-I*pi

Ok. Now I want to use this with symbolic variables. So I do

sage: var('w eps')
sage: forget()
sage: assume(w,'real')
sage: assume(w>0)
sage: limit(log(-w+i*eps),eps=0,dir='+')
I*pi + log(w)
sage: limit(log(-w+i*eps),eps=0,dir='-')
-I*pi + log(w)

Ok. That is correct. Now I want to get a little more adventurous, namely

sage: var('w ec eps')
sage: forget()
sage: assume(w,'real')
sage: assume(ec,'real')
sage: assume(eps,'real')
sage: assume(w>0)
sage: assume(w<ec)
sage: limit(log(w-ec+i*eps),eps=0,dir='+')
I*pi + log(-ec + w)
sage: limit(log(w-ec+i*eps),eps=0,dir='-')
-I*pi + log(-ec + w)

Oops? This is wrong. The argument of the log() has not been turned into the absolute value its real part, i.e. ec-w. This also contradicts the previous simpler startup examples.

Just for backup. Mathematica will give you

In[6]:= Limit[Log[w-ec+I eps],eps->0,Direction->-1,Assumptions->{w>0,w<ec}]
Out[6]= I Pi+Log[ec-w]
In[7]:= Limit[Log[w-ec+I eps],eps->0,Direction->1,Assumptions->{w>0,w<ec}]
Out[7]= -I Pi+Log[ec-w]

As I was expecting and at variance with sage's output.

@Jason Grout: 1) "..it is assumed that you can divide and things aren't zero...". Yes. Exactly that is what happens.

2) "..This happens in other math software systems too..". Yes again, eg. also in Mathematica:

In[4]:= RowReduce[{{1, 1, 2, b1}, {1, 0, 1, b2}, {2, 1, 3, b3}}]
Out[4]= {{1, 0, 1, 0}, {0, 1, 1, 0}, {0, 0, 0, 1}}

@DSM: for sage: p=sum([var(join(['a',str(i)],sep=''))*x^i for i in (0..N)]), couldn't you still use p.operands()[N-10].operands()[0] and get a10, so you can still address them in a list fashion ... but I agree this now looks ugly (and with karma 51 I'd better shut up ;) )

Why does one need the list? Can't one just do: sum([var(join(['a',str(i)],sep=''))*x^i for i in (0..N)])

I think your 'expected answer' is not the expected answer.

The definition of the echelon form of a matrix requires (amongst others) that the first non-zero element on each row be a 1. So, from your results the next step is to multiply the last row by 1/(-b1-b2+b3) which leads to

[[1,1,2,   b1]
 [0,1,1,b1-b2]
 [0,0,0,   1]]

and then, you can subtract the last row times (b1-b2) and times b1 from the 2nd and the 1st row, leading to

[[1,1,2,0]
 [0,1,1,0]
 [0,0,0,1]]

finally you can subtract the 2nd from the 1st row leading to

   [[1,0,1,0]
    [0,1,1,0]
    [0,0,0,1]]

So, everything is ok.

B.t.w.: the reason why you can completely wipe out your 'variables' b1...b3 is because the cols/rows of the rest of the matrix are linearly dependent. You will experience the same thing for any other case where this holds because one of the rows of your matrix will contain only zeros up to the row which contains the variables.

a) thanks! b) from your solution I went to the docs and I have to admit that the reason for not finding this answer was that I neither do understand what an ExpressionTree(Builder) is in the first place, nor why it seems to relate to the variables of the symbolic expression. Would you mind to give some more explanation or point me to a place in the doc where I could get the necessary background?

There are two points to your question: 1)

cos(x+2)*cos(x)-cos(x+1)*cos(x+1)=-sin(1)^2   #i.e. a constant

(Actually one of the experts should kick in and tell us what to do to make sage simplify your expression to that. I am frequently having problems to force sage to simplify even the most trivial expressions. A tutorial on that would be nice...)

2) sage uses matplotlib to do the plotting of your expression. The automatic selection of a 'proper' y-axis extent of that can cause problems when the actual y-extent of your data is identically zero. So, do something like:

plot(cos(x+2)*cos(x)-cos(x+1)*cos(x+1),(-pi,pi),ymin=-sin(1)^2*1.1,ymax=-sin(1)^2*.9)

and you'll get: ... a nice straight line