Mac Dude

1506 Reputation

17 Badges

10 years, 247 days

MaplePrimes Activity


These are replies submitted by 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.

 

 

@Christopher2222 Thanks much; but no go: Maple won't let me add another element 6 and I can also not chose, say, 1006 for the atomic number in AddElement and then use C for the element symbol (besides, it would be pretty ugly).

So I think I am stuck here :-(. Maybe I'll submit a feature SPR.

Thanks dharr also; the specific comment in Help had escaped me. I actually do not argue with Maple's choice of the allotrope (graphite is more stable  than diamond, which will become graphite if heated up too high [in an inert atmosphere, lest it burns] so don't try to bake your diamonds).

 

Mac Dude.

 

@acer This was actually a sinister thing: There seemed to be funny non-printing chara's at the beginning of each line (and not a Unix vs DOS vs MacOs line-ending thing). Emac would not display them even when I set the relevant toggle to make it show all characters; but hexdump would. For once, good old OS X Textedit would strip the crap when I used it to save the file as ASCII. On top there was a trailing space after each element symbol which convert would preserve & upset ModifyElement. parse strips it and works.

It is what one gets when copy-pasting text out of a pdf.

Anyway, it all works now. Thanks a lot.

M.D.

@acer Wow, I feel dumbfouded. I looked at the file using Emacs since I was wondering about that, and I did not see the extra character. It is a bit weird that it survives the parse procedure. Of course, this is not a Maple problem.

Anyway, will check this out soonest & see if the loop now works.

Thanks much,

M.D.

@acer Ok, here is my attempt at a minimum working example exhibiting the problem. One Maple worksheet and one txt file with the table.

Thanks

Mac Dude

ModifyElementMWE.mw   Radiation_Length_Table.txt

@Carl Love I tried both parse(), and cat('',elemt) per Joel's suggestion. parse() gives the same error; cat fails when the first entry is an empty name. Do note that I also tried convert(elemt,'name') to explicitly make this not a string but a name (my code snippets in the original post may be a bit misleading in this regard).

When doing lprint of the result there is in fact one pair of left quotes.

ModifyElement definitely will not accept a string as element name, and complain as such.

Tx,

M.D.

 


One use-situation that comes to mind is remote access. If you are halfway across the world and want to run a Maple session, say, on your work computer the cli can be a lifesaver. Running X11 remotely is usually not a lot of fun, as is VNC if you can even use it.

M.D.

@edahl Another option worth investigating is the maplev mode for Emacs, by Joe Riel (who is no stranger to this forum). You will need to use emacs, obviously, but it may be worth it. Joe keeps maplev up-to-date for Maple from V to present. maplev does keyword coloring, indentations, will help you sorting out the various end do, end proc etc. closures, and many more things. I believe you can also run Maple from within emacs through it although I am not doing that.

To make this work you create your code as a file with a .mpl extension. Then you "read()" it into Maple.

Just my $0.02.

M.D.

5 6 7 8 9 10 11 Last Page 7 of 42