@ 

Not really. G has everything; the rest is just to make it more explicit.

You do need to be aware of the assumptions Maple puts on the generated variables _Z2 and _B2, which you get using about(_Z2) and about(_B2). In this case, _Z2 is assumed to be an integer; _B2 is assumed to be 0 or 1.

M.D.

Read the Maple Programming Guide (can be found on Maplesoft's Manuals' page).

Program whatever it is you want to program.

If it works and is fast/accurate enough, you are done.

If not, come back and post the code you want to improve.

Mac Dude

Hi, have you tried printing the workbook to pdf (i.e doing it the old-fashioned way before ebooktools came along)? I have done this extensively and the only issue I could not fix was that the plots came out relatively large. But they never overlapped or such nonsense.

Mac Dude

@acer Many thanks for this exhaustive analysis. I actually was not all that aware of the floatPi kernelopt. The behaviour of evalf is a bit counterintuitive to say the least.

But it is good to have a better idea of what is going on.
 

Thanks again,

M.D.

@acer Ah, an oversight. Here is the file (with your name but modified). I did not touch your kernelopts. And as downloaded your original sheet evaluates exacly the same on my Maple as on yours even though I run 2015.1 and you run 2015.2.

M.D.

floatPiEqnLabel2.mw

@acer Ah, I had forgotten about trace... maybe I wasn't even aware that trace can trace Maple's library functions like sin... anyway, I played with your file & I think I get why evalf() changes your result (4):

evalf(sin(2*Pi*(4)));
execute sin, args = 704000000.*Pi
{--> enter sin, args = 704000000.*Pi
                                      8
                         7.04000000 10
                               0.
                               0
                               0
<-- exit sin (now at top level) = 0}
                               0.

so sin() gets a (-n integer) number times Pi as an argument and presumably knows that that is always 0.

The use of the variable (R in your file) prevents this and sin() gets passed the floating point argument so a round-off error appears.

Why are these different?

M.D.

Joe,

I had (actually still have, sort-of) a similar issue for one of my large packages (Lattice, a beam-optics code available on the Maple Application Center). I originally tried to use an export for this purpose only to quickly realize that it did not work as intended. Presently I use a "Set" method to set certain parameters in the package, which works, sort-of.

Some requirements for any such mechanism I think are pertinent:

* Reasonable initial defaults so one is not forced to set the package defaults before every use (e.g. for small and simple sheets that use a package).

* Allowing to set only a subset of parameters, leaving the others at their original default setting.

* The ability to set or change such parameters after first use of the package in a worksheet without getting inconsistent results.

The last item can introduce a non-trivial complication in large sheets as any change needs to be communicated throughout the package. For in-part this reason I settled on using a Setter method with named parameters; this allows to do any kind of manipulation needed. Setting e.g. a member of a record implies any module-local routine affected would need to check the parameter(s) upon each execution. A Setter method also allows any kind of type-checking desired. I do like your name "Configure" however, as it implies a larger scope that "Set".

I don't like the use of globals. Modules are a great way of protecting the module-local variables; the use of globals penetrates that protection.

I am less concerned about name clashes. E.g. the "Set" method has a short name that may clash, but I can (and do) give other procs a longer more descriptive name.

I do not understand your comment about the configuration object needing to be separate form the package or module. If you do not use a certain package, why would you want to bother setting its defaults? On the other hand, would you want to always have to load your default-setting module? Maybe I am not getting something here...

My third requirement (changeability after first use of a package) can be debated. It stems from my need to set the beam energy in the Lattice package, which for many cases is not needed and the definition of which, in some cases, triggers extra and potentially time-consuming evaluations in the package. By setting it later I can avoid spending such time. It is not an entirely clean way of doing things, however, and I may want to change my approach to this issue in a later version.

Thanks for sharing your thoughts,

Mac Dude

From the way the question is phrased I take it that you know how to specify starting values for fsolve. Do you want to know what Maple uses if you do not specify the initial guess(es)? Why do you care? If it gets stuck at an unwanted solution (quite possible) the Help pages explain how to use the "avoid" option.

I certainly do not claim to know how Maple derives initial guesses. One way is to start at 0. Another way is to find the values where the function crosses 0 (potentially time consuming). For more complicated problems I practically always specify the starting values to help Maple along.

Mac Dude

@Joe Riel and acer: Thanks both of you for the comprehensive answers. I believe I get faster processing of numeric data at least in certain cases when UseHardwareFloats is true, as it prevents Maple from falling back to software floats, although I'd be pressed if I had to come up with an example right now. But I would guess the effect of "true" is there for a reason so I am a bit sceptical of acer's assertion that "true" is a dubious setting. If it isn't working or useful, then why is the option even there? And Maple's default settings are not always optimal, e.g. I don't understand at all why Digits is 10 by default and not 15, which is the highest setting allowing hardware fpp and close to the accuracy of many calculational tools (programs, calculators etc.).

I understand that UseHardwareFloats:=true restricts what Maple can do. I fail to understand, however, why e.g. fsolve croaks reliably with this setting, even with relatively straightforward tasks. In my book that is a bug and not understandable at all.

Anyway, I do understand now the behaviour I am seeing, so thanks for enlightening me.

Mac Dude.

@acer Wow, thanks much for the in-depth expose of the issues involved. This reminds me of another problem with gridlines, involving log plots that do not plot logarithmically (in plots:-display) with my setting of gridlines=true. I SCR'd that one, like, 4 years ago and even had back-& forth with Maplesoft tech support at that time. It never got fixed. Quite possibly these are connected in some way.

I do wonder whether we have a chance to get this fixed. It is actually not so small a matter: in this case I was not able to get the plot I wanted in time for a presentation. For a $2000 package like Maple (with a $400 "maintenance" fee anually) I kind-of expect such things to get fixed pronto.

So, my thanks go to you for giving me a path forward, but my criticism goes to Maplesoft for not addressing basic flaws in a timely manner.

Mac Dude.

@acer Ah, so indeed without my .mapleinit file it works. It is appended here. Note that I had to rename it so the web interface would accept it. Originally it is .mapleinit.

FWIW, I am using Maple 2017.2

Mac Dude

mapleinit.mw

@Christopher2222 and acer, thanks both of you for your help. I like acer's Open... and the Remove Output and Save the best. But it is also good to know that removing the output in an editor is an option.

Now I need to sort out why the display command messes things up so badly. I may be back...

Mac Dude.

@svenonderbeke Please convert your sheet to 1-d input. Then it works. I don't really know what is wrong with yours, but I converted the input to 1-d Maple input (selecting a few expressions and using Format > Convert) and it worked. As is, it missed a few assignments, in particular f3. You can see that by doing indets(f3) upon which it should give you a list of the variables and functions having the variables in their arguments. as is, your sheet just returned f3, so f3 was not assigned.

2-d input is not really suitable to get calculations done. It is great if you want to produce a document to e.g. publish or so, but to get work done it is not well suited.

M.D.

@tomleslie That is exactly the way to do it! I hit onto this last night also, but I wasn't on MaplePrimes so didn't see your suggestion until now. In fact, for nargs=0 (i.e. no argument to density) one can return the graphite value & remain consistent with the normal behaviour of the package. Sweet! My own version ended up looking like this:

ModifyElement('C',density=[value=proc() if nargs=0 then 2.2\
                                        elif args[1]='graphite' then 2.2\
                                        elif args[1]='diamond' then 3.5\
                                        else error "unknown allotrope" end if end proc]);

and

GetValue(Element('C',density));
GetValue(Element('C',density(diamond)));
GetValue(Element('C',density(graphite)));
                             2200.0
                             3500.0
                             2200.0

(the returned numbers are in kg/m^3 due to the SI system whereas the entries in ModifyElement are in g/cm^3.)

Thanks much,

Mac Dude

@dharr Actually, what I am really doing is to add the radiation length X__0 (from a separate table I generated) to the properties of the elements. Radiation length (which is the lengths scale for radiative energy loss of electrons or photons passing through matter) is customarily given in g/cm^2, so to get the actual length one needs to divide X__0 by the density. The cases I am looking at involve crystalline materials including carbon, hence the interest in diamond.

That said, I discovered in the properties help page you referenced that the density already uses a parametrized form for gaseous substances. I am not quite sure why; but in principle it should be possible to program this such as to allow density(graphite) and density(diamond). I can probably do this myself.

Thanks,

M.D.