Read here. It is for  Windows.

If your operating  system is Linux, I guess that acer's code should work straight away.

Read here. It is for  Windows.

If your operating  system is Linux, I guess that acer's code should work straight away.

For use on Windows I have downloaded the gsl package from the GnuWin32 project page , unpacked it, placed libgsl.dll in a suitable directory and just changed 'LIB' to point to this directory

LIB="c:/.../libgsl.dll"

The rest is just cut and paste the acer's code (very interesting!). Thus I have got quite similar results (Win XP 32 bits, Intel(R) Pentium(R) 4 CPU 3.00GHz (2 CPUs), gsl-1.8):

...
oparam:=50001:
...

 time()-st,kernelopts(bytesalloc)-ba,kernelopts(bytesused)-bu;
                      4.342, 25947504, 56464908

solR+I*solI;
                              -7                          -7
       0.318175350197958166 10   - 0.779830112408353734 10   I

Find here a Maple 11 Classical worksheet with this Windows version of the acer's calculation:

 Download 143_acer-method-win.mws

Except, perhaps, for the small numerical differences (and timings?) with the Linux version I do not know whether there is something else to remark from this worksheet.

I wonder which other special functions, besides 'BesselJ' would profit significantly from this use of external calling in numerical calculations.

Moved here

Moved here

Find here a Maple 11 Classical worksheet with this Windows version of the acer's calculation:

 Download 143_acer-method-win.mws

 Except, perhaps, for the small numerical differences I do not know whether there is something else to remark here.

And excuses for my contribution to the chaos :)

Find here a Maple 11 Classical worksheet with this Windows version of the acer's calculation:

 Download 143_acer-method-win.mws

 Except, perhaps, for the small numerical differences I do not know whether there is something else to remark here.

And excuses for my contribution to the chaos :)

in the sense that the actions that you describe are only part of the process that produced these names. My guess is that properties of the particular input region or things like that (hidden by design) may contribute also. If so, the result could depend on the edit history of the document. And it could go out of control...

For similar reasons why I prefer LaTeX to Word I prefer very much 1D over 2D input mode.

in the sense that the actions that you describe are only part of the process that produced these names. My guess is that properties of the particular input region or things like that (hidden by design) may contribute also. If so, the result could depend on the edit history of the document. And it could go out of control...

For similar reasons why I prefer LaTeX to Word I prefer very much 1D over 2D input mode.

as you may get the same, or very similar, 2D typesetting from the different mathml-like constructs. Eg, using the 'prepost' palette object I have arrived to:

`#mscripts(mi(\"p\"),mn(\"0\"),mo(\" \"),none(),none(),mo(\" \"),mo(\" \"))`

which, when printed I cannot distinguish from your other two examples.

And probably, you can make many more different names that print the same, arising each of them from (perhaps subtly) different graphical interaction processes.

as you may get the same, or very similar, 2D typesetting from the different mathml-like constructs. Eg, using the 'prepost' palette object I have arrived to:

`#mscripts(mi(\"p\"),mn(\"0\"),mo(\" \"),none(),none(),mo(\" \"),mo(\" \"))`

which, when printed I cannot distinguish from your other two examples.

And probably, you can make many more different names that print the same, arising each of them from (perhaps subtly) different graphical interaction processes.

The association "Functional Programming" <-> Mathematica is not just in the mind of a particularly ignorant reviewer, but it is a "popular legend". A visible example is the article Functional Programming on Wikipedia, its reference 4 and its discussion.

The argumentation of the reviewer is very familiar to me. I have heard it in quite the same terms several times from colleague physicists. Not from anyone, but from the "computers veterans". While talking about our experiences, starting with the first programable calculators in the mid 70's, when we reach the point of the comparison between Maple and Mathematica, the mystical phrase appears: "But Mathematica has a functional programming language, eh!".

Quite probably, the first place where physicists have ever read "functional programming" was in the documentation of Mathematica. I think that it was my case. For sure, it was the thing that said that used it and you had at hand. But at that time I have found it confusing and I prefered very much the procedural programming language of Maple :)

So, where is the documentation explaining the use of the "functional programming paradigm" in Maple?"

I think that the subject of programming languages deserve a comparative review by itself.

Going into more detail, I think that this "wiki-based" system of reviews do
need of both kind of reviews. Specialized ones, you name it: General
Relativity, Statistics, etc; as well as general ones: core mathematics,
programming language, GUI, etc. The latter would be subject for "systemists" as well as serve for reference.








 

The association "Functional Programming" <-> Mathematica is not just in the mind of a particularly ignorant reviewer, but it is a "popular legend". A visible example is the article Functional Programming on Wikipedia, its reference 4 and its discussion.

The argumentation of the reviewer is very familiar to me. I have heard it in quite the same terms several times from colleague physicists. Not from anyone, but from the "computers veterans". While talking about our experiences, starting with the first programable calculators in the mid 70's, when we reach the point of the comparison between Maple and Mathematica, the mystical phrase appears: "But Mathematica has a functional programming language, eh!".

Quite probably, the first place where physicists have ever read "functional programming" was in the documentation of Mathematica. I think that it was my case. For sure, it was the thing that said that used it and you had at hand. But at that time I have found it confusing and I prefered very much the procedural programming language of Maple :)

So, where is the documentation explaining the use of the "functional programming paradigm" in Maple?"

I think that the subject of programming languages deserve a comparative review by itself.

Going into more detail, I think that this "wiki-based" system of reviews do
need of both kind of reviews. Specialized ones, you name it: General
Relativity, Statistics, etc; as well as general ones: core mathematics,
programming language, GUI, etc. The latter would be subject for "systemists" as well as serve for reference.








 

It seems to me that the main CAS have grown so large and extended to so much fields that no individual has enough knowledge nor time to provide a comprehensive review of a single system, not to say a fair comparative review. And keep it updated...

Eg, there are packages in Maple that deal with subjects that I have never studied and even I can hardly understand the language in which the help pages are written (eg PolynomialIdeals). Similarly, I think, a mathematician could have problems with the Physics package and so on.

And it would not be very useful to deal only with the sections of the system with which the reviewer is familiar with because the target is also fragmented: I doubt that many engineers would be interested on reading a review by a mathematician on ORE algebras. Or a researcher on string theory reading a review by an educator on a Student subpackage.

Thus, my current thinking is that these so much needed reviews can only be realized collaboratively. Perhaps in a wiki enviroment or something like that.

 

It seems to me that the main CAS have grown so large and extended to so much fields that no individual has enough knowledge nor time to provide a comprehensive review of a single system, not to say a fair comparative review. And keep it updated...

Eg, there are packages in Maple that deal with subjects that I have never studied and even I can hardly understand the language in which the help pages are written (eg PolynomialIdeals). Similarly, I think, a mathematician could have problems with the Physics package and so on.

And it would not be very useful to deal only with the sections of the system with which the reviewer is familiar with because the target is also fragmented: I doubt that many engineers would be interested on reading a review by a mathematician on ORE algebras. Or a researcher on string theory reading a review by an educator on a Student subpackage.

Thus, my current thinking is that these so much needed reviews can only be realized collaboratively. Perhaps in a wiki enviroment or something like that.