On Axiom
JCA
Anybody got more than just superficial experience on Axiom?
On paper it looks very cool, but the hefty price tag that the guys
from NAG attach to it is somewhat off-putting.
Feedback is welcome.
Harald Hanche-Olsen
| In article <3943DBEA...@cs.berkeley.edu>, Richard Fateman
| <fat...@cs.berkeley.edu> wrote:
|
| > I don't know about Wolfram's ideal. He seems to be very happy
| > with Mathematica, which, so far as I can tell, does "mathematics
| > like a undergraduate physics student does."
|
| Physics students round here write sin x or maybe sin(x) , but not
| Sin[x] ...
I am sure Richard Fateman can speak for himself, but what I thought he
meant was doing mathematics by pattern matching.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- "There arises from a bad and unapt formation of words
a wonderful obstruction to the mind." - Francis Bacon
Richard Fateman
Well, that's one point, but here's another.
Ask a physics student to integrate x^n and one gets x^(n+1)/(n+1).
The mathematician (or someone who wants a strictly correct answer) might
object and say, "that's not right if n=-1".
The physics student might say "oh, that's a special case, I forgot about
it".
The mathematica program says (in effect) "Here's the answer. I'm not
guaranteeing it is the right answer, and it is up to you to check it
out."
The definite integration program works harder and gives answers that
may be more correct, but are dead ends. (see Integrate[x^n,{x,-a,a}], at
least
in version 3.0. It gives an answer that starts out If[a>0 && Re[n]>-1
,....]
Why a dead end? The only thing it seems one can do with that expression
is give values for a and n. If you (say) try to multiply it by n+1,
nothing
happens.
Also, a physics student used to be told (at least I was when I was
an undergraduate) some very rudimentary rules about combining
measurements.
e.g. don't carry more decimal digits than justified by the data.
If you use the same rules for internal arithmetic in a system like MMA
then
it is impossible to write an iterative n numerically convergent program.
Cheers.
Mayer Humi
>In article <3943DBEA...@cs.berkeley.edu>, Richard Fateman
><fat...@cs.berkeley.edu> wrote:
>
>Physics students round here write sin x or maybe sin(x) , but not
>Sin[x] ...
>
mma NOT to distinguish between caps and lower case characters?
I am not a typist...
(I assume this is something to be inserted in the ini file???)
Thanks MH.
Richard Fateman
Probably
sin=Sin
etc.
will do.
However it would not make
sin x or sin(x) the same as sin[x].
There is a palette-based input format for Mathematica, as well.
It is possible to come up with a more forgiving parser, and
by coincidence I think that Axiom may have one.
Heike Koch-Beuttenmueller
>
> Well, that's one point, but here's another.
> Ask a physics student to integrate x^n and one gets x^(n+1)/(n+1).
> The mathematician (or someone who wants a strictly correct answer) might
> object and say, "that's not right if n=-1".
> The physics student might say "oh, that's a special case, I forgot about
> it".
> The mathematica program says (in effect) "Here's the answer. I'm not
> guaranteeing it is the right answer, and it is up to you to check it
> out."
Okay , only Macsyma is doing this job as it would be correct.Neither
Axiom, nor Maple, Mathematica and Reduce.
> The definite integration program works harder and gives answers that
> may be more correct, but are dead ends. (see Integrate[x^n,{x,-a,a}], at
> least
> in version 3.0. It gives an answer that starts out If[a>0 && Re[n]>-1
> ,....]
>
> Why a dead end? The only thing it seems one can do with that expression
> is give values for a and n. If you (say) try to multiply it by n+1,
> nothing
> happens.
>
> Also, a physics student used to be told (at least I was when I was
> an undergraduate) some very rudimentary rules about combining
> measurements.
> e.g. don't carry more decimal digits than justified by the data.
> If you use the same rules for internal arithmetic in a system like MMA
> then
> it is impossible to write an iterative n numerically convergent program.
Here you will get only problems with Mathematica but not with the other
programs mentioned above.
Heike Koch-Beuttenmüller
=======================================================
Dr. Heike Koch-Beuttenmüller
Universität Ulm
Universitätsrechenzentrum
Albert-Einstein-Allee 11
D-89081 Ulm
Germany
e-mail: Heike.Koch-B...@rz.uni-ulm.de
Telefon: 0731 5022465
=======================================================
Heike Koch-Beuttenmueller
>
> Harald Hanche-Olsen wrote:
> >
> > + JCA <Jose_Caste...@hp.com>:
> >
> > | Anybody got more than just superficial experience on Axiom? On
> > | paper it looks very cool, but the hefty price tag that the guys from
> > | NAG attach to it is somewhat off-putting.
> >
> >
> > I had looked forward to seeing some responses to this query myself,
> > but if there are any Axiom users on this newsgroup, they seem oddly
> > reluctant to talk about it.
> >
> > Now I hate spreading unfounded rumour like I'm about to, but it might
> > be better than utter silence, particularly if it provokes someone more
> > knowledgable to either confirm or correct them. Just take the
> > following with a grain of salt, ok? (You should always do that with
> > what is told you on a newsgroup anyway; but I am asking you to double
> > the dose this time. Two grains of salt! No, a table spoon!)
> >
> > Basically, I've been told that maintenance of Axiom is either slow or
> > nonexistent, and also that the people at NAG have been rather
> > non-responsive to bug reports. This has frustrated my correspondent
> > no end.
> >
> > If true, this is a pity, for Axiom seems to me to have a very sound
> > design, coming much closer to Wolfram's ideal of ``doing mathematics
> > like a mathematician does'' than Mathematica.
>
> I don't know about Wolfram's ideal. He seems to be very happy with
> Mathematica, which, so far as I can tell, does "mathematics like
> a undergraduate physics student does."
>
> Who wants to sell software to mathematicians, anyway?
>
> The US government keeps track of various statistics. According to
> them there 14,000 mathematicians in the US in 1998, and another 20,000
> mathematics college teachers. See
>
> http://stats.bls.gov/oco/ocos043.htm
>
> It would not seem to be a fruitful market for a software vendor. There
> are more engineers. And I daresay that Axiom does not do mathematics
> like engineers, or like Mathematica.
>
> > It would probably be my
> > symbolic algebra system of choice if the price was right and the bugs
> > got ironed out. As it is, I for one would never spend the kind of
> > money they ask for it until and unless I read some positive reviews
> > from sources that I trust. And so far I haven't. (Actually, it's not
> > only a money issue; the time available for learning a new system is
> > also a scarce resource, maybe even more so.) It's a shame really.
Some years ago I gave an introductary short course for Mathematicians in
Axion compared with Maple. Those Mathematicians, especially Number
theorists where very impressed about Axioms facilities, like the elegant
factoring of the integers in a series expansion, defining a basis for
calculations as you want and so on.
But in real life they preferred to work with Maple or Mathematica.
As far as I now the Scratchpad developpers were very disappointed with
NAGs low support for Axiom. At the beginnung the support was greater,
but Axiom only ran on an IBM with at those times a lot of memory.
Altogether was incredible expansive compared to Computer systems
nowadays.
> Axiom's apparent lack of vendor support (The most recent user newsletter
> issue #3 is dated 1997) and apparently small user community
> is a problem. While other system vendors were adding applied mathematics
> features and ever fancier user interfaces, NAG was apparently
> waiting for customers.
JCA
Thanks everybody for their feedback. It seems to be the case though
most of us are in the same boat of uncertainty vis-a-vis Axiom. Which
is a shame, as I still believe that it should be better known and used
(certainly when compared to Mathematica, the Microsoft's Windows
of the CA world.)
graham
> Some years ago I gave an introductary short course for Mathematicians in
> Axion compared with Maple. Those Mathematicians, especially Number
> theorists where very impressed about Axioms facilities, like the elegant
> factoring of the integers in a series expansion, defining a basis for
> calculations as you want and so on.
>
> But in real life they preferred to work with Maple or Mathematica.
Do you know why they preferred to work with Maple or Mathematica
over Axiom?
graham
Richard B. Kreckel
: Richard Fateman wrote:
:>
:
:> Well, that's one point, but here's another.
:> Ask a physics student to integrate x^n and one gets x^(n+1)/(n+1).
:> The mathematician (or someone who wants a strictly correct answer) might
:> object and say, "that's not right if n=-1".
:> The physics student might say "oh, that's a special case, I forgot about
:> it".
:> The mathematica program says (in effect) "Here's the answer. I'm not
:> guaranteeing it is the right answer, and it is up to you to check it
:> out."
:
: Okay , only Macsyma is doing this job as it would be correct.Neither
: Axiom, nor Maple, Mathematica and Reduce.
I disagree. If I remember correctly, Macsyma asks you something like
"Is n equal -1? Please answer yes or no." I think for an interactive
system this is a valid approach but a system should try to keep an
internal tree of such decisions and return that one. The programmer
can later decide which branch to take or build that decision right
into the branching point for a production-program. Such
interactiveness makes a system completely unusable for many purposes.
So, Mathematica 3 did it right, however, it shouldn't run into a dead
end. Whether Macsyma allows this, I don't know.
I was recently criticized that GiNaC doesn't allow inclusion of such
branches, because it is not clear how the rank of the 2x2-matrix
[[ a, 1 ], [ a^2, 1 ]] should be evaluated. I was rather amused about
this. There is a border line you always draw somewhere, knowingly or
not. How is x-x supposed to be evaluated? 0? What if x is infinite?
It is all really a question about what can happen in your application.
Maybe a perfect system would carry all branches like the seemingly
trivial evaluation of x/x -> (x==0?1:indeterminate). Using such a
system in practice would then be a matter of cutting branches at the
decision tree by introducing assumptions and eventually reduce it to a
single branch. I would be happy about such a system but I fear that
a) I will never see one, b) others wouldn't be happy and c) it
wouldn't be too fast because of the potentially exponential growth of
such trees.
So we are stuck with choosing border lines. This is what all systems
are doing. The question is only whether the choice was a lucky one or
not. In my opinion, system manuals should educate the user about
these problems and not sweep them under the rug.
:> The definite integration program works harder and gives answers that
:> may be more correct, but are dead ends. (see Integrate[x^n,{x,-a,a}], at
:> least
:> in version 3.0. It gives an answer that starts out If[a>0 && Re[n]>-1
:> ,....]
Just for the record, with Mathematica 4 you don't get the If[ ... ]
anwer any more but directly -((-a)^(1+n)/(1+n))+(a^(1+n)/(1+n)).
First I thought there was something clever involved because
Integrate[x^n,{x,-1,1}] gives you 1/(1+n)+(-1)^n/(1+n)-0^(1+n)/(1+n)
but I soon realized that it was still impossible to later take any
substitutions in this expressions because the individual terms are
either infinite or indeterminate. :-(
:> Why a dead end? The only thing it seems one can do with that expression
:> is give values for a and n. If you (say) try to multiply it by n+1,
:> nothing happens.
:>
:> Also, a physics student used to be told (at least I was when I was
:> an undergraduate) some very rudimentary rules about combining
:> measurements.
Physicists work around such problems and soon forget about them. This
may explain why Form, a system used heavily by some Quantum Field
theorists readily simplifies 0^a to a^3. :-(
:> e.g. don't carry more decimal digits than justified by the data.
:> If you use the same rules for internal arithmetic in a system like MMA
:> then
:> it is impossible to write an iterative n numerically convergent program.
: Here you will get only problems with Mathematica but not with the other
: programs mentioned above.
Could you please elaborate on that? This statement of Richard Fateman
was a statement about physics students and I don't see how it applies
to Mathematica or any other system.
Regards
-richy.
--
Richard Kreckel, <kre...@ginac.de>, <http://www.ginac.de/~kreckel/>
Richard Fateman
"Richard B. Kreckel" wrote:
>
> Heike Koch-Beuttenmueller wrote:
> : Richard Fateman wrote:
> :>
> :
> :> Well, that's one point, but here's another.
> :> Ask a physics student to integrate x^n and one gets x^(n+1)/(n+1).
> :> The mathematician (or someone who wants a strictly correct answer) might
> :> object and say, "that's not right if n=-1".
> :> The physics student might say "oh, that's a special case, I forgot about
> :> it".
> :> The mathematica program says (in effect) "Here's the answer. I'm not
> :> guaranteeing it is the right answer, and it is up to you to check it
> :> out."
> :
> : Okay , only Macsyma is doing this job as it would be correct.Neither
> : Axiom, nor Maple, Mathematica and Reduce.
>
> I disagree. If I remember correctly, Macsyma asks you something like
> "Is n equal -1? Please answer yes or no."
I just tried it. It asks
"Is n+1 zero or nonzero"
> I think for an interactive
> system this is a valid approach but a system should try to keep an
> internal tree of such decisions and return that one. The programmer
> can later decide which branch to take or build that decision right
> into the branching point for a production-program. Such
> interactiveness makes a system completely unusable for many purposes.
The solution used by Macsyma is to allow you to make assumptions
beforehand.
For example, assume(n>1); integrate(x^n,x); does not ask the user
anything. (Both Maple and Mathematica now have rudimentary "assume"
facilities. Macsyma's is, I think, more elaborate, but I don't have
first
hand experience with Mma 4.0).
Sometimes Macsyma figures things out, like
integrate(x^(sin(r)^2),x) ... it knows sin(r)^2 is > -1 so it doesn't
ask.
Macsyma makes mistakes sometimes, e.g. sum(x^i,i,-n,n).
Then substituting x=0 returns 0.
Mma (3.0) responds with -0^(-n)*(-1+0^(1+2n)).
I don't know what one is supposed to do with that, but
multiplying by 0^n and then adding O^(1+2n), each of which is arguably
zero, results in 1. I suppose I could report this to WRI or to
the mathematica (moderated) newsgroup, but this usually leads
nowhere.
> So, Mathematica 3 did it right,
I suppose we can agree to differ on this.
> however, it shouldn't run into a dead
> end. Whether Macsyma allows this, I don't know.
>
> I was recently criticized that GiNaC doesn't allow inclusion of such
> branches, because it is not clear how the rank of the 2x2-matrix
> [[ a, 1 ], [ a^2, 1 ]] should be evaluated. I was rather amused about
> this. There is a border line you always draw somewhere, knowingly or
> not. How is x-x supposed to be evaluated? 0? What if x is infinite?
>
> It is all really a question about what can happen in your application.
> Maybe a perfect system would carry all branches like the seemingly
> trivial evaluation of x/x -> (x==0?1:indeterminate).
This particular example may be resolved by saying the calculations
are being done in an abstract field, in which x/x =1; the valuation
x=0 should not affect that. If you apply valuations first (as in the
sum example above) the results may not be as expected.
Using such a
> system in practice would then be a matter of cutting branches at the
> decision tree by introducing assumptions and eventually reduce it to a
> single branch. I would be happy about such a system but I fear that
> a) I will never see one, b) others wouldn't be happy and c) it
> wouldn't be too fast because of the potentially exponential growth of
> such trees.
This kind of thing has been suggested in the past (by me, among others),
and a simplifier in the context of Macsyma was produced to pay attention
to branches. The required theorem-proving to get branches to re-join
is substantial. The theorem-proving community can't help much here, or
at least they haven't to date. The
computational geometry community might have a clue.
>
> So we are stuck with choosing border lines. This is what all systems
> are doing. The question is only whether the choice was a lucky one or
> not.
In my opinion, computer algebra systems should not depend on the user
not encountering singularities. That's often exactly where the interest
lies.
> In my opinion, system manuals should educate the user about
> these problems and not sweep them under the rug.
Certainly, but since most people do not read the manual, this will not
help much.
When you find a bug, do you want to be told, "Oh, we know about that
bug. It is in the manual."?
>
> :> The definite integration program works harder and gives answers that
> :> may be more correct, but are dead ends. (see Integrate[x^n,{x,-a,a}], at
> :> least
> :> in version 3.0. It gives an answer that starts out If[a>0 && Re[n]>-1
> :> ,....]
>
> Just for the record, with Mathematica 4 you don't get the If[ ... ]
> anwer any more but directly -((-a)^(1+n)/(1+n))+(a^(1+n)/(1+n)).
> First I thought there was something clever involved because
> Integrate[x^n,{x,-1,1}] gives you 1/(1+n)+(-1)^n/(1+n)-0^(1+n)/(1+n)
> but I soon realized that it was still impossible to later take any
> substitutions in this expressions because the individual terms are
> either infinite or indeterminate. :-(
So Mma 4.0 took a step backward and
is inferior to Mma 3.0?
>
> :> Why a dead end? The only thing it seems one can do with that expression
> :> is give values for a and n. If you (say) try to multiply it by n+1,
> :> nothing happens.
> :>
> :> Also, a physics student used to be told (at least I was when I was
> :> an undergraduate) some very rudimentary rules about combining
> :> measurements.
>
> Physicists work around such problems and soon forget about them. This
> may explain why Form, a system used heavily by some Quantum Field
> theorists readily simplifies 0^a to a^3. :-(
>
I guess if you want to have an automatic mathematical assistant that
you have to "work around" and "correct" then this is OK. Personally
I'd like to feel more confident in the computer program. for example
that the program is correct by construction.
....
> :> e.g. don't carry more decimal digits than justified by the data.
> :> If you use the same rules for internal arithmetic in a system like MMA
> :> then
> :> it is impossible to write an iterative numerically convergent program.
> : Here you will get only problems with Mathematica but not with the other
> : programs mentioned above.
>
> Could you please elaborate on that? This statement of Richard Fateman
> was a statement about physics students and I don't see how it applies
> to Mathematica or any other system.
>
OK, try to explain this. (I did it in Mma 3.0)
x=1.11111111111111111111
Do[x=2*x-x,{30}]
If[x==x+1,"Mathematica fundamentally alters the mechanics of
mathematics"]
(* for those of you without mathematica, what this seems to do is
set x to itself 30 times. (really x := 2*x-x). Then it asks if
x is the same value as x+1.
Oddly enough, mathematica 3.0 thinks that these two numbers are equal.
By the way, the quote is from the back cover of one of the MMa books.
It is a quote from the New York Times.
*)
Cheers,
RJF
Richard B. Kreckel
[...]
: In my opinion, computer algebra systems should not depend on the user
: not encountering singularities. That's often exactly where the interest
: lies.
Maybe one could make up a rigorous definition of what I called "border
lines" out of this?
[...]
: OK, try to explain this. (I did it in Mma 3.0)
:
: x=1.11111111111111111111
:
: Do[x=2*x-x,{30}]
:
: If[x==x+1,"Mathematica fundamentally alters the mechanics of mathematics"]
Dios mío! I remember such things from your old paper "Review of
Mathematica". I thought they were fixed by now. I see it is still
present in Mma 4.0, though I have to go to 44 repetitions (which may
be platform-dependend).
It always worries me if a system wants to be more clever than the user /
the programmer / me.
Regards
-richy.
--
Richard Kreckel
<Richard...@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
graham
> graham wrote:
> > Do you know why they preferred to work with Maple or Mathematica
> > over Axiom?
> computer and it was more comfortable for Axiom to use it directly and
> not over a network,but the users preferred to work in the net. I think
> the next reason was, that it was not so easy to start with Axiom. You
> must know a lot of Axioms data types which lateron is very useful, but
> at the beginning is very theoretical. For engineers, for example Maple
> and Mathematica and Macsyma offer more functions etc. which are needed
> for their work and they are not so accustomed to think about the data
> types as pure mathematicians, may-be.
This is a little unfortunate since it's precisely these Axiom "data
types" which allow Axiom programs to scale from small to large, and
do not allow Maple/Mathematica ones to scale.
graham
Heike Koch-Beuttenmueller
>
> Heike Koch-Beuttenmueller wrote:
> > Some years ago I gave an introductary short course for Mathematicians in
> > Axion compared with Maple. Those Mathematicians, especially Number
> > theorists where very impressed about Axioms facilities, like the elegant
> > factoring of the integers in a series expansion, defining a basis for
> > calculations as you want and so on.
> >
>
> Do you know why they preferred to work with Maple or Mathematica
> over Axiom?
>
Oh, at the beginning one reason was , that they had to use a special
computer and it was more comfortable for Axiom to use it directly and
not over a network,but the users preferred to work in the net. I think
the next reason was, that it was not so easy to start with Axiom. You
must know a lot of Axioms data types which lateron is very useful, but
at the beginning is very theoretical. For engineers, for example Maple
and Mathematica and Macsyma offer more functions etc. which are needed
for their work and they are not so accustomed to think about the data
types as pure mathematicians, may-be.
Heike Koch-Beuttenmueller
> : not encountering singularities. That's often exactly where the interest
> : lies.
>
> lines" out of this?
>
> [...]
> :
> : x=1.11111111111111111111
> :
> : Do[x=2*x-x,{30}]
> :
> : If[x==x+1,"Mathematica fundamentally alters the mechanics of mathematics"]
>
> Mathematica". I thought they were fixed by now. I see it is still
> present in Mma 4.0, though I have to go to 44 repetitions (which may
> be platform-dependend).
>
> It always worries me if a system wants to be more clever than the user /
> the programmer / me.
numerically calculates with 310 Digits a number in a loop about 200
times. The numeric is so good, that after 200 loops only the last 3
digits are wrong. I tested this program with Maple, Axiom, Macsyma,
Reduce and Mathematica over years , because it was interesting to see
the speed-up or slow-down of the CASs and the computers. Only
Mathematica told me: Oh, only 220 digits are correct and printed them. I
needed a very long time until I found these remarks in the Mathematica
Handbook that MMa decides for the user how much Digits of the result are
correct.
Regards,
Michael Wester
>Heike Koch-Beuttenmueller wrote:
>> graham wrote:
>> > over Axiom?
>> computer and it was more comfortable for Axiom to use it directly and
>> not over a network,but the users preferred to work in the net. I think
>> the next reason was, that it was not so easy to start with Axiom. You
>> must know a lot of Axioms data types which lateron is very useful, but
>> at the beginning is very theoretical. For engineers, for example Maple
>> and Mathematica and Macsyma offer more functions etc. which are needed
>> for their work and they are not so accustomed to think about the data
>> types as pure mathematicians, may-be.
>
>types" which allow Axiom programs to scale from small to large, and
>do not allow Maple/Mathematica ones to scale.
Another problem is that although Axiom works very well with polynomials and
rational functions, it is quite a bit more difficult to work with trig and
special functions, for example (often needed by people doing applications).
One often uses the generic category "Expression Integer" and loses any
advantages associated with data typing.
And yet another problem is simplification. Here is an interesting example:
integrate(integrate(sqrt(x**2 + y**2), x = 0..1), y = 0..1)
There are 11 exposed and 7 unexposed library operations named
integrate having 2 argument(s) but none was determined to be
applicable. Use HyperDoc Browse, or issue
)display op integrate
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.
Cannot find a definition or applicable library operation named
integrate with argument type(s)
Union(f1: OrderedCompletion Expression Integer,f2: List OrderedCompletion Expres
sion Integer,fail: failed,pole: potentialPole)
SegmentBinding NonNegativeInteger
-- Note that the error message is difficult to interpret for an inexperienced
-- user. Let's try again:
integrate(integrate(sqrt(x**2 + y**2), x = 0..1, "noPole"), y = 0..1, "noPole")
(5)
+-+ +-+ +-+ +-+ +-+
(- 4\|2 + 6)log(- 2\|2 + 3) + (- 2\|2 + 3)log(- 12\|2 + 17) - 24\|2 + 32
-----------------------------------------------------------------------------
+-+
48\|2 - 72
Type: Union(f1: OrderedCompletion Expression Integer,...)
Time: 0.10 (IN) + 6.17 (EV) + 0.03 (OT) + 0.03 (GC) = 6.33 sec
(I did this in Axiom 2.1) Well, the answer I expected was:
log(sqrt(2) + 1) + sqrt(2)
--------------------------
3
I could not get my answer using any combination of simplify, normalize,
complexNormalize, etc. or even into anything close to the form I wanted. To
be fair, Macsyma, Maple, Mathematica, MuPAD and Reduce couldn't do it either.
Only Derive (a small system by comparison to the others) succeeded. So here
Axiom generatd a correct but very messy answer and no easy way to simplify it
to something more manageable. This is not unique to Axiom, but I found it
difficult to massage expressions, which is easier to do in some of the other
systems. But Axiom sure is fast on certain polynomial/rational calculations.
--
Michael Wester --- wes...@math.unm.edu --- http://math.unm.edu/~wester/
| ``That may be true,'' he acknowledged, ``but it's completely accurate, and as
| long as the answer is right, who cares if the question is wrong? If you want
| sense, you'll have to make it yourself.'' -- "The Phantom Tollbooth": Juster
Simon Langley
MuPAD had object orientation, overloading and dynamic creation of data
domains etc. It isn't as comprehensive as Axiom and only a relatively
small number of domains have been set up - but I do find it reasonably easy
to use. And it's cheap.
Simon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Simon Langley
Email: Simon....@uwe.ac.uk
University of the West of England
Bristol BS16 1QY
England
graham
> JCA wrote:
> > Thanks everybody for their feedback. It seems to be the case though
> > most of us are in the same boat of uncertainty vis-a-vis Axiom. Which
> > is a shame, as I still believe that it should be better known and used
> > (certainly when compared to Mathematica, the Microsoft's Windows
> > of the CA world.)
>
> MuPAD had object orientation, overloading and dynamic creation of data
> domains etc. It isn't as comprehensive as Axiom and only a relatively
> small number of domains have been set up - but I do find it reasonably easy
> to use. And it's cheap.
As far as I remember MuPad is dynamically typed and Axiom is (for the
most part) statically typed. I think Axiom's static typing contributes
to
scalability of code in Axiom -- so I like it's static typing. But my guess
is that the predominant view among computer algebra users is that static
typing is a pain, and that types "don't matter". Comments?
graham
Heike Koch-Beuttenmueller
> As far as I remember MuPad is dynamically typed and Axiom is (for the
> most part) statically typed. I think Axiom's static typing contributes
> to
> scalability of code in Axiom -- so I like it's static typing. But my guess
> is that the predominant view among computer algebra users is that static
> typing is a pain, and that types "don't matter". Comments?
The problem is , That a lot of users don't think about types wondering
why the get no results.
Now Maple has introduced assume to manage some types, etc.
But some hacking, may-be you call it fast prototyping, is liked more by
a great amount of users Than painful old-fashioned analyzing of
problems, including some thinking. ?
>
> graham
Heike Koch-Beuttenmüller
Paul Abbott
<Richard...@Uni-Mainz.DE> wrote:
> Just for the record, with Mathematica 4 you don't get the If[ ... ]
> anwer any more but directly -((-a)^(1+n)/(1+n))+(a^(1+n)/(1+n)).
> First I thought there was something clever involved because
> Integrate[x^n,{x,-1,1}] gives you 1/(1+n)+(-1)^n/(1+n)-0^(1+n)/(1+n)
> but I soon realized that it was still impossible to later take any
> substitutions in this expressions because the individual terms are
> either infinite or indeterminate. :-(
BTW, there is a little documented option, useful for such integrals:
Integrate[x^n,{x,-1,0,1}]
Cheers,
Paul
Richard B. Kreckel
[...]
: BTW, there is a little documented option, useful for such integrals:
:
: Integrate[x^n,{x,-1,0,1}]
It is so little documented I am unable to find it. It merely seems to
integrate piecewise. Using Mma3 or Mma4 gives me:
In[1]:= Integrate[x^n,{x,-1,1}]
n 1 + n
1 (-1) 0
Out[1]= ----- + ----- - ------
1 + n 1 + n 1 + n
In[2]:= Integrate[x^n,{x,-1,0,1}]
1 n
Out[2]= If[Re[n] > -1, -----, Integrate[x , {x, 0, 1}]] +
1 + n
n
(-1) n
> If[Re[n] > -1, -----, Integrate[x , {x, -1, 0}]]
1 + n
Which is the same as Integrate[x^n,{x,-1,0}]+Integrate[x^n,{x,0,1}].
In any case, Mathematica doesn't seem to be able to do anything useful
with this result.