[sage-support] Re: Memoizing methods.
That is exactly what I wanted. Thanks!!! -Adrian. On Sep 3, 7:31 pm, Mike Hansen [EMAIL PROTECTED] wrote: Hi Adrian, I wrote some code to do this a few releases ago. It's the cached_method decorator in Sage. Here's your example: sage: class dog(): : def __init__(self, bark='guau'): : self._bark = bark : @cached_method : def bark(self): : sleep(5) : return (self._bark + )*3 : sage: sparky = dog() sage: sparky.bark() #5 seconds 'guau guau guau ' sage: sparky.bark() #instant 'guau guau guau ' If you're curious, you can find the code in sage/misc/cachefunc.py --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] if-statement with infinity or NaN
Hi, I want to check if a number is set to infinity or NaN. So I tried this if-statement: if x!=infinity: print x But this doesn't work when x=a/b with a very small b, so that x becomes infinity. (I'm using SAGE Version 3.0.1) Agi --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: if-statement with infinity or NaN
I have this: H is a real-valued Matrix z=abs(H[i,j]/H[j,j]) if z!=infinity: print H[i,j], H[i,j].parent() print H[j,j], H[j,j].parent() print z But it doesn't work: H[ 2 , 1 ]= -0.0243252127705267 Real Field with 53 bits of precision H[ 1 , 1 ]= 0.000 Real Field with 53 bits of precision z=+infinity This was printed although z=infinity. --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Upgrade to version 3.1.1
Hello, I just upgraded from 3.0.5 to version 3.1.1 and several things aren't working any more: 1. sliders aren't showing when used with the interact-functionality. It doesn't work the way it used to in the older version, and it doesn't work when I copy examples directly from the documentation. There's just the name of the variable, but no slider next to it. What can I do?? 2. Without changing any of the code, I get a new error message that wasn't there before, and it doesn't tell me the line of code where something went wrong. Since the code is pretty long, maybe someone can tell me what kind of error I have to look for when I see this: ValueError: invalid literal for int() with base 10: 'NaN' 3. Syntax on arrows has changed. Before I gave the starting and ending point of the arrow, now you have to give the starting point and the difference between the starting and ending points (something like (3,4) meaning 3 to the right, 4 up). However, the documentation still explains it the old way and it took me a while to figure it out. Thanks for any help with the first two problems! Maike --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: if-statement with infinity or NaN
2008/9/4 agi [EMAIL PROTECTED]: I have this: H is a real-valued Matrix z=abs(H[i,j]/H[j,j]) if z!=infinity: print H[i,j], H[i,j].parent() print H[j,j], H[j,j].parent() print z But it doesn't work: H[ 2 , 1 ]= -0.0243252127705267 Real Field with 53 bits of precision H[ 1 , 1 ]= 0.000 Real Field with 53 bits of precision z=+infinity This was printed although z=infinity. This is getting more interesting: so, you have computed a value z (in the default real field) which prints itself as +infinity though it is apparently not infinity. I think that if you replce the test z!=infinity by not z.is_infinity() then you will not get this disrepancy. This is what the print function will use to determine whether a value prints as infinity or not, while != is a more general comparison which is probably failing because z and infinity have different types. ( z!=RR(infinity) might also work, but using z.is-infinity() is curely better. Tell us if this works. John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: if-statement with infinity or NaN
On 04/09/2008, at 8:22 PM, agi wrote: Hi, I want to check if a number is set to infinity or NaN. So I tried this if-statement: if x!=infinity: print x But this doesn't work when x=a/b with a very small b, so that x becomes infinity. (I'm using SAGE Version 3.0.1) If x = 1.0/0 and y = -1.0/0, then (1) x.is_infinity() and y.is_infinity() are both True (2) x == y is False. (3) x.is_NaN() is False. Have a look at http://sagemath.org/doc/ref/module-sage.rings.real-double.html (search for is_infinity) (There may be a better reference.) D --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: if-statement with infinity or NaN
2008/9/4 David Philp [EMAIL PROTECTED]: On 04/09/2008, at 8:22 PM, agi wrote: Hi, I want to check if a number is set to infinity or NaN. So I tried this if-statement: if x!=infinity: print x But this doesn't work when x=a/b with a very small b, so that x becomes infinity. (I'm using SAGE Version 3.0.1) If x = 1.0/0 and y = -1.0/0, then (1) x.is_infinity() and y.is_infinity() are both True (2) x == y is False. (3) x.is_NaN() is False. Have a look at http://sagemath.org/doc/ref/module-sage.rings.real-double.html (search for is_infinity) (There may be a better reference.) I think this is better: http://sagemath.org/doc/ref/module-sage.rings.real-mpfr.html since RDF (double precision reals) is deprecated. Again, look for is_infinity. John Cremona D --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Incorrect computations of Eisenstein series
Hi, When computing Eisenstein series with a given character, Sage may return some forms with a wrong character. The following lines show an example of this: sage: G = DirichletGroup(7) sage: E = EisensteinForms(G[4]).eisenstein_series() sage: E[0].character() == G[4] False The problem appears to be caused by the condition if chi*psi == eps: in the function __find_eisen_chars in modular/modform/eis_series.py. According to Miyake, _Modular Forms_, Lemma 7.1.1 (cited in a comment in this function), it should be if chi == eps*psi: Another bug is that Sage uses an incorrect formula to compute q- expansions of Eisenstein series. Here the origin of the problem seems to be formula (5.3.1) in Stein, _Modular Forms: A Computational Approach_, where the psi(n) should be replaced by its complex conjugate (cf. Miyake, _Modular Forms_, Theorem 4.7.1 and the first three lines of page 271). The method __compute_general_case of the class EisensteinSeries in modular/modform/element.py reproduces this formula in the form v.append(sum([psi(n)*chi(m/n)*n**(k-1) for n in rings.divisors(m)])) Here psi should be ~psi. Thanks, Peter Bruin --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Why c.real() and c.imag() works so slow?
Just out of curiosity, what did you have to add? Your latest code
takes only seconds on my computer
My computer is much older, and always overloaded.
were you ever able to get it
reasonable on yours?
My principle is - program must run as fast as it is possible. It's
reason to move.
On Sep 3, 7:26 pm, Robert Bradshaw [EMAIL PROTECTED]
wrote:
On Sep 3, 2008, at 6:38 AM, vakaras wrote:
I now see that I have had to write a reason why I want a plain sage
script, which generates Mandelbrot set. I want to show for students,
who haven't coding before, how easy is to generate Mandelbrot set
with sage.
That's certainly a valid use case.
After adding some additional functions and classes to
sage init everything should be okay.
Just out of curiosity, what did you have to add? Your latest code
takes only seconds on my computer, were you ever able to get it
reasonable on yours?
Thank you, for help.
No problem.
- Robert
On Sep 1, 9:52 pm, Robert Bradshaw [EMAIL PROTECTED]
wrote:
On Sep 1, 2008, at 3:18 AM, Simon King wrote:
Hi,
one hint for doing *fast* computations:
Use Cython, rather than pure Python!
Certainly!
From my point of view, Cython is one of the main strengths of Sage:
You can do your computations with C data types, and you should do
so,
because it is faster than using complicated data types such as
Sage-
Integer. But you still have the nice feel of Python.
A few months ago, I made up a Mandelbrot creator myself, just for
fun
and for practicing. It consists of a class Mandelbrot. In the
initiation, you can pass various parameters (the x- and y-range, the
number of pixel on both axes, the maximal number of iterations).
If i understand the meaning of your parameters correctly, the
following produces the image that you want:
sage: attach Mandelbrot.pyx
# the code is below
sage: MB=Mandelbrot(xmin=-2,xmax=1,xsteps=200,
ymin=-1,ymax=1,ysteps=200, maxIter=200)
# i think this is your example
sage: time MB.make()
CPU times: user 0.34 s, sys: 0.00 s, total: 0.34 s
Wall time: 0.34 s
sage: show(MB.img)
# Objects of class Mandelbrot have an attribute img, which is
computed with the method make()
# and shown with show()
Main reasons why the code is fast:
1. The computations are done with data of type double. For
example,
cdef double cr
cdef double ci
describes real and imaginary part of the complex number for which we
iterate
2. All loop variables are of type int. You do
for i in range(n):
...
which is slow. Faster is
for i in xrange(n):
...
Using C types is still faster:
cdef int i
cdef int N=n # hence, the Integer n is converted into a C
int
for i from 0 = i N:
...
Note that if i is a cdef variable, one only can do
for i in range(N)
and it will be converted to the for-from style loop.
One very useful feature of Sage for developing fast code is
annotation. By typing
sage -cython -a Mandelbrot.pyx
from the command line, i get a file Mandelbrot.html, which i can
view
with a browser. That file shows me my own code -- with hints on how
efficient the code is (the more yellow a line of code the more
slow it
is executed).
The code below also relies on an experimental package for image
manipulation, that you can get (from the command line) with
sage -i PIL-1.1.5
Cheers
Simon
###
## Here is the code of Mandelbrot.pyx
import sage
import sage.all
import Image
import colorsys
# requires PIL
class Mandelbrot:
def __init__(self,xmin=-2.4,xmax=1.3,xsteps=600,
ymin=-1.7,ymax=1.7,ysteps=600, maxIter=120):
Class for creating a picture of the Mandelbrot set.
MB = Mandelbrot()
The picture can be created with MB.make() and shown with
show(MB.img)
self.colors = {} # used for cacheing
self.img = Image.new(RGB,(xsteps,ysteps),(0,0,0))
self.d2 = float(4) # sequence is unbounded if it comes
outside
a circle of radius 2
self.N = int(maxIter) # maximal number of iterations
if xmin=xmax:
raise ValueError, xmax=xmin
self.xmin=float(xmin)
self.xmax=float(xmax)
if xsteps==0:
raise ValueError, xsteps==0
self.dx=(self.xmax-self.xmin)/float(xsteps)
self.xsteps = int(xsteps)
if ymin=ymax:
raise ValueError, ymax=ymin
self.ymin=float(ymin)
self.ymax=float(ymax)
if ysteps==0:
raise ValueError, ysteps==0
self.dy=(self.ymax-self.ymin)/float(ysteps)
self.ysteps = int(ysteps)
def color(self,i):
computes the color of a pixel if the iteration leaves the
circle of radius 2 after i steps
#
[sage-support] Re: if-statement with infinity or NaN
On Sep 4, 7:23 am, John Cremona [EMAIL PROTECTED] wrote: 2008/9/4 David Philp [EMAIL PROTECTED]: I think this is better: http://sagemath.org/doc/ref/module-sage.rings.real-mpfr.html since RDF (double precision reals) is deprecated. Again, look for is_infinity. John Cremona RDF is deprecated? Is there anywhere to find more information about this? A search on trac tickets for deprecate RDF didn't return anything. Also nothing in the docs for RDF, and sage: RDF Real Double Field not a deprecation warning in 3.1.2.alpha2 Regards, JM --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: if-statement with infinity or NaN
2008/9/4 Jason Merrill [EMAIL PROTECTED]: On Sep 4, 7:23 am, John Cremona [EMAIL PROTECTED] wrote: 2008/9/4 David Philp [EMAIL PROTECTED]: I think this is better: http://sagemath.org/doc/ref/module-sage.rings.real-mpfr.html since RDF (double precision reals) is deprecated. Again, look for is_infinity. John Cremona RDF is deprecated? Is there anywhere to find more information about this? A search on trac tickets for deprecate RDF didn't return anything. Also nothing in the docs for RDF, and Sorry, perhaps I was wrong to say deprecated. I seemed to remember a discussion on sage-devel about this, but when I just looked all I found was this http://groups.google.co.uk/group/sage-devel/browse_thread/thread/5c2fee77e4feabbc/a959b8865fde0ffa?lnk=gstq=RDF#a959b8865fde0ffa which is not what I remembered. If anyone who knows the situation is reading this perhaps they can clairfy. If I am just plain wrong, I apologise. John sage: RDF Real Double Field not a deprecation warning in 3.1.2.alpha2 Regards, JM --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] including images
Hi, I'd like to include an .eps graphic in my sage-notebook output. neither the latex \includegraphics command nor the html img tag seem to work. Which command can I use, and where should I save the .eps file? I've also tried to find the files created by the sage .save(...) function (hoping to be able to put my file in the same place), but I wasn't able to locate them. Where does Sage put those?? Maike --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] How do I share a notebook with collaborators?
Dear all, I haven't found any useful documentation on the Share and Publish features of notebooks. I would like to make a local notebook viewable/ editable by collaborators, so I thought I just click on the Share button at the top of the notebook and get guided through the process. All that comes up is an empty box where I can type in collaborators separated by commas, but if I type in their email addresses and then click on Invite Collaborators, I simply get redirected back to the notebook and nothing happens. When I click on Share again, I find an empty box again. Is there any documentation on how this functionality should work? I don't know if this is an option, but it would be great if publishing a notebook could be linked to access control, so that I could collaborate on a notebook with people that don't have sage installed themselves, and then make the notebook freely available to anyone when it is ready (or a paper is published on it). Thanks for your help already! Stan --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Upgrade to version 3.1.1
On Thu, Sep 4, 2008 at 3:53 AM, Maike [EMAIL PROTECTED] wrote: Hello, I just upgraded from 3.0.5 to version 3.1.1 and several things aren't working any more: 1. sliders aren't showing when used with the interact-functionality. It doesn't work the way it used to in the older version, and it doesn't work when I copy examples directly from the documentation. There's just the name of the variable, but no slider next to it. What can I do?? It sounds like something went wrong with your upgrade. You should try a fresh install of sage-3.1.1. William 2. Without changing any of the code, I get a new error message that wasn't there before, and it doesn't tell me the line of code where something went wrong. Since the code is pretty long, maybe someone can tell me what kind of error I have to look for when I see this: ValueError: invalid literal for int() with base 10: 'NaN' 3. Syntax on arrows has changed. Before I gave the starting and ending point of the arrow, now you have to give the starting point and the difference between the starting and ending points (something like (3,4) meaning 3 to the right, 4 up). However, the documentation still explains it the old way and it took me a while to figure it out. Thanks for any help with the first two problems! Maike -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: polyhedra with float coordinates
OK, this is now trac ticket #4060. I will fix it as soon as I can, probably so a fix can be in whatever comes after sage-3.1.2. M. Hampton On Sep 3, 8:58 pm, Marshall Hampton [EMAIL PROTECTED] wrote: No, this is my fault for being lazy. I only work with exact coordinates, so I did not extensively test with floats. I will try to fix this soon. -M. Hampton On Sep 3, 10:46 am, dghersi [EMAIL PROTECTED] wrote: Dear All, I have a question related to the polyhedra module. When I define a polyhedron using float rather than integer coordinates, I get a weird behavior from the vert_to_ieq function. For example, if I type something like this: p = [[1.1, 2.2], [3.3, 4.4]] vert_to_ieq(p, cdd_type=real) I get an object that contains just one vertex, namely [0, 0, 0] On the other hand, if I use integer coordinates everything is fine. Am I doing something wrong? (I am running sage version 3.1.1 on a Mac Pro (Intel) using the precompiled binary.) Thank you very much, Dario --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] documentation on show()
Hello, I think I've found a documentation bug, but perhaps I just don't know how to read the documentation. Trac #2132 seems to reflect the same misunderstanding I had and could perhaps be closed either immediately or after a change in documentation. The documentation for show() states that the options include figsize -- [width, height] (same for square aspect) This looks for all the world as if P.show(figsize=[200,200]) should produce a square aspect image of P. On the other hand, P.show(figsize=(6,6)) *does* show a square aspect image of P. (1) Should one read [x,y] throughout the documentation as a list [.,.] of two elements or as a tuple (.,.) of two elements? If a tuple, then my bad and perhaps Trac #2132 can be closed. (2) How is one to interpret width height anyway? It clearly does not mean pixels, which was my assumption (and probably the assumption of Trac #2132). Does it mean dpi*width, dpi*height? (A guess from experimentation.) (3) From the API documentation, aspect_ratio is also a valid parameter, but this does not apepar when typing show(). Neither do some other parameters, which appear useful. Some of them don't appear to work however: frame and axes come to mind. thanks john perry --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: documentation on show()
Update: when I say that axes and frame don't appear to work, I mean after creating an implicit plot. They work find with a regular plot. thanks john perry On Sep 4, 9:16 am, john_perry_usm [EMAIL PROTECTED] wrote: Hello, I think I've found a documentation bug, but perhaps I just don't know how to read the documentation. Trac #2132 seems to reflect the same misunderstanding I had and could perhaps be closed either immediately or after a change in documentation. The documentation for show() states that the options include figsize -- [width, height] (same for square aspect) This looks for all the world as if P.show(figsize=[200,200]) should produce a square aspect image of P. On the other hand, P.show(figsize=(6,6)) *does* show a square aspect image of P. (1) Should one read [x,y] throughout the documentation as a list [.,.] of two elements or as a tuple (.,.) of two elements? If a tuple, then my bad and perhaps Trac #2132 can be closed. (2) How is one to interpret width height anyway? It clearly does not mean pixels, which was my assumption (and probably the assumption of Trac #2132). Does it mean dpi*width, dpi*height? (A guess from experimentation.) (3) From the API documentation, aspect_ratio is also a valid parameter, but this does not apepar when typing show(). Neither do some other parameters, which appear useful. Some of them don't appear to work however: frame and axes come to mind. thanks john perry --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: polyhedra with float coordinates
Thank you very much! Dario On Sep 4, 9:42 am, Marshall Hampton [EMAIL PROTECTED] wrote: OK, this is now trac ticket #4060. I will fix it as soon as I can, probably so a fix can be in whatever comes after sage-3.1.2. M. Hampton On Sep 3, 8:58 pm, Marshall Hampton [EMAIL PROTECTED] wrote: No, this is my fault for being lazy. I only work with exact coordinates, so I did not extensively test with floats. I will try to fix this soon. -M. Hampton On Sep 3, 10:46 am, dghersi [EMAIL PROTECTED] wrote: Dear All, I have a question related to the polyhedra module. When I define a polyhedron using float rather than integer coordinates, I get a weird behavior from the vert_to_ieq function. For example, if I type something like this: p = [[1.1, 2.2], [3.3, 4.4]] vert_to_ieq(p, cdd_type=real) I get an object that contains just one vertex, namely [0, 0, 0] On the other hand, if I use integer coordinates everything is fine. Am I doing something wrong? (I am running sage version 3.1.1 on a Mac Pro (Intel) using the precompiled binary.) Thank you very much, Dario --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] colors on implicit_plot
Hello, The plot() function uses the color or rgbcolor options. The implicit_plot() function does not recognize this, but requests instead the option cmap. Now cmap recognizes neither the names of colors recognized by plot(), nor rgb tuples. What cmap *does* recognize is completely incomprehensible, for example * YlGnBu * Spectral * summer * gist_yarg From what I can tell these names come from matplotlib. However, SAGE rejects anything that isn't in the cmap dictionary (lines 2023-2028 of sage.plot.plot). Is there an easy workaround to convert rgb colors to the cmaps expected by implicit_plot()? thanks john perry --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Incorrect computations of Eisenstein series
Hi Peter, I've actually been planning on going back and cleaning up/speeding up the Eisenstein series code at some point in the near future anyway. I'm on vacation this week, but I'll look at this at the beginning of next week. In the interim, this is now: http://trac.sagemath.org/sage_trac/ticket/4062 -cc On Thu, Sep 4, 2008 at 4:21 AM, Peter Bruin [EMAIL PROTECTED] wrote: Hi, When computing Eisenstein series with a given character, Sage may return some forms with a wrong character. The following lines show an example of this: sage: G = DirichletGroup(7) sage: E = EisensteinForms(G[4]).eisenstein_series() sage: E[0].character() == G[4] False The problem appears to be caused by the condition if chi*psi == eps: in the function __find_eisen_chars in modular/modform/eis_series.py. According to Miyake, _Modular Forms_, Lemma 7.1.1 (cited in a comment in this function), it should be if chi == eps*psi: Another bug is that Sage uses an incorrect formula to compute q- expansions of Eisenstein series. Here the origin of the problem seems to be formula (5.3.1) in Stein, _Modular Forms: A Computational Approach_, where the psi(n) should be replaced by its complex conjugate (cf. Miyake, _Modular Forms_, Theorem 4.7.1 and the first three lines of page 271). The method __compute_general_case of the class EisensteinSeries in modular/modform/element.py reproduces this formula in the form v.append(sum([psi(n)*chi(m/n)*n**(k-1) for n in rings.divisors(m)])) Here psi should be ~psi. Thanks, Peter Bruin --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: if-statement with infinity or NaN
It works with not z.is_infinity(). Thanks :) --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Upgrade to version 3.1.1
On Sep 4, 2008, at 6:37 AM, William Stein wrote: On Thu, Sep 4, 2008 at 3:53 AM, Maike [EMAIL PROTECTED] wrote: Hello, I just upgraded from 3.0.5 to version 3.1.1 and several things aren't working any more: 1. sliders aren't showing when used with the interact-functionality. It doesn't work the way it used to in the older version, and it doesn't work when I copy examples directly from the documentation. There's just the name of the variable, but no slider next to it. What can I do?? It sounds like something went wrong with your upgrade. You should try a fresh install of sage-3.1.1. William 2. Without changing any of the code, I get a new error message that wasn't there before, and it doesn't tell me the line of code where something went wrong. Since the code is pretty long, maybe someone can tell me what kind of error I have to look for when I see this: ValueError: invalid literal for int() with base 10: 'NaN' 3. Syntax on arrows has changed. Before I gave the starting and ending point of the arrow, now you have to give the starting point and the difference between the starting and ending points (something like (3,4) meaning 3 to the right, 4 up). However, the documentation still explains it the old way and it took me a while to figure it out. I am getting this too. When did this change? - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Upgrade to version 3.1.1
Robert Bradshaw wrote: 3. Syntax on arrows has changed. Before I gave the starting and ending point of the arrow, now you have to give the starting point and the difference between the starting and ending points (something like (3,4) meaning 3 to the right, 4 up). However, the documentation still explains it the old way and it took me a while to figure it out. I am getting this too. When did this change? This is a bug. See http://trac.sagemath.org/sage_trac/ticket/3880 It's been fixed for 3.1.2, so that arrow((x0,y0), (x1,y1)) goes from the point (x0,y0) to the point (x1,y1). Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Interact - multiple inputs for same parameter?
Is it possible to create an @interact setup such that there are two ways to specify the same input? That is, perhaps one wants to use the slider to get close to a desired input, but then for fine-tuning beyond the user's motor skill control (e.g. if there are hundreds of slider steps), one could type into a text box. Obviously one would change the other automatically; you couldn't have them be different. As far as I can find, this seems impossible currently, but I may have missed something so I am asking to make sure. Thanks for any feedback; this is my first time using interact and I do appreciate the documentation many examples. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: polyhedra with float coordinates
OK, I think I have fixed this.A patch is up at http://trac.sagemath.org/sage_trac/ticket/4060 awaiting review. I am cross-posting this to sage-devel to hopefully attract a reviewer. In the meantime you could patch your own source if you'd like. If you aren't comfortable doing that, you could grab www.d.umn.edu/~mhampton/polyhedra.py and copy it into your sage directory at $SAGE_ROOT/devel/sage-main/sage/geometry/polyhedra.py, and then rebuild with sage -b. Marshall Hampton On Sep 4, 8:43 am, dghersi [EMAIL PROTECTED] wrote: Thank you very much! Dario On Sep 4, 9:42 am, Marshall Hampton [EMAIL PROTECTED] wrote: OK, this is now trac ticket #4060. I will fix it as soon as I can, probably so a fix can be in whatever comes after sage-3.1.2. M. Hampton On Sep 3, 8:58 pm, Marshall Hampton [EMAIL PROTECTED] wrote: No, this is my fault for being lazy. I only work with exact coordinates, so I did not extensively test with floats. I will try to fix this soon. -M. Hampton On Sep 3, 10:46 am, dghersi [EMAIL PROTECTED] wrote: Dear All, I have a question related to the polyhedra module. When I define a polyhedron using float rather than integer coordinates, I get a weird behavior from the vert_to_ieq function. For example, if I type something like this: p = [[1.1, 2.2], [3.3, 4.4]] vert_to_ieq(p, cdd_type=real) I get an object that contains just one vertex, namely [0, 0, 0] On the other hand, if I use integer coordinates everything is fine. Am I doing something wrong? (I am running sage version 3.1.1 on a Mac Pro (Intel) using the precompiled binary.) Thank you very much, Dario --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Interact - multiple inputs for same parameter?
There is a work-around though: have two controls (say coarse and fine) and then use the sum of those variables as the actual parameter. As a stupid example: pre @interact def stest(a = slider(0,3.14,.1,1.5), b = slider(0,.1,.01)): sum_var = a + b show(plot(lambda x: sin(x), 0, sum_var), xmin = 0, xmax = sum_var) /pre On Sep 4, 1:50 pm, Jason Grout [EMAIL PROTECTED] wrote: kcrisman wrote: Is it possible to create an @interact setup such that there are two ways to specify the same input? That is, perhaps one wants to use the slider to get close to a desired input, but then for fine-tuning beyond the user's motor skill control (e.g. if there are hundreds of slider steps), one could type into a text box. Obviously one would change the other automatically; you couldn't have them be different. As far as I can find, this seems impossible currently, but I may have missed something so I am asking to make sure. Thanks for any feedback; this is my first time using interact and I do appreciate the documentation many examples. Right now I believe this is impossible. I think the easiest way to make it happen would be to create a new @interact control with both a slider and a text box, for example. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
