Opened 11 years ago

Closed 6 years ago

# implement fricas integrator

Reported by: Owned by: whuss burcin major sage-6.5 symbolics integrate, fricas hemmecke Wilfried Huss, Frédéric Chapoton Burcin Erocal, Ralf Stephan N/A c5bd849 c5bd849b92b6a4ff3526218e9fb5817414dae60d

### Description

The attached patch adds the option algorithm="fricas" to the integrate command.

### comment:1 Changed 11 years ago by whuss

• Status changed from new to needs_review

### comment:2 follow-ups: ↓ 3 ↓ 17 Changed 11 years ago by burcin

• Authors changed from whuss to Wilfried Huss
• Reviewers set to Burcin Erocal
• Status changed from needs_review to needs_work

This looks great. Thanks for the quick patch!

I have a few minor comments:

• the conversion of different infinities on line 95-103 should be moved to the _fricas_init_() method of the corresponding classes. Then this would work:
sage: infinity._fricas_init_()
"%plusInfinity"

and we can just do af = a._fricas_().
• Similarly, I suggest moving the code for converting the result back to the _sage_() method of the fricas interface.

### comment:3 in reply to: ↑ 2 ; follow-up: ↓ 6 Changed 11 years ago by whuss

• the conversion of different infinities on line 95-103 should be moved to the _fricas_init_() method of the corresponding classes. Then this would work:
sage: infinity._fricas_init_()
"%plusInfinity"

I tried this (see fricas_infinity.patch), but for some reason that I don't understand the output of _fricas_init_() changes into something which is not a valid fricas expression.

sage: oo._fricas_init_()
'%plusInfinity'

but

sage: oo._fricas_()
+ infinity

I have no idea what is going on here.

### comment:4 follow-ups: ↓ 5 ↓ 14 Changed 11 years ago by drkirkby

Is "algorithm" the most appropiate word here? To me, Fricas, Aximom, Maxima etc are software packages, not algorithms. They implement many differerent algorithms.

I'm not a mathmatician, but certainly my mathematical training would never have suggested that Fricas was an algorithm.

I would have thought something like

integrate(f(x), x, use="fricas")
integrate(f(x), x, software="fricas")
integrate(f(x), x, method="fricas")

would be better than

integrate(f(x), x, algorithm="fricas")

I don't claim any of my choices are optimal, but I think all of them are better than "algorithm".

Dave

### comment:5 in reply to: ↑ 4 Changed 11 years ago by whuss

If I do

sage: search_def('algorithm=')

I get 150 results. So the 'algorithm' convention is widely used in Sage, I don't think it makes sense to change this at this point.

### comment:6 in reply to: ↑ 3 Changed 10 years ago by burcin

• Milestone changed from sage-4.7 to sage-4.7.1

• the conversion of different infinities on line 95-103 should be moved to the _fricas_init_() method of the corresponding classes. Then this would work:
sage: infinity._fricas_init_()
"%plusInfinity"

I tried this (see fricas_infinity.patch), but for some reason that I don't understand the output of _fricas_init_() changes into something which is not a valid fricas expression.

sage: oo._fricas_init_()
'%plusInfinity'

but

sage: oo._fricas_()
+ infinity

I have no idea what is going on here.

This seems to be how fricas prints %plusInfinity. Ralf, can you help us with this?

### comment:7 Changed 10 years ago by hemmecke

Well, not quite right, as http://axiom-wiki.newsynthesis.org/PerCent shows. I've added

)set output algebra on

in order to also show the ascii output. Otherwise mathaction renders tex output of axiom. These things starting with a percent sign are only used for input. What exactly gets printed depends on the ')set output' settings.

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

Also look at the exports of OrderedCompletion?. https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/complet.spad.pamphlet#L20 Obviously also 'plusInfinity()' and 'minusInfinity()' could be used as input.

The output is constructed in https://github.com/hemmecke/fricas-svn/blob/master/src/algebra/complet.spad.pamphlet#L59 How the symbol infinity appears is hidden inside OutputForm? and probably deeper.

)set output tex on
(1) -> plusInfinity()

(1)   + infinity
$$+\infty \leqno(1)$$

Type: OrderedCompletion(Integer)

### comment:9 Changed 10 years ago by burcin

So the ascii output for plusInfinity is "+ infinity" and the _fricas_init_() method in attachment:fricas_infinity.patch works as intended.

Wilfried, will you have time to revise the patch? Note that when #9880 is merged (almost) all symbolics patches will need to be rebased.

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

• Milestone changed from sage-5.11 to sage-5.12

### comment:11 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:12 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

### comment:13 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.3 to sage-6.4

### comment:14 in reply to: ↑ 4 ; follow-up: ↓ 16 Changed 6 years ago by vdelecroix

Is "algorithm" the most appropiate word here? To me, Fricas, Aximom, Maxima etc are software packages, not algorithms. They implement many differerent algorithms.

I'm not a mathmatician, but certainly my mathematical training would never have suggested that Fricas was an algorithm.

I would have thought something like

integrate(f(x), x, use="fricas")
integrate(f(x), x, software="fricas")
integrate(f(x), x, method="fricas")

would be better than

integrate(f(x), x, algorithm="fricas")

I don't claim any of my choices are optimal, but I think all of them are better than "algorithm".

+1 for use, software or library Moreover, in some situation, when we call the software (fricas, maxima, ...) we might want to feed it with an option algorithm.

Vincent

### comment:15 Changed 6 years ago by chapoton

• Branch set to public/ticket/9427
• Commit set to 5db022485af30f54242c3c1dcb2c0622d09b13e8

I have made a git branch with the attached files, rebased on 6.5.b2

New commits:

 ​2b719db Implement algorithm="fricas" for integration ​5db0224 convert infinities to fricas

### comment:16 in reply to: ↑ 14 Changed 6 years ago by rws

Moreover, in some situation, when we call the software (fricas, maxima, ...) we might want to feed it with an option algorithm.

First I agreed with this, but now I think it would be easy to allow something like algorithm=fricas-risch, and this would then be more convenient than software=fricas,algorithm=risch. Whereas changing algorithm to software would be annoying as hell.

### comment:17 in reply to: ↑ 2 Changed 6 years ago by rws

• Similarly, I suggest moving the code for converting the result back to the _sage_() method of the fricas interface.

I know this is how Sympy does it but I think such a decision is up to the Fricas developers.

### comment:18 Changed 6 years ago by git

• Commit changed from 5db022485af30f54242c3c1dcb2c0622d09b13e8 to c5bd849b92b6a4ff3526218e9fb5817414dae60d

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

 ​25820dc Merge branch 'develop' into t/9427/public/ticket/9427 ​c5bd849 9427 reviewer's patch: fix doctest

### comment:19 Changed 6 years ago by rws

• Authors changed from Wilfried Huss to Wilfried Huss, Frédéric Chapoton
• Reviewers changed from Burcin Erocal to Burcin Erocal, Ralf Stephan
• Status changed from needs_work to needs_review

This looks good and tests OK in symbolic and rings.

### comment:20 Changed 6 years ago by rws

• Status changed from needs_review to positive_review

### comment:21 Changed 6 years ago by rws

• Milestone changed from sage-6.4 to sage-6.5

### comment:22 Changed 6 years ago by vbraun

• Branch changed from public/ticket/9427 to c5bd849b92b6a4ff3526218e9fb5817414dae60d
• Resolution set to fixed
• Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.