# [Maxima] renaming undocumented Bessel functions g0, g1, gn

Stavros Macrakis macrakis at alum.mit.edu
Wed Aug 9 13:29:39 CDT 2006

```------=_Part_90652_21582006.1155148179225
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
>     Stavros> Maxima works best when there is a canonical representation of
> a mathematical
>     Stavros> concept.  That way, not only can all the knowledge about the
> concept itself
>     Stavros> be in one place, but all other concepts which interact with
> it only need to
>     Stavros> know one version.
>
> Yes, that makes perfect sense.  But how does this apply here?  Should
> we make scaled_bessel_i(n,x) be exp(-x)*bessel_i(n,x), so that the
> only difference would be if someone needed to evaluate it numerically
> for large args?
>
> And what does that say about bessel_i?  Should that be represented in
> terms of bessel_j?
>

Good point.  There are certainly many cases already where Maxima represents
basically the same concept in multiple ways.  gamma(x+1)=x!,
cos(x)=sin(x+%pi/2), cosh(x)=cos(%i*x), the exponential/log forms of
trig/arctrig, etc.

Maxima has various strategies for dealing with this.

One is to attempt to normalize the form in ordinary simplification (often
under flag control).  Thus, by default, cos(%i*x) simplifies to cosh(x),
sin(x+%pi/2) to cos(x), etc.  On the other hand, it is a very rough and
ready normalization: sin(x+%pi/3) and cos(x-%pi/6) do not simplify to the
same thing; same for cos(1+%i) and cosh(1-%i).

Another is to provide functions to convert to one form or another:
makefact/makegamma, exponentialize/logarc/demoivre.

Another is simply to let the user deal with it using function definitions or
pattern-matching transformations, possibly in load files.  Or simply to let
the user figure out tricks.  (To convert exponentials in x to hyperbolics,
use subst(x/%i,demoivre(subst(x*%i,x, EXPR ))) .)

None of these is perfect, and unfortunately their implementation in Maxima
tends to be patchy.  In the end, I suppose Maxima should follow standard
mathematical conventions, so if Bessel functions of the 1st, 2nd, and 3rd
forms are generally used, I guess we should have them, too.  But we should
probably also supply functions to normalize them to Bessel_i.

The scaled Bessel case for numeric evaluation in particular makes me
uncomfortable.  Maxima is not primarily a numeric system, but it should be
capable of doing numeric work when necessary.  The 'easy' answer is I
suppose to depend on bfloats, but that doesn't help the person who wants to
output Maxima expressions to Fortran for numeric calculation.  Would it be
possible to write code to reformat expressions in Bessel functions for
numeric calculation? Perhaps that is too ambitious....

-s

------=_Part_90652_21582006.1155148179225
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&nbsp;&nbsp;&nbsp; Stavros&gt; Maxima works best when there is a canonical representation of a mathematical
<br>&nbsp;&nbsp;&nbsp;&nbsp;Stavros&gt; concept.&nbsp;&nbsp;That way, not only can all the knowledge about the concept itself<br>&nbsp;&nbsp;&nbsp;&nbsp;Stavros&gt; be in one place, but all other concepts which interact with it only need to<br>&nbsp;&nbsp;&nbsp;&nbsp;Stavros&gt; know one version.
<br><br>Yes, that makes perfect sense.&nbsp;&nbsp;But how does this apply here?&nbsp;&nbsp;Should<br>we make scaled_bessel_i(n,x) be exp(-x)*bessel_i(n,x), so that the<br>only difference would be if someone needed to evaluate it numerically<br>
for large args?<br><br>And what does that say about bessel_i?&nbsp;&nbsp;Should that be represented in<br>terms of bessel_j?<br></blockquote></div><br>Good point.&nbsp; There are certainly many cases already where Maxima represents basically the same concept in multiple ways.&nbsp; gamma(x+1)=x!, cos(x)=sin(x+%pi/2), cosh(x)=cos(%i*x), the exponential/log forms of trig/arctrig, etc.
<br><br>Maxima has various strategies for dealing with this.<br><br>One is to attempt to normalize the form in ordinary simplification (often under flag control).&nbsp; Thus, by default, cos(%i*x) simplifies to cosh(x), sin(x+%pi/2) to cos(x), etc.&nbsp; On the other hand, it is a very rough and ready normalization: sin(x+%pi/3) and cos(x-%pi/6) do not simplify to the same thing; same for cos(1+%i) and cosh(1-%i).
<br><br>Another is to provide functions to convert to one form or another: makefact/makegamma, exponentialize/logarc/demoivre.<br><br>Another is simply to let the user deal with it using function definitions or pattern-matching transformations, possibly in load files.&nbsp; Or simply to let the user figure out tricks.&nbsp; (To convert exponentials in x to hyperbolics, use subst(x/%i,demoivre(subst(x*%i,x, EXPR ))) .)
<br><br>None of these is perfect, and unfortunately their implementation in Maxima tends to be patchy.&nbsp; In the end, I suppose Maxima should follow standard mathematical conventions, so if Bessel functions of the 1st, 2nd, and 3rd forms are generally used, I guess we should have them, too.&nbsp; But we should probably also supply functions to normalize them to Bessel_i.
<br><br>The scaled Bessel case for numeric evaluation in particular makes me uncomfortable.&nbsp; Maxima is not primarily a numeric system, but it should be capable of doing numeric work when necessary.&nbsp; The 'easy' answer is I suppose to depend on bfloats, but that doesn't help the person who wants to output Maxima expressions to Fortran for numeric calculation.&nbsp; Would it be possible to write code to reformat expressions in Bessel functions for numeric calculation? Perhaps that is too ambitious....
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -s<br><br>

------=_Part_90652_21582006.1155148179225--

```