[sage-support] Re: Inert Integrals and Derivatives?
David Philp wrote: > On 02/09/2008, at 6:22, Robert Dodier <[EMAIL PROTECTED]> wrote: > > * lack of syntax in programming constructs > What does this mean? If[x, y, z] instead "if x then y else z" or something like that While[a, b] instead of "while a do b" or "while (a) b" or something like that Switch[a, x, xx, y, yy, ...] instead of "switch (a) case x : xx, case y : yy, ..." or something like that The point in each case is that it helps the reader see the structure of the code to separate the arguments by keywords or other syntax elements. best Robert Dodier --~--~-~--~~~---~--~~ 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: Inert Integrals and Derivatives?
On Mon, Sep 1, 2008 at 10:22 PM, Robert Dodier <[EMAIL PROTECTED]> wrote: > > Ondrej Certik wrote: > >> So what things do they have wrong? So that we can learn from it. > > * all functions are capitalized > > * BumpyCaseIsHardToRead > > * square brackets for function arguments > > * two square brackets for subscripts > > * squiggly braces for lists > > * sets and matrices not distinguished from lists > > * lack of syntax in programming constructs > > There's really nothing to recommend any of this. Ah, this, but all of those are fixed by Python. I thought you mean some design principle. Yes, those are things why I wrote in some other thread that programming in mathematica is not fun (for me), but the design of mathematica (at least what I understood so far), I must say, is fun for me and I want to have it, just in Python. Ondrej --~--~-~--~~~---~--~~ 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: Inert Integrals and Derivatives?
On 02/09/2008, at 6:22, Robert Dodier <[EMAIL PROTECTED]> wrote: > * sets and matrices not distinguished from lists This is a serious defect in mathematica. It has led to me making mistakes. Most of your other objections were matters of taste. (I agree with most of them but they are mostly things that sage will obviously avoid so they aren't very instructive.) I think the most useful thing for this discussion is to concentrate on the things the 'big four' get right, that sage lacks. > * lack of syntax in programming constructs What does this mean? 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: Inert Integrals and Derivatives?
On Sep 1, 2008, at 1:22 PM, Robert Dodier wrote: > > Ondrej Certik wrote: > >> So what things do they have wrong? So that we can learn from it. > > * all functions are capitalized > > * BumpyCaseIsHardToRead > > * square brackets for function arguments > > * two square brackets for subscripts > > * squiggly braces for lists > > * sets and matrices not distinguished from lists > > * lack of syntax in programming constructs > > There's really nothing to recommend any of this. I'm with you on those! The folks at Mathematica have a lot of good ideas, but I certainly don't see us wanting anything from this list. - 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: Inert Integrals and Derivatives?
Ondrej Certik wrote: > So what things do they have wrong? So that we can learn from it. * all functions are capitalized * BumpyCaseIsHardToRead * square brackets for function arguments * two square brackets for subscripts * squiggly braces for lists * sets and matrices not distinguished from lists * lack of syntax in programming constructs There's really nothing to recommend any of this. FWIW Robert Dodier --~--~-~--~~~---~--~~ 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?
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 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 . 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 . 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 n is converted into a C
>
>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"
> # the result is cached in self.colors
> if i==self.N:
> return (0,0,0)
> CL = self.colors.get(i)
> if CL:
> return CL
> (r,g,b) = colorsys.hsv_to_rgb(1.0-float(i)/self.N,1.0,1.0)
> CL = (int(256*r)-1,int(256*g)-1,int(256*b)-1)
> self.colors[i] = CL
> return CL
>
> def point(self,x,y):
> """
> return the number of iterations after which point (x,y)
> leaves the circle of radius 2.
> Maximum number of iterations is self.N
> """
> # Morally, this is C code!
> cdef double cr = self.xmin+x*self.dx
> cdef double ci = self.ymin+y*self.dy
> cdef double zr = 0
> cdef double zi = 0
> cdef double zrneu,zineu
> cdef double zr2=0
> cdef double zi2=0
> cdef double d2 = self.d2
> cdef int N = self.N
> cdef int i
> for i from 0 <= i <= N:
> zrneu = zr2-zi2 + cr
> zineu = 2*zr*zi + ci
> zr=zrneu
>
[sage-support] Re: Inert Integrals and Derivatives?
On Mon, Sep 1, 2008 at 6:45 PM, Robert Dodier <[EMAIL PROTECTED]> wrote: > > Robert Bradshaw wrote: > >> On Aug 30, 2008, at 4:46 PM, Robert Dodier wrote: > >> > From the direction this discussion has taken I'm guessing that >> > nobody here is aware that selective evaluation is trivial in Lisp, >> > and Maxima. In both cases a single quote marks stuff that >> > isn't evaluated. > >> I actually did know that lisp has this feature. The real question is >> how to expose such a feature in a natural way in the Sage (Python) >> environment. > > FWICT there is not indeed any natural way to do it. It seems within > the realm of possibility to develop a superset of Python which has a > modified evaluation policy. Existing programs would act the same > in this hypothetical language, but there could be new constructs > (quoting and evaluating, unevaluated and partially-evaluated > expressions, maybe more) which extend the language. > >> Using Python has worked out very nice both for the UI >> and core library--I don't see this changing anytime soon. > > There are days when I want to use Python as the UI language; > it is a much stronger programming language than the existing > Maxima language. There is an implementation of Python in > Lisp, namely CLPython. I have toyed with the idea of using > CLPython as the UI language for Maxima. > >> And as beautiful lisp is as a language, it seems even Maxima >> decided that it wasn't suited for the front end of a CAS. > > The Maxima language has the same code = data principle as in Lisp. > That's much more important than parenthesis or the lack of them. Ok. I would be really interested what things you don't like on Mathematica. It seems to me it is also quite lisp like, no? So what things do they have wrong? So that we can learn from it. Ondrej --~--~-~--~~~---~--~~ 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: Inert Integrals and Derivatives?
Robert Bradshaw wrote: > On Aug 30, 2008, at 4:46 PM, Robert Dodier wrote: > > From the direction this discussion has taken I'm guessing that > > nobody here is aware that selective evaluation is trivial in Lisp, > > and Maxima. In both cases a single quote marks stuff that > > isn't evaluated. > I actually did know that lisp has this feature. The real question is > how to expose such a feature in a natural way in the Sage (Python) > environment. FWICT there is not indeed any natural way to do it. It seems within the realm of possibility to develop a superset of Python which has a modified evaluation policy. Existing programs would act the same in this hypothetical language, but there could be new constructs (quoting and evaluating, unevaluated and partially-evaluated expressions, maybe more) which extend the language. > Using Python has worked out very nice both for the UI > and core library--I don't see this changing anytime soon. There are days when I want to use Python as the UI language; it is a much stronger programming language than the existing Maxima language. There is an implementation of Python in Lisp, namely CLPython. I have toyed with the idea of using CLPython as the UI language for Maxima. > And as beautiful lisp is as a language, it seems even Maxima > decided that it wasn't suited for the front end of a CAS. The Maxima language has the same code = data principle as in Lisp. That's much more important than parenthesis or the lack of them. All the best Robert Dodier --~--~-~--~~~---~--~~ 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: problem with _fast_float and find_maximum_on_interval
OK, I found out what to do. Since I used _fast_float_, the function
was converted to a python function, where nan is different to the sage
NaN. The ultimate test for a nan number, as I found out from a python
blog, is to do:
number==number
This will return 'false' only if 'number' is a python nan. Please
correct me if I'm wrong.
Cheers
Stan
On Sep 1, 2:28 pm, Stan Schymanski <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I got an odd behaviour using _fast_float in find_maximum_on_interval,
> where a complex number was output as 'nan', which is not the same as
> NaN or 'nan'. How can I test for such occurences in order to exclude
> them?
>
> Thanks for your help!
>
> Stan
>
> --
> | SAGE Version 3.1.1, Release Date: 2008-08-17 |
> | Type notebook() for the GUI, and license() for information. |
> --
>
> sage: var('av')
> av
> sage: bv1=(10*sqrt(70.56000*(av^4 - 2*av^3 + av^2) +
> : 207.3600*(-4*av^4 + 8*av^3 - 4*av^2) +
> : 365*(51.84000*(4*av^3 - 4*av) + 17.64000*(2*av -
> : 2*av^2)) + 133225*(4.41 - 51.84000*av)) +
> : 84.0*(av - av^2) + 7665.000)/
> (720.*(2 -
> : 2*av) + 131400.0)
> sage: soln=find_maximum_on_interval(bv1._fast_float_('av'),0,1);soln
> (nan, 0.38196601125)
> sage: type(soln[0])
>
> sage: soln[0]==nan
> ---
> NameError Traceback (most recent call
> last)
>
> /Users/sschym/ in ()
>
> NameError: name 'nan' is not defined
> sage: soln[0]=='nan'
> False
> sage: soln[0]>0.
> True
> sage: soln[0]<1.
> False
> sage: soln1=find_maximum_on_interval(bv1,0,1);soln1
> (7.55915212607560e-6*(14395.05425073996*I + 7684.829710109982),
> 0.38196601125)
> sage: soln[0]==soln1[0]
> 7.55915212607560e-6*(14395.05425073996*I + 7684.829710109982) == nan
> sage: soln[0]==NaN
> NaN == nan
--~--~-~--~~~---~--~~
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] problem with _fast_float and find_maximum_on_interval
Dear all,
I got an odd behaviour using _fast_float in find_maximum_on_interval,
where a complex number was output as 'nan', which is not the same as
NaN or 'nan'. How can I test for such occurences in order to exclude
them?
Thanks for your help!
Stan
--
| SAGE Version 3.1.1, Release Date: 2008-08-17 |
| Type notebook() for the GUI, and license() for information.|
--
sage: var('av')
av
sage: bv1=(10*sqrt(70.56000*(av^4 - 2*av^3 + av^2) +
: 207.3600*(-4*av^4 + 8*av^3 - 4*av^2) +
: 365*(51.84000*(4*av^3 - 4*av) + 17.64000*(2*av -
: 2*av^2)) + 133225*(4.41 - 51.84000*av)) +
: 84.0*(av - av^2) + 7665.000)/
(720.*(2 -
: 2*av) + 131400.0)
sage: soln=find_maximum_on_interval(bv1._fast_float_('av'),0,1);soln
(nan, 0.38196601125)
sage: type(soln[0])
sage: soln[0]==nan
---
NameError Traceback (most recent call
last)
/Users/sschym/ in ()
NameError: name 'nan' is not defined
sage: soln[0]=='nan'
False
sage: soln[0]>0.
True
sage: soln[0]<1.
False
sage: soln1=find_maximum_on_interval(bv1,0,1);soln1
(7.55915212607560e-6*(14395.05425073996*I + 7684.829710109982),
0.38196601125)
sage: soln[0]==soln1[0]
7.55915212607560e-6*(14395.05425073996*I + 7684.829710109982) == nan
sage: soln[0]==NaN
NaN == nan
--~--~-~--~~~---~--~~
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?
Hi,
one hint for doing *fast* computations:
Use Cython, rather than pure Python!
>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 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 . 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 . 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 n is converted into a C
for i from 0 <= i < N:
...
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"
# the result is cached in self.colors
if i==self.N:
return (0,0,0)
CL = self.colors.get(i)
if CL:
return CL
(r,g,b) = colorsys.hsv_to_rgb(1.0-float(i)/self.N,1.0,1.0)
CL = (int(256*r)-1,int(256*g)-1,int(256*b)-1)
self.colors[i] = CL
return CL
def point(self,x,y):
"""
return the number of iterations after which point (x,y)
leaves the circle of radius 2.
Maximum number of iterations is self.N
"""
# Morally, this is C code!
cdef double cr = self.xmin+x*self.dx
cdef double ci = self.ymin+y*self.dy
cdef double zr = 0
cdef double zi = 0
cdef double zrneu,zineu
cdef double zr2=0
cdef double zi2=0
cdef double d2 = self.d2
cdef int N = self.N
cdef int i
for i from 0 <= i <= N:
zrneu = zr2-zi2 + cr
zineu = 2*zr*zi + ci
zr=zrneu
zi=zineu
zr2=zr**2
zi2=zi**2
if (zr2+zi2)>d2:
self.img.putpixel((x,y),self.color(i))
return i
return self.N
def make (self):
"Create a picture of the Mandelbrot set"
cdef int i
cdef int j
cdef int xm = self.xsteps
cdef int ym = self.ysteps
for i from 0 <= i < xm:
for j from 0 <= j < ym:
