Opened 9 years ago
Closed 5 years ago
#9427 closed enhancement (fixed)
implement fricas integrator
Reported by: | whuss | Owned by: | burcin |
---|---|---|---|
Priority: | major | Milestone: | sage-6.5 |
Component: | symbolics | Keywords: | integrate, fricas |
Cc: | hemmecke | Merged in: | |
Authors: | Wilfried Huss, Frédéric Chapoton | Reviewers: | Burcin Erocal, Ralf Stephan |
Report Upstream: | N/A | Work issues: | |
Branch: | c5bd849 (Commits) | Commit: | c5bd849b92b6a4ff3526218e9fb5817414dae60d |
Dependencies: | Stopgaps: |
Description
The attached patch adds the option algorithm="fricas" to the integrate command.
Attachments (2)
Change History (24)
Changed 9 years ago by
comment:1 Changed 9 years ago by
- Status changed from new to needs_review
comment:2 follow-ups: ↓ 3 ↓ 17 Changed 9 years ago by
- Reviewers set to Burcin Erocal
- Status changed from needs_review to needs_work
Changed 9 years ago by
comment:3 in reply to: ↑ 2 ; follow-up: ↓ 6 Changed 9 years ago by
Replying to burcin:
- 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 9 years ago by
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 9 years ago by
Replying to drkirkby:
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 9 years ago by
- Cc hemmecke added
- Milestone changed from sage-4.7 to sage-4.7.1
Replying to whuss:
Replying to burcin:
- 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_() + infinityI 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 9 years ago by
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 9 years ago by
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 9 years ago by
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 6 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:11 Changed 6 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:12 Changed 6 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:13 Changed 5 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:14 in reply to: ↑ 4 ; follow-up: ↓ 16 Changed 5 years ago by
Replying to 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".
+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 5 years ago by
- Branch set to public/ticket/9427
- Commit set to 5db022485af30f54242c3c1dcb2c0622d09b13e8
comment:16 in reply to: ↑ 14 Changed 5 years ago by
Replying to vdelecroix:
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 5 years ago by
Replying to burcin:
- 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 5 years ago by
- Commit changed from 5db022485af30f54242c3c1dcb2c0622d09b13e8 to c5bd849b92b6a4ff3526218e9fb5817414dae60d
comment:19 Changed 5 years ago by
- 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 5 years ago by
- Status changed from needs_review to positive_review
comment:21 Changed 5 years ago by
- Milestone changed from sage-6.4 to sage-6.5
comment:22 Changed 5 years ago by
- Branch changed from public/ticket/9427 to c5bd849b92b6a4ff3526218e9fb5817414dae60d
- Resolution set to fixed
- Status changed from positive_review to closed
This looks great. Thanks for the quick patch!
I have a few minor comments:
_fricas_init_()
method of the corresponding classes. Then this would work: and we can just do af = a._fricas_()._sage_()
method of the fricas interface.