Opened 8 years ago

Closed 8 years ago

# incorrect translation of Bessel from Maxima?

Reported by: Owned by: kcrisman major sage-6.3 calculus Nils Bruin Peter Bruin N/A dd3786f dd3786ff9aa822efb8a5eebbc3fbee2e4c1d55fe

```But other sums are simply wrong.

k = var('k')
sum(x^(2*k)/factorial(2*k),k,0,oo)

gives

-1/4*sqrt(2)*sqrt(pi)*x^(3/2)

but the answer should be sinh(x).

Hmm.  That shouldn't be happening, though I wouldn't be surprised if it didn't turn out as easy as that.

(%o1) /Users/.../Sage-5.12-OSX-64bit-10.6.app/Contents/Reso\
urces/sage/local/share/maxima/5.29.1/share/solve_rec/simplify_sum.mac
(%i3) display2d:false;

(%o3) false
(%i4) simplify_sum(sum(x^(2*k)/factorial(2*k),k,0,inf));

(%o4) sqrt(%pi)*bessel_i(-1/2,x)*sqrt(x)/sqrt(2)

So I'm not sure why that would happen - maybe because of incorrect Bessel simplification?

sage: maxima_calculus('bessel_i(-1/2,x)')
bessel_i(-1/2,x)
sage: _._sage_()
sqrt(2)*sqrt(1/(pi*x))*cosh(x)

That gives cosh(x), which I think is what you meant.
```

I don't know why this would happen, but presumably it should be possible to track down without too much effort.

### comment:1 Changed 8 years ago by kcrisman

• Description modified (diff)

### comment:2 Changed 8 years ago by nbruin

It's a problem in the automatic translation learning for `max_to_sr`. If we force it to learn about Bessel functions beforehand, there's no problem:

```sage: var('k')
k
sage: sum(bessel_I(2,x),k,1,10)
10*bessel_I(2, x)
sage: sum(x^(2*k)/factorial(2*k),k,0,oo)
sqrt(pi)*sqrt(x)*sqrt(1/(pi*x))*cosh(x)
sage: from sage.interfaces.maxima_lib import *
sage: sage_op_dict[operator.mul] #as it should be
<ECL: MTIMES>
```

On the other hand, in a fresh session:

```sage: var('k')
k
sage: sum(x^(2*k)/factorial(2*k),k,0,oo)
-1/4*sqrt(2)*sqrt(pi)*x^(3/2)
sage: from sage.interfaces.maxima_lib import *
sage: sage_op_dict[operator.mul]
<ECL: %BESSEL_I>
```

The problem is that the `bessel_I(-1/2,x)` gets immediately rewritten to another expression, so the default heuristics for `max_to_sr` fail. The remedy: initialize the translation of `%BESSEL_I`. This consists simply of adding the line

```    sage.functions.bessel.bessel_I: "%BESSEL_I",
```

to sage_op_dict in sage/interfaces/maxima_lib.py

### comment:3 Changed 8 years ago by nbruin

• Branch set to u/nbruin/ticket/16224
• Created changed from 04/24/14 01:37:35 to 04/24/14 01:37:35
• Modified changed from 04/24/14 03:12:12 to 04/24/14 03:12:12

### comment:4 Changed 8 years ago by nbruin

• Authors set to Nils Bruin
• Commit set to 303a30b85353abde0e5e9f3d1b1ec0ae31b7b71e
• Status changed from new to needs_review

OK, this should do the trick. I've also made the routines produce an error rather than corrupt the dictionaries. That should make diagnosing such problems a little easier in the future.

If someone wants to add a doctest for this somewhere, go ahead.

New commits:

 ​303a30b `trac 16224: make sure maxima_lib knows about bessel functions.`

### comment:5 Changed 8 years ago by nbruin

On second thought we can probably do better than having to register all this in two spots:sage:

```sage: bessel_I._maxima_()
bessel_i
sage: tbl=sage.symbolic.pynac.symbol_table['maxima']
sage: tbl['bessel_i']
bessel_I
```

so the information is there already. We should just let `sr_to_max` and `max_to_sr` look in those spots before reverting to just converting strings back and forth and trying to guess the appropriate symbols from that. That would provide an extra level and would mean that functions like `bessel_I` that are spelled differently in `maxima` and/or get rewritten can be converted without entering their translations in another spot.

Last edited 8 years ago by nbruin (previous) (diff)

### comment:6 follow-up: ↓ 7 Changed 8 years ago by git

• Commit changed from 303a30b85353abde0e5e9f3d1b1ec0ae31b7b71e to b7f21d58b3a5bd58254e659e67aa947e166b5fd3

Branch pushed to git repo; I updated commit sha1. New commits:

 ​b7f21d5 `trac 16224: make max_to_sr look in sage.symbolic.pynac.symbol_table['maxima']`

### comment:7 in reply to: ↑ 6 Changed 8 years ago by nbruin

Branch pushed to git repo; I updated commit sha1. New commits:

 ​b7f21d5 `trac 16224: make max_to_sr look in sage.symbolic.pynac.symbol_table['maxima']`

This should do a much more programmatic and hence more reliable job than forcing people to register the same information in yet another spot.

### comment:8 Changed 8 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

### comment:9 Changed 8 years ago by pbruin

• Branch changed from u/nbruin/ticket/16224 to u/pbruin/16224-maxima_to_sage
• Commit changed from b7f21d58b3a5bd58254e659e67aa947e166b5fd3 to dd3786ff9aa822efb8a5eebbc3fbee2e4c1d55fe
• Reviewers set to Peter Bruin
• Status changed from needs_review to positive_review

New commits:

 ​303a30b `trac 16224: make sure maxima_lib knows about bessel functions.` ​b7f21d5 `trac 16224: make max_to_sr look in sage.symbolic.pynac.symbol_table['maxima']` ​dd3786f `Trac 16224: add doctest`

### comment:10 Changed 8 years ago by kcrisman

Thanks for both of your work!

### comment:11 Changed 8 years ago by vbraun

• Branch changed from u/pbruin/16224-maxima_to_sage to dd3786ff9aa822efb8a5eebbc3fbee2e4c1d55fe
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.