Opened 5 years ago

Closed 5 years ago

#16224 closed defect (fixed)

incorrect translation of Bessel from Maxima?

Reported by: kcrisman Owned by:
Priority: major Milestone: sage-6.3
Component: calculus Keywords:
Cc: Merged in:
Authors: Nils Bruin Reviewers: Peter Bruin
Report Upstream: N/A Work issues:
Branch: dd3786f (Commits) Commit: dd3786ff9aa822efb8a5eebbc3fbee2e4c1d55fe
Dependencies: Stopgaps:

Description (last modified by kcrisman)

From this sage-support thread:

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.

(%i1) load(simplify_sum);
(%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.

Change History (11)

comment:1 Changed 5 years ago by kcrisman

  • Description modified (diff)

comment:2 Changed 5 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 5 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 5 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:

303a30btrac 16224: make sure maxima_lib knows about bessel functions.

comment:5 Changed 5 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.

Version 0, edited 5 years ago by nbruin (next)

comment:6 follow-up: Changed 5 years ago by git

  • Commit changed from 303a30b85353abde0e5e9f3d1b1ec0ae31b7b71e to b7f21d58b3a5bd58254e659e67aa947e166b5fd3

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

b7f21d5trac 16224: make max_to_sr look in sage.symbolic.pynac.symbol_table['maxima']

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

Replying to git:

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

b7f21d5trac 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 5 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:9 Changed 5 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

reviewer patch adds doctest


New commits:

303a30btrac 16224: make sure maxima_lib knows about bessel functions.
b7f21d5trac 16224: make max_to_sr look in sage.symbolic.pynac.symbol_table['maxima']
dd3786fTrac 16224: add doctest

comment:10 Changed 5 years ago by kcrisman

Thanks for both of your work!

comment:11 Changed 5 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.