[sage-support] Re: Bessel argument order
On Feb 16, 2008 5:46 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Feb 16, 11:38 pm, "David Joyner" <[EMAIL PROTECTED]> wrote: > > Hi David, > > > Micheal suggested replacing all "#random's" by "..." and > > William seconded this. Then William suggested adding the scip option to > > the functions implemented. This has been done as well. > > The patch passes "sage -t" has some examples added and some > > docstring typos fixed. It can be found > > at:http://sage.math.washington.edu/home/wdj/patches/special_16-02-2008.hg > > Should I make a ticket for this? Okay, done. http://sagetrac.org/sage_trac/ticket/2183 > > Yep, everything you work on (and plan to contribute to Sage) is a > ticket ;) > > > > Cheers, > > Michael > > > --~--~-~--~~~---~--~~ 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: Bessel argument order
On Feb 16, 11:38 pm, "David Joyner" <[EMAIL PROTECTED]> wrote: Hi David, > Micheal suggested replacing all "#random's" by "..." and > William seconded this. Then William suggested adding the scip option to > the functions implemented. This has been done as well. > The patch passes "sage -t" has some examples added and some > docstring typos fixed. It can be found > at:http://sage.math.washington.edu/home/wdj/patches/special_16-02-2008.hg > Should I make a ticket for this? Yep, everything you work on (and plan to contribute to Sage) is a ticket ;) Cheers, Michael --~--~-~--~~~---~--~~ 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: Bessel argument order
Micheal suggested replacing all "#random's" by "..." and William seconded this. Then William suggested adding the scip option to the functions implemented. This has been done as well. The patch passes "sage -t" has some examples added and some docstring typos fixed. It can be found at: http://sage.math.washington.edu/home/wdj/patches/special_16-02-2008.hg Should I make a ticket for this? On Dec 12, 2007 7:09 PM, William Stein <[EMAIL PROTECTED]> wrote: > > On Dec 12, 2007 3:18 PM, pgdoyle <[EMAIL PROTECTED]> wrote: > > > > > > > I'll actually be posting a vague pie in the sky grant proposal to > > > sage-* for feedback in about 3 or 4 days > > > about improving special functions in Sage > > > > > > > This sounds like a very good idea. One of the main things I worry > > about missing from Mathematica is all the special functions. > ^ > > If you haven't already, you should also try doing: > > sage: import scipy.special > sage: scipy.special.[tab key] > > There's a *massive* number of double precision special functions > included in sage via scipy. > > Even better, take a look at this page: > >http://new.scipy.org/SciPyPackages/Special > > There's a list of over 15 families of Bessel functions. We have not > yet done anything to make these easy to use from Sage yet -- which > for me means: >(1) adding *lots* of examples, >(2) wrapping them so they behave well with respect to Sage data types >(3) Given them plot methods, and symbolic support. > In particular, you may want to turn of preparsing before using them or > explicitly coerce the inputs to native python types (e.g., float, > complex, etc.). > Here is an example: > > sage: import scipy.special > sage: scipy.special.yv? > Type: ufunc > Base Class: > String Form: > Namespace: Interactive > Docstring: > y = yv(x1,x2) y=yv(v,z) returns the Bessel function of the second > kind of real > order v at complex z. > sage: scipy.special.yv(int(2),complex(0,1)) > (1.03440456978-0.135747669767j) How is this converted to sage? > > IMPORTANT NOTE: When David Joyner was using Pari/maxima to > implement the special functions stuff at the sage level that you've been > looking at, scipy wasn't even a part of Sage yet, otherwise he might > have used it. > > By the way, I originally wrote the first ever pre-Sage <--> something else > interface 3 years ago when I needed access to a special function that > was only implemented in Mathematica (as far as I knew). That's where > Sage talking to other programs really began... > > > This is of course a tricky business, because of choices of branch- > > cuts, and keeping track of precision, and Mathematica's functions > > don't always work > > as they should. I hope and expect that this kind of problem will be > > easier to deal with in an open system than in Mathematica, where > > you can't inspect the code. > > Agreed. > > > -- William > > > > > --~--~-~--~~~---~--~~ 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: Bessel argument order
On Dec 12, 2007 3:18 PM, pgdoyle <[EMAIL PROTECTED]> wrote: > > > > I'll actually be posting a vague pie in the sky grant proposal to > > sage-* for feedback in about 3 or 4 days > > about improving special functions in Sage > > > > This sounds like a very good idea. One of the main things I worry > about missing from Mathematica is all the special functions. ^ If you haven't already, you should also try doing: sage: import scipy.special sage: scipy.special.[tab key] There's a *massive* number of double precision special functions included in sage via scipy. Even better, take a look at this page: http://new.scipy.org/SciPyPackages/Special There's a list of over 15 families of Bessel functions. We have not yet done anything to make these easy to use from Sage yet -- which for me means: (1) adding *lots* of examples, (2) wrapping them so they behave well with respect to Sage data types (3) Given them plot methods, and symbolic support. In particular, you may want to turn of preparsing before using them or explicitly coerce the inputs to native python types (e.g., float, complex, etc.). Here is an example: sage: import scipy.special sage: scipy.special.yv? Type: ufunc Base Class: String Form: Namespace: Interactive Docstring: y = yv(x1,x2) y=yv(v,z) returns the Bessel function of the second kind of real order v at complex z. sage: scipy.special.yv(int(2),complex(0,1)) (1.03440456978-0.135747669767j) IMPORTANT NOTE: When David Joyner was using Pari/maxima to implement the special functions stuff at the sage level that you've been looking at, scipy wasn't even a part of Sage yet, otherwise he might have used it. By the way, I originally wrote the first ever pre-Sage <--> something else interface 3 years ago when I needed access to a special function that was only implemented in Mathematica (as far as I knew). That's where Sage talking to other programs really began... > This is of course a tricky business, because of choices of branch- > cuts, and keeping track of precision, and Mathematica's functions > don't always work > as they should. I hope and expect that this kind of problem will be > easier to deal with in an open system than in Mathematica, where > you can't inspect the code. Agreed. -- William --~--~-~--~~~---~--~~ 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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
> I'll actually be posting a vague pie in the sky grant proposal to > sage-* for feedback in about 3 or 4 days > about improving special functions in Sage > This sounds like a very good idea. One of the main things I worry about missing from Mathematica is all the special functions. This is of course a tricky business, because of choices of branch- cuts, and keeping track of precision, and Mathematica's functions don't always work as they should. I hope and expect that this kind of problem will be easier to deal with in an open system than in Mathematica, where you can't inspect the code. --~--~-~--~~~---~--~~ 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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
On Dec 12, 2007 2:44 PM, pgdoyle <[EMAIL PROTECTED]> wrote: > > To get back to the question of argument order, it seems strange to me > that > pari(2).besselk(3) > should meant K_2(3) rather than K_3(2). > > sage: pari(2).besselk(3) > 0.06151045847174203765682007145 > sage: bessel_K(2,3) > 0.0615104584717420 > > bessel_K(nu,x) is written K_nu(x) because the first argument nu is in > some sense a parameter - in many cases an integer - identifying > K_nu as the nu'th Bessel function of type K. So I would naively > imagine that > pari(2).besselk(3) > would mean `take the 3rd bessel function and apply it to 2'. > > Is there some general philosophy that dictates the opposite behavior? > Like, say, "f(x,y) always translates to x.f(y)"? Yes. In all of the interfaces, "f(x,y) *always* translates to x.f(y)". In most situations this is the most natural choice. > As a preview of an issue I'll raise in a separate post, note that Sage > is not giving us its best with bessel_K: > > sage: bessel_K(2+I,3+I) > Traceback (most recent call last): > ... > TypeError: Unable to convert x > (='0.043192827269587267-0.040059538066532876*I') to real number. > > The answer here is correct, and the only problem is that Sage was > expecting the result to be a real number. Fix it and submit a patch :-). The think the special functions could be greatly improved. I'll actually be posting a vague pie in the sky grant proposal to sage-* for feedback in about 3 or 4 days about improving special functions in Sage william --~--~-~--~~~---~--~~ 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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
To get back to the question of argument order, it seems strange to me that pari(2).besselk(3) should meant K_2(3) rather than K_3(2). sage: pari(2).besselk(3) 0.06151045847174203765682007145 sage: bessel_K(2,3) 0.0615104584717420 bessel_K(nu,x) is written K_nu(x) because the first argument nu is in some sense a parameter - in many cases an integer - identifying K_nu as the nu'th Bessel function of type K. So I would naively imagine that pari(2).besselk(3) would mean `take the 3rd bessel function and apply it to 2'. Is there some general philosophy that dictates the opposite behavior? Like, say, "f(x,y) always translates to x.f(y)"? As a preview of an issue I'll raise in a separate post, note that Sage is not giving us its best with bessel_K: sage: bessel_K(2+I,3+I) Traceback (most recent call last): ... TypeError: Unable to convert x (='0.043192827269587267-0.040059538066532876*I') to real number. The answer here is correct, and the only problem is that Sage was expecting the result to be a real number. Cheers, Peter --~--~-~--~~~---~--~~ 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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
> > even better would be to adopt a computational model such that all > > numerical computations can give only *one* correct result. Then you > > could simply compare to the expected result with utilities like "diff". > > That would be nice but isn't realistic, since Sage includes systems like > Numpy / Scipy / PARI, etc, and none of these systems adopt such a model, > for whatever reason. Maybe it is not realistic today, but you have to push those systems to adopt clear semantics, so that it becomes realistic tomorrow. Otherwise a given SAGE computation which works on a given computer might fail on another one. Paul --~--~-~--~~~---~--~~ 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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
On Dec 12, 2007 5:30 AM, Paul Zimmermann <[EMAIL PROTECTED]> wrote:
>
> > > > >sage: pari('2').besselk(3) # random
> > > "Random" here doesn't mean what you think. [...]
> > We really need to kill all of those and add "..." to account for the
> > imprecision caused by different CPUs/operating systems/compilers.
>
> even better would be to adopt a computational model such that all
> numerical computations can give only *one* correct result. Then you
> could simply compare to the expected result with utilities like "diff".
That would be nice but isn't realistic, since Sage includes systems like
Numpy / Scipy / PARI, etc, and none of these systems adopt such a model,
for whatever reason.
The realistic thing is what Mabshoff suggests, which is changing the
doctests to look like this:
sage: pari('2').besselk(3)
0.061510458471742...
where the ...'s the bits that are random.
David -- maybe changing some of these would be something
you might want to do?
William
--~--~-~--~~~---~--~~
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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
> > > >sage: pari('2').besselk(3) # random
> > "Random" here doesn't mean what you think. [...]
> We really need to kill all of those and add "..." to account for the
> imprecision caused by different CPUs/operating systems/compilers.
even better would be to adopt a computational model such that all
numerical computations can give only *one* correct result. Then you
could simply compare to the expected result with utilities like "diff".
Paul Zimmermann
--~--~-~--~~~---~--~~
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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
On Dec 12, 11:50 am, "David Joyner" <[EMAIL PROTECTED]> wrote:
> On Dec 12, 2007 3:20 AM, pgdoyle <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > The description of Bessel_K functions in the Sage Cookbook is
> > confusing about the order of the arguments.
> >http://sagemath.org/doc/html/const/node96.html
> > Here's what it says:
>
> > >Here's an example using SAGE's interface to pari's special functions.
>
> > >sage: pari('2+I').besselk(3)
> > >0.04559077184075505871203211094 + 0.02891929465820812820828883526*I #
> > >32-bit
> > >0.045590771840755058712032110938791854704 +
> > >0.028919294658208128208288835257608789842*I # 64-bit
> > >sage: pari('2').besselk(3) # random
> > >0.061510458471742038
>
> > >The last command can also be executed using the SAGE command
>
> > >sage: bessel_K(3,2)
> > >0.647385390948634
> > >sage: bessel_K(3,2,100)
> > >0.64738539094863415315923557097
>
> > But in fact the answer 0.061510458471742038 is correct, not random:
>
> "Random" here doesn't mean what you think. All SAGE docs are
> tested for correctness by an automatic testing program written by
> William Stein. Since it is run on different machines, and different
> machines give
We really need to kill all of those and add "..." to account for the
imprecision caused by different CPUs/operating systems/compilers. That
was we can still catch obviously incorrect results while ignoring
numerical noise. I will open a ticket for that shortly and grep
through the tree for all occurrences of "#random". We might not kill
all of them, but we should be able to eliminate the vast majority of
them.
Cheers,
Michael
> slightly different round-off errors at the last few places, those last
> few places are "random". Here "# random" is a key word that indicates
> to the tester that the last few places are possibly different.
>
>
>
> > sage: bessel_K(2,3)
> > 0.0615104584717420
> > sage: bessel_K(2,3,100)
> > 0.061510458471742037656820071453
>
> > I believe the confusion resulted because in earlier versions of Sage
> > the order of arguments to
> > bessel_K was backwards. For instance in Sage 2.8.5:
>
> > sage: bessel_K(2,3)
> > 0.647385390948634 # WRONG!!!
>
> > Cheers,
>
> > Peter
--~--~-~--~~~---~--~~
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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~--~~~~--~~--~--~---
[sage-support] Re: Bessel argument order
On Dec 12, 2007 3:20 AM, pgdoyle <[EMAIL PROTECTED]> wrote:
>
> The description of Bessel_K functions in the Sage Cookbook is
> confusing about the order of the arguments.
> http://sagemath.org/doc/html/const/node96.html
> Here's what it says:
>
> >Here's an example using SAGE's interface to pari's special functions.
>
> >sage: pari('2+I').besselk(3)
> >0.04559077184075505871203211094 + 0.02891929465820812820828883526*I #
> >32-bit
> >0.045590771840755058712032110938791854704 +
> >0.028919294658208128208288835257608789842*I # 64-bit
> >sage: pari('2').besselk(3) # random
> >0.061510458471742038
>
> >The last command can also be executed using the SAGE command
>
> >sage: bessel_K(3,2)
> >0.647385390948634
> >sage: bessel_K(3,2,100)
> >0.64738539094863415315923557097
>
> But in fact the answer 0.061510458471742038 is correct, not random:
"Random" here doesn't mean what you think. All SAGE docs are
tested for correctness by an automatic testing program written by
William Stein. Since it is run on different machines, and different
machines give
slightly different round-off errors at the last few places, those last
few places are "random". Here "# random" is a key word that indicates
to the tester that the last few places are possibly different.
>
> sage: bessel_K(2,3)
> 0.0615104584717420
> sage: bessel_K(2,3,100)
> 0.061510458471742037656820071453
>
> I believe the confusion resulted because in earlier versions of Sage
> the order of arguments to
> bessel_K was backwards. For instance in Sage 2.8.5:
>
> sage: bessel_K(2,3)
> 0.647385390948634 # WRONG!!!
>
> Cheers,
>
> Peter
>
> >
>
--~--~-~--~~~---~--~~
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://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/
-~--~~~~--~~--~--~---
