Axel,

While I agree in general with you that a CAS should not try to become a desktop-publishing system, some of us publish papers using results or plots from Maple. Even though the rules are relaxed quite a bit nowadays, publications still need to have proper plots with correct labels and annotations. Sometimes a plot done in Maple is only doable in another program with a lot of extra work. So plots with custom tickmarks, proper typesetting in labels, what-have-you, are an important feature worth having and worth maintaining properly. I'd even argue that Maple is not leading in this dept.

Just my $0.02.

Mac Dude

After my reply to Alejandro Jabubi I looked at this a little more and realized that, in fact, pulling in the data form the CODATA file was quite easy since the Maple names to a large extent follow the same convention so the translation and matching up is fairly trivial. So I cobbled together a quick-and-dirty Maple procedure that pulls in the constants from the file and updates all those it finds a Maple equivalent for using ScientificConstants:-ModifyConstant.

So far so good; that part basically works. It becomes however quickly apparent that not all is well: the conversions between the units do not get updated and are now inconsistent with the values of the constants.

Example:

electron_mass is 9.10938291E-31 kg (correct 2010 value)

electron_mass*c^2 is 8.18710506545917E-14 J (Maple-calculated but in agreement with 2010 value except for some spurious digits)

convert(electron_mass*c^2,'units','MeV') is 0.510 998 683 613 828 MeV, which is wrong, the correct value is 0.510 998 928 (also in the data file)

So it appears the unit conversion does not get updated and does not use the ScientificConstant numbers (not per se surprising as these are separate packages). I poked around extensively but am not able to find where I can update the unit conversion constants. The data file has values for a number of these conversions so I can pull-in and modify these constants also.

Does anyone have a hint how to go about that?

M. D.

@Alejandro Jakubi Yeah, i was thinking of that botched Mars mission... but I don't work in that field so it seemed inappropriate as an example from me (and yes, I do work with particle accelerators).

No one in his/her right mind will use a bug in Maple (or Matlab, or whatever)  as an excuse to screw up a job. What I am concerned about here is that our favorite CAS shows some disturbing signs of lack of quality control. We all have come to accept (wrongly?) that software has some quirks. I also accept that some of the things I do with Maple are pushing the envelope and may fail (I am thinking here about things like complicated integrals that may not evaluate even numerically when they should, or may evaluate wrongly). Wrong results are never nice but I can accept that happening in borderline cases or when an algorithm gets abused.

Simple bugs may slip through although they should not. The best way of dealing with them is to release updates as they get discovered. The flood of security updates for many software products demonstrates that this is possible. Like others here I commend Maple for planning to make updates of the Physics package available as they are produced. I will argue that the ScientificConstants package warrants a similar treatment.

An ASCII table with CODATA values (not necessarily the same as PDG values) is available at http://physics.nist.gov/cuu/Constants/Table/allascii.txt. This is for the 2010 values (their latest adjustment). It is not in a perfect format for pulling into Maple and updating the ScientificConstants but it seems close enough that a Maple script of limited complexity could make it work. In fact; I am tempted to look into this although I am already juggling more than I can handle so I could not possibly commit to anything.

Note that this is for physics constants and not elements or isotopes.

M. D.

Although this horse has been beaten quite to death, let me chime in given that I work in physics and need to use physics constants fairly regularly.

For any kind of professional use at least in particle physics & related fields there have to be regular updates that make the ScientificConstants values consistent with the PDG (Particle Data Group, pdg.lbl.gov) values. The PDG puts out regular publications (of a significant volume) that give the latest accepted values, usually based on the then-latest CODATA recommended values. Sometimes (if there are significant new results not yet in CODATA) they deviate. This is what the particle physics community uses, and also the majority of the particle accelerator people use. These updates appear every 2nd year or so. The actual least-squares adjustment happens much less frequently, that is why PDG differs in some cases.

If regular updates are not practical, a way to update the values is necessary. ScientificConstants actually has that (ModifyConstant). It is not a perfect way to deal with the situation, but it is a possible way. A better way would be a means to update the underlying library procedure.

I do have a hard time to find an excuse as to why these constants do not get updated with every major, paid-for, Maple release. Heck, it can't be that difficult! PDG may well make files available if asked; after all, these guys are publicly funded.

I also (to reiterate a rant I let off before) have a hard time to accept why bugs in ScientificConstants persist over generations of Maple. In my case it is the failure to properly treat the derived constants when changing the unit system, a bug present in Maple 15 and 17. I do note that ModifyConstant got me around that one as well, but I'd rather not rely on Maple's constants when designing the next billion-$ particle collider :-).

None of this is fatal. But it is not good PR either. 

Mac Dude.

@acer Any chance this (Routine to pull-in the CODATA constants) could be made available e.g. in the Application Center?

My reason for asking is twofold. First, as mentioned the data in Maple are not up-to-date. Second, unfortunately the ScientificConstants package tries to be too smart and expresses some constants as an expression involving others. This breaks when a new system of units is defined (a bug). But it is also wrong (even if it would work): the CODATA adjustment does this much better than Maplesoft could possibly do it and one should just use the CODATA numbers except in very, very special cases. Third, the numbers will eventually change.

It seems to me it should be trivial for Maplesoft to do something similar for each update of Maple.

M. D.

@acer Thanks for checking & confirming my observations.

It is actually kind-of sad having such an elementary thing go wrong. I believe I can work around this (by redefining m[e]), but I am not at all happy about this discovery. It means the ScientificConstants Package cannot be trusted. While I understand and accept that software is not perfect; this one I consider quite bad. Also unnecessary and probably fairly easy to fix (unless the whole package is really nadly done).

I'll probably put in an SCR, but it feels that Maplesoft is not particularly responsive to remarks from their customers.

:-(

M.D.

@acer Thanks for checking & confirming my observations.

It is actually kind-of sad having such an elementary thing go wrong. I believe I can work around this (by redefining m[e]), but I am not at all happy about this discovery. It means the ScientificConstants Package cannot be trusted. While I understand and accept that software is not perfect; this one I consider quite bad. Also unnecessary and probably fairly easy to fix (unless the whole package is really nadly done).

I'll probably put in an SCR, but it feels that Maplesoft is not particularly responsive to remarks from their customers.

:-(

M.D.

@abbeykabir To mind comes print(), and if you want a really well formatted output lining up neatly you may need printf which uses standard C formats. If you run these in a loop I think you may get the output at each iteration. 

If the iteration takes a long time you could use FileTools to print to a file.

All of these commands are documented and I encourage you to peruse the help facility.

M. D.

@abbeykabir To mind comes print(), and if you want a really well formatted output lining up neatly you may need printf which uses standard C formats. If you run these in a loop I think you may get the output at each iteration. 

If the iteration takes a long time you could use FileTools to print to a file.

All of these commands are documented and I encourage you to peruse the help facility.

M. D.

So the trick appears to be to enter the composite unit MeV*s into the AdSystem command (about the only variation I did not try). BTW, the multiplication sign has to be outside of uneval quotes.

The test works; I get hbar in the right units.

However, all is not well. Trying to evaluate the electron mass, where I want m*c^2 in MeV, I run into this interesting result:

m:=GetValue(Constant('m[e]'))*GetUnit(Constant('m[e]'));

c:=GetValue(Constant('c'))*GetUnit(Constant('c'));

simplify(m*c^2);

Hmm, heavy little buggers, these electrons, aren't they... :-) Well, no!

Digging a little I find that m[e] is a derived constant, and while the derivation adjusts the numerical value it appears to lose track of the unit: where it says "kg" it should be "MeV*s^2/m^2". And then I get for m[e]*c^2 the numerical value I want (0.511) but the unit [J] is wrong. it should be MeV.

Have I run into a bug here? I double checked Maple 15 and Maple 17: same result in both.
I played around adding the MeV to the list in AddSystem. That does convert the unit from Joule to MeV but the value (3.2E12 MeV) is still wrong.

The "context" I still do not fully understand (I got all that from the docs). It appears that the same unit can have different meanings (sure enough) and context is used to keep track of them. I am not sure this applies to me since I do not change any values or meanings of units.

M. D.

So the trick appears to be to enter the composite unit MeV*s into the AdSystem command (about the only variation I did not try). BTW, the multiplication sign has to be outside of uneval quotes.

The test works; I get hbar in the right units.

However, all is not well. Trying to evaluate the electron mass, where I want m*c^2 in MeV, I run into this interesting result:

m:=GetValue(Constant('m[e]'))*GetUnit(Constant('m[e]'));

c:=GetValue(Constant('c'))*GetUnit(Constant('c'));

simplify(m*c^2);

Hmm, heavy little buggers, these electrons, aren't they... :-) Well, no!

Digging a little I find that m[e] is a derived constant, and while the derivation adjusts the numerical value it appears to lose track of the unit: where it says "kg" it should be "MeV*s^2/m^2". And then I get for m[e]*c^2 the numerical value I want (0.511) but the unit [J] is wrong. it should be MeV.

Have I run into a bug here? I double checked Maple 15 and Maple 17: same result in both.
I played around adding the MeV to the list in AddSystem. That does convert the unit from Joule to MeV but the value (3.2E12 MeV) is still wrong.

The "context" I still do not fully understand (I got all that from the docs). It appears that the same unit can have different meanings (sure enough) and context is used to keep track of them. I am not sure this applies to me since I do not change any values or meanings of units.

M. D.

@ecterrab Hi Edgardo,

Just a quick reply as I am buried in unrelated work this week. I'd be delighted if I could draw on your expertise as I am designing the course. As I think I mentioned, the actual course will be next summer, so no need to panic yet, but I also won't be able to focus exclusively on it (far from it, actually) so I want to get going now as I know I'll be struggling at times with both Maple and the subject (in the sense of how to present it best).

Thanks much, we'll be in touch

M. D.

Ah, I did not realize showstat was of use here. So it appears that PhysicsVectors is what I think they call a structured type.

Thanks,

M.D.

Ah, I did not realize showstat was of use here. So it appears that PhysicsVectors is what I think they call a structured type.

Thanks,

M.D.

@ecterrab Yes, one may argue that (...these topics are outside the sphere of the Physics package). I meant to allow for that in the 2nd paragraph of my 2nd reply.

Re-reading your description (the worksheet), I think we may be approaching the subject from a somewhat different angle. You appear to be asking: how can we make this tool (CAS) better and even more powerful and more natural to use, implicating that then usage will increase. I am somewhat more hung up on why the power that is already there isn't used more, and my implicit answer is that it is the inherent complexity of the tool. I really do not have enough experience to decide who is closer to the truth, but given the relative maturity of CAS these days one does wonder why they have not reached the penetration of, say, MatLab (which I find in much broader use in my field of accelerator work than either Maple or Mma).

Going over this thread again, however, my first comment still resonates with me and seems to hit the spot as closely as I am able to.

In the meantime I have started to "play around" with my old course script and tried to "Maple-ize" a short piece. After a couple of hours of work I am still convinced I am going in the right direction with this and, I might add, I did use the Physics package to good advantage. And, lots of climbing on that learning curve again...

M.D.