Hi
As mentioned in a previous comment in this thread we now provide access to the version of Physics under development, including adjustments/fixes/novelties as they are ready. A new update (today Aug/1) is available for download at http://www.maplesoft.com/products/maple/features/physicsresearch.aspx.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Mac Dude

Taking real/good advantage of computer algebra in physics courses is to some point pioneering activity. As mentioned in the presentation it is also one of the main targets of the Physics project. Please feel free to bring your related questions/suggestions, here or writing us at physics@maplesoft.com, and we may be able to help you / join efforts.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Mac Dude

When using computer algebra in physics, "casting expressions into certain forms" is the very relevant type of thing we (students or not) need to do all the time. One needs to learn these basic operations in order to take advantage of the computer in physics. And for these basic operations I think that a basic and really short, to-the-point, textbook/tutorial is best. Your first comment made me consider revamping/updating that tutorial I wrote for physics students years ago. In your second comment, however, you mention something else, like "pushing the limits of Maple", e.g. simplifying an expression for which simplify fails, etc. I think these are more advanced operations, or more technical things like the evaluation levels detail you linked, more relevant for people who go deeper into using computer algebra in general - as such I feel these topics are outside the sphere of the Physics package.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
Just revising the documentation about dsolve's speed to see if the information I have is also available to you, Mac Dude. Check please ?dsolve/rkf45 and ?dsolve/numeric/efficiency: current dsolve runs as fast as C code when specifying the compile = true option in the call to dsolve/numeric. Using this option actually makes dsolve write the C code for you, compile it, and use it for solving the DE system, without you perceiving. It is all automatic, as said in the presentation. The limitations of "dsolve at the speed of C code" are also just those for regular C code you may nevertheless prefer to write yourself to use with a connection Toolbox: it only works with real valued DE systems that contain at most elementary functions (no special functions allowed) - see the list of functions in ?Compile,compile under Runtime Support.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
These polemic questions and the answers I present in this talk actually passed through my mind at different times and reflect, honestly, what I think.

In 1996 I was interested in computing Poincare sections in the context of a general relativity problem. There was Fortran code for that (see Calzetta and El Hasi, Phys.Rev. D 51 - 1995). After struggling badly because the number of numerical experiments to be done was really large, it resulted to me much simpler to write a complete program to compute Poincare sections within a computer algebra system than trying to use the existing one for Fortran. The program is today found in Maple, DEtools[poincare].

I learned two things: 1) the advantages of running numerical computations within a computer algebra environment were just enormous. 2) the drawback at that time: speed. I didn't like the speed. No, it was not satisfactory. C was abut 30 to 100 times faster.

In 2000 this speed issue got on my nerves. I talked to Allan Witkoppf, my friend, at that time a Ph.D student and an expert in C. We came up with some interesting ideas that ended up in the Maple DNA project for fast numerical ODE solutions (google "DNA Maple 6"). Surprisingly, with simple ideas we got 15x to 30x speed up - hey! I understood one more thing: the numerical slowness of computer algebra systems was not a real or serious obstacle.

Along the next ten years Allan became the Maple numerical DE guy, great - and voila the speed, Dude. It is there. For real. Even DNA is now in the dust. Try your examples. Compare. I - honestly - believe and fully stand by this answer for polemic question 1. Yes, you can also use a connection Toolbox instead, as you say, and some people will prefer it, perhaps because already have C or Fortran code that they can reuse. Still I think the CAS worksheet is really better in the small and large scale, for the opportunity of reusing, symbolic preprocessing not available in Fortran or C, and including the speed.

About polemic question #2: I agree with you in that the computer is not exclusive of books. I see from your comment that the presentation could be misunderstood as suggesting "this or that". The intention is only to reflect a practice, though: people tend more and more to use one or the other, as in "only go to the books if the computer (including web) is insufficient". And not few people ask me about this regarding DEs. The last time I consulted DE books I believe it was ~10 years ago. For ODEs the computers went just far beyond textbooks. Not beyond humans. I currently do consult the arxiv.

You mentioned Abramowitz. It is also true, I have my copy. And always looked at it as a monumental piece of work. But then in 1999 I moved away from the paper version of it (google "abramowitz pdf", second link). Then I saw the DLMF (Digital Library of Mathematical Functions) and Marichev's and others emerging as static repositories of special function information. The FunctionAdvisor in Maple came after all that, with a different idea in mind: do not present 'static' information. Instead: process information, interrelating it on the fly, according to user's input, using an increasing number of new algorithms popping up all around.

There is still a long way to go. I think however that the paradigm has shifted already. Textbooks and static presentations are entering the rear mirror. Core pieces of mathematical information processed on the fly with each-day-more-varied-algorithms is in front of us. This is what is illustrated in the presentation attached.

The core of the special functions part was also presented in "Special Functions in the Digital Age" (IMA 2002), while a previous version of most of this DE material, including the questions, was also presented in the session for "Teaching and Learning Differential Equations" of the meeting of the CMS 2000.

Edgardo S. Cheb-Terrab 
Physics, Maplesoft

Hi
Thanks for your comments. The learning curve: basic or advanced quality textbooks? Struggling to do seemingly trivial things like casting expressions into certain forms … I'd say compact-and-basic is the remedy, with compact & quality in bold. For teaching in Brazil, State University of Rio de Janeiro, I tried to write such a mini-and-basic for physics students; I may revamp it. For advanced: what is what you'd like to see in such a text that would smooth out the learning curve?

Examples and textbook notation: I'm glad to hear that you find these examples useful. The are mostly those shown in ?Physics,Examples. Physics and mathematical methods are not the same thing, and Feynman's and Landau's books (not only them, of course) are great in that in their problems illustrate both for real. BTW three of the four examples under "Mechanics" are from Landau's vol.1.

The 'notation' issue actually refers to keyboard input, and the display of results on the screen, so not palettes. To enter things, say, as you do when computing with paper and pencil, and see the output as you see it in textbooks. It is impressive for me how this speeds up matters in my brain. Even after working with computer algebra for so many years, I'm still not used to (sounds alien to me) computerish style representing mathematical objects so differently than the way we do it by hand, ditto for the output. All the efforts are put in Physics to not do that.

New: we now provide access around the clock to the version of Physics under development (http://www.maplesoft.com/products/maple/features/physicsresearch.aspx). This includes ways for you to present your suggestions/report bugs/feedback. The downloadable package, post 17.01, is at "zero known bugs" in this moment and we intend to keep it this way. Not having to wait for adjustments until the next release anymore.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Download you_can_set_g_to_wha.mw

@ecterrab 

Download you_can_set_g_to_wha.mw

@ecterrab 

@peter137 Yes I have in mind additional documentation; that is key in this project and chunks are added at each release, with some people now complaining because of the current large size of ?Physics,examples ... These examples are mainly from the Landau books or from the other books shown in the references (footnote of ?Physics).

What would be your suggestion for showing the use of the package that at the same time is of your interest and you think would be of wide range interest?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@peter137 Yes I have in mind additional documentation; that is key in this project and chunks are added at each release, with some people now complaining because of the current large size of ?Physics,examples ... These examples are mainly from the Landau books or from the other books shown in the references (footnote of ?Physics).

What would be your suggestion for showing the use of the package that at the same time is of your interest and you think would be of wide range interest?

Edgardo S. Cheb-Terrab
Physics, Maplesoft

@Alejandro Jakubi as said in this and another thread this problem is fixed. But you are suggesting something else. Note that in the output you show by simplify/size you have w * conjugate(w) -- that is a non-simplified product, and as such it is not good as output of a simplify command. The output after the fix in fact is as the one you show by simplify/size but with that w * conjugate(w) also simplified.

Besides that there is simplify/size itself being discovered. To have in mind: when writing it tried thoroughly to avoid performing any mathematical operation - nothing - only collect coefficients (including of frozen subexpressions) and at most decomposition of fractional powers, that can be done fast. Anything else would ruin the performance of this wonderful routine, that was originally developed for, and is systematically in use in all the Maple DE, Physics and MathematicalFunctions code, and it is not used by simplify by default only because of backwards compatibility debates.  

And one idea to keep in mind: wouldn't it be beautiful if *every* output, not just the one of simplify, would always be preprocessed with simplify/size? Exception made only (from the top of my head) of the output of collect, factor and expand. I am talking of a kind of a setting. One that you could turn ON/OFF optionally, say as simply as typing > on;, or >off; and voila the thing activated/deactivated :) No? :) I think so, and work everyday with this feature implemented - it becomes addictive. At every release I consider adding it to the system. Perhaps ... It would need some tunning but mostly facing a significant break with so many years of (for me boring or frequently wallpaper) computer algebra output.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi
The comparison you mention consists of mainly 3 pages, of which less than 1/2 is about mathematical features (starting at 'Graph theory' and finishing at 'Cayley tables'), so to begin with there are obvious and significant omissions.

To mention but a few in areas I am more familiar with, the new Maple 17 functionality in Physics, Differential Equations and Differential Geometry - not mentioned at all in the comparison - is not only not available in Mathematica 9 or previous ones, but it is also probably 5 to 10 years of development ahead of what you see in Mathematica. This is the opposite of what is claimed in that comparison advertisement. Moreover, this distance is favorable to Maple, consistently, since year 2000, and consistently increasing every year. For Differential Equations the difference started shockingly (that is the word) in 1997 at least and Mathematica just never recovered.

Independent of these stark omissions, regarding the half page of mathematics that is mentioned in that comparison, either the person who wrote it does not understand the topics, or distorted the facts.

For example, quoting literally from this comparison you mention, it says that Maple 17: "a) introduced Visualization: visualize branch cuts, b) this Maple's functionality is not equivalent to Mathematica's automatic branch cut detection—it allows you to request a visualization of the branch cuts of individual functions but does not detect branch cuts in functions that you try to plot, c) that Mathematica introduced this in 2007". Statement c) is supposed to indicate that Mathematica introduced this functionality before Maple.

Both statements a) and b) about Maple are incorrect and the implication of statement c) is false.

Maple introduced visualization of cuts with its plots:-plotcompare not in Maple 17 but already in 2002, so 5 years before Mathematica and in a way still not seen in Mathematica 9; the Maple visualization is not restricted to cuts of individual functions, and of course the Maple plotting routines detect the branch cuts of the expressions you try to plot. See for instance the examples in the help page for ?plotcompare. But more important, Maple 17: a) introduced *algebraic representations* for the branch cuts of *algebraic expressions* not just individual functions, and this functionality does not exist at all in Mathematica - in fact it is new research work, see references in ?FunctionAdvisor,branch_cuts - and b) Maple introduced *algebraic representations* for branch cuts of individual functions already in 2003, with the FunctionAdvisor project, and neither those algebraic representations for the cuts even of individual functions, nor anything like the FunctionAdvisor project, ever existed in Mathematica, also not in the new Mathematica 9.

You see ...

Edgardo S. Cheb-Terrab
Physics, Maplesoft

This one actually got fixed June/19 before you posted. The problem you mention is the same one mentioned in http://www.mapleprimes.com/questions/148559-Problem-With-Code-Calculation-In-Maple-17 (I gave some details there). In short, simplify/conjugate, a very old routine (previous to 1994), got entirely rewritten.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Carl,
There is a line (showstat(`simplify/conjugate`, 11)), in place since 1994 as far as I can see, that is problematic in that it introduces significant algebraic complication (see reply by Alejandro) while trying to simplify f*conjugate(f) = abs(f)^2. Until Maple 15 inclusive, the result of that attempt was discarded whenever it didn't result in 'less conjugate(..)' around, and thus the algebraic complication it would introduce was not noticed. But then the logic underlying these lines 11 to 13 fails in an example like f*conjugate(f) + conjugate(f), where replacing the first term by abs(f)^2 does not lead to 'less conjugate(..)' around - you still have conjugate(f); this got fixed in Maple 16, but then the result of this line 11 not always ends discarded in M16 till today ... and then you have the snow ball I see with the example posted in this thread. Of course the problem is that line 11..13 in that  the simplification f*conjugate(f) -> abs(f)^2 can be done more economically and avoiding these algebraic swelling problems. It is easy to fix. Unfortunately I do not see a workaround for you without editting the code. I am not sure the fix can still go into 17.01.

Edgardo S. Cheb-Terrab
Physics, Maplesoft

Hi Carl,
There is a line (showstat(`simplify/conjugate`, 11)), in place since 1994 as far as I can see, that is problematic in that it introduces significant algebraic complication (see reply by Alejandro) while trying to simplify f*conjugate(f) = abs(f)^2. Until Maple 15 inclusive, the result of that attempt was discarded whenever it didn't result in 'less conjugate(..)' around, and thus the algebraic complication it would introduce was not noticed. But then the logic underlying these lines 11 to 13 fails in an example like f*conjugate(f) + conjugate(f), where replacing the first term by abs(f)^2 does not lead to 'less conjugate(..)' around - you still have conjugate(f); this got fixed in Maple 16, but then the result of this line 11 not always ends discarded in M16 till today ... and then you have the snow ball I see with the example posted in this thread. Of course the problem is that line 11..13 in that  the simplification f*conjugate(f) -> abs(f)^2 can be done more economically and avoiding these algebraic swelling problems. It is easy to fix. Unfortunately I do not see a workaround for you without editting the code. I am not sure the fix can still go into 17.01.

Edgardo S. Cheb-Terrab
Physics, Maplesoft