@Carl Love Cool, that does the trick and is consistent with the overall scheme of what I am trying to do.

Thanks much,

M.D.

@MrMarc The term "Theory of Everything" (TOE) does not imply >everything< can be explained >in detail<. It refers to the idea that one has the fundamental theory that explains our Universe without ad-hoc asumptions or the need to plug in measured values then >in principle< one could derive everything else. The Standard Model is not it, as it has a number of parameters that need to be defined outside of the SM. However, >in principle< is a significant qualifier, as phenomena like chaos make predictions inherently next-to-impossible even if we had literally unlimited computational resources.

E.g. although the mechanics is well known an attempt to calculate exactly and in detail the swirling of the water around the drain as your bathtub empties itself is pretty much hopeless (I am fairly sure though that you can calculate and predict that there will be a rotational motion, however, just not the details). The timing of your and my pit stops would be---in relation to a TOE---equivalent to such detail, actually much, much, much more removed from the theory than the movement of individual molecules in the swirling water from, say some kind of hydro-dynamic calculation.

We do, however, have an idea what the term "everything" encompasses. It is based on the assumption that everything builds on the particle world by means of their interactions, decays, reactions with each other and so on. So the claim of a TOE is not quite as hubrid as it sounds (it is arguably a little hubrid, though). Earlier attempts in this direction were e.g. the "Weltformel" (world formula) by Heisenberg et al. The difference is that nowadays the connection between the physics of the smallest known particles (leptons and quarks) and radiation and the largest structures in the universe (e.g. black holes & the whole Big-Bang cosmology) is known at least to some degree, which was much less the case in Heisenberg's days. Needless to say, anything outside of this picture would not be covered by "everything", but arguably one of the successes of modern elementary physics is that in fact it appears most phenomena >are< consistent with this picture and do not need assumptions of other effects.

I would certainly agree with your doubt that we are anywhere close to an actual TOE. I do not know enough to have an opinion as to the possibility of ever developing one, however. Whatever it would be, it would presumably be highly abstract and be many layers above the world directly accessible to our senses.

M.D.

Your upload indicates that you saved as a Maple Workbook (.maple); a relatively new format introduced with Maple 2016 (I believe).  Older versions of Maple cannot not open this.

Unfortunately, Maplesoft in their (un-)wisdom elected to not let you save a Workbook as a Worksheet (the .mw format we are used to). At least I have run into this before where a worksheet accidentally saved as a .maple Workbook could not be re-saved as a Worksheet (.mw). I think I had to save as a text file (.mpl) and then read it back in.

Moral: watch what you are saving as & stay away from the Workbook if you have older versions of Maple in active use.

M.D.

As a long-time user of Maple 15 (vs 2015) on Mac OS X I can ensure you that there is no such limit in the general case. I have had the kernel use more than 4 GB on a G5 (the Maple kernel runs in 64 bit mode on a 64 bit PPC) and even on a 32 bit G4 I have certainly had it use more than half a GB.

That said, Maple 15 certainly has a higher propensity of locking up than newer versions. Sometimes it is just longer run time, but I also had code lock up in Maple 15 that runs in, say, Maple 2016.

Give us an example. If it is a loop that locks up, there are ways to diagnose that. If a certain operation locks up maybe there is a way to diagnose it as well.

I have Maple 15 still working on a G5, so if you send an example I can try it.

Just my $0.02

M.D.

Edits for spelling & clarity.

@Carl Love Ah, I did not catch that. For my immediate needs it is not a major consideration, but for some other projects it may become important.

Thanks,

M.D.

@Carl Love Oh yeah, good old Programming Guide; obviously, how could I forget (I am serious here; the Maple Programming Guide is probably the most important Maple documentation/book).

So yes, it explains everything including the operator overloading as you mention.

I am still a bit doubtful about the improvement. Something akin to operator overloading in fact was already present in the previous approach (see Sec. 8.6 in the Programming Guide) even if it is called rebinding and explicitly claimed to not be overloading. But with the option overload (or using the specific function overload()), it seems to me the effect should be very close to overloading, which in my book means that depending on the type of the argument, an operator does different things (presumably always meaningful in the given context).

Still diggin'

Mac Dude

@tomleslie This may be a deficiency of Windows, where the HiDPI support seems not quite there yet. I have several Retina-display Macs as well as a non-Retina monitor, and the interface elements come out right on all of them, just with higher resolution on the Retinas. It will even work in a mixed environment. I am not sure this is something Maplesoft can fix; I think it is a system issue. But then, what do I know about Windows.

Mac Dude

PS: Retina is Apple's moniker for HiDPI displays.

@Preben Alsholm Thanks much, Preben.

My own work around for the time being is to use the densities from another table that I got from the PDG. This works for me as I am building a separate table anyway to include some properties not in Maple's own system. So I take those values & modifyElement to put these numbers and their units in, essentially overwriting Maple's numbers.

M.D.

@Ronan Hmm... I am not in a position to check this right now. Some things to check upon: In libname, I have my own directory first, so my routines cannot get masked by Maple's routines. I don't think that is an issue here, however. Your "with(Rtestm)" call returns [Rtest] which would indicate that the with() succeeded, but somehow Rtest does not get the assignment.

I do wonder whether you would need to use the ModuleLoad function. In fact, I first thought one would need to use that but found that it wasn't necessary in this case. you can read up on ModuleLoad in help until I get around to checking this further.

M.D.

@Ronan Here is a minimum working example how to read a proc into a module:

-------------------

restart; # the message is from my own .mapleinit file
                "Maple Initialization loaded..."
currentdir();
                       "/Users/uli/work"
test(); # not defined  so just returns unevaluated
                             test()
testm:=module()
  export test;

     read("test.mpl"); # This reads (and executes!) test.mpl
 
end module;

                          _m4598062464
test(); # now it is defined
                        "this is a test"

----------------------

test.mpl looks like this:

test:=proc()
  print("this is a test");
end proc;

As for using an external editor, that is obviously your own call. Personally I use Emacs and Joe Riel's maplev.el package for Emacs. maplev mode does syntax coloring and code-indentation; Emacs allows to split a window; all very convenient features when coding. But then, I have known Emacs for a long time... But you can presumably also use Notepad on Windows.

I find editing in Maple and then writing the code out not very satisfactory. Small packages I just keep in the Maple environment & save directly to the .mla file (I call that "compile it" although nothing of that sort is going on), keeping the .mw file in case I want to make changes whereas large ones I do in Emacs.

I am surprised about the mess with the directory separators in Windows. Maple used to deal quite well with the old ":" separator in Max OS 9 and earlier so it certainly knows how to handle different separators. Maybe it is just a bug? I don't do Windows so I don't know.

M.D.

@Preben Alsholm Thanks much for the investigation & explanation & SCR, thus sparing me the effort of doing it. I do wonder how many people are using these constants... maybe not so many. But be that as it may, if it is in Maple, it should be correct so hopefully they fix it with 2017.3. It should not be a difficult fix.

M.D.

@Ronan Your problem with the dot is simply syntax: you need to specify filenames as strings i.e. use double quotes (").

I am uploding a Maple worksheet showing how you can save and read your function Antisym, and also how you can wrap it into a module (RatTrig), declare it a package, save it as a .mla file, and then use Antisym as as a member of the RatTrig package. You need to declare the function as export to be able to use it. You can have many procedures and even, as John Fredsted suggests, have modules within modules to get a hierarchy of functions, although I do suggest starting somewhat simple until you get the hang of it. If you want to delve deeper get the Maple Programming Guide (from Maplesoft's documentation area), it is invaluable if you want to do more programming in Maple.

Note that this sheet uses my own defaults esp. for libname so you need to adapt it before use. I set libname in my .mapleinit file.

And I use Mac OS X. It looks like you use Windows so your file specs look different, esp. you need the backslash instead of slash as directory separator.

M.D.

RatTrig.mw

@tomleslie With MathType it works, I do this often, although usually into Ppt.

In Word, select "Insert MathType Equation" (which you will be able to do with MathType installed correctly).

An empty MathType wondow opens.

In Maple, select your equation & "Copy as MathML"

Paste into MathType.

There are some issues with this: First, Maple variables & such appear in blue. Looks kind-of pretty but usually unwanted. Trivial to fix in MathType. More annoying is that everysooften I get Greek letters as something approaching ML markup: &beta; or similar where a Greek beta should be. So I have to select & paste the correct character by hand. Not nice.

At least the general layout is preserved.

There are instructions on the DesignScience website. Also, I found their cust. service to be quite responsive.

M.D,

Doing as you propose would have far-reaching consequences.

E.g., often one takes sin(x)=x to first order. This would lead to confusion if sin would take degrees as argument. Also, the radian has unit [1]; if you are doing dimensional analysis then the degrees obfuscate the issue significantly, to say nothing about Taylor series.

While I am sympathetic to the plight of students; if they do math sophisticated enough that Maple is a viable tool, either as a teaching tool or to be used in analysing math problems, then they should be taught to grasp the idea of radians. In the end, learning that a right angle is Pi/2 vs 90 deg is maybe not that big a deal.

I grew up with degrees. This did not make my life in physics easier. On the plus side, becoming bilingual with units (as in degF vs degC, inches vs metric, and rad vs degrees) is actually quite a useful skill.

M.D.

@vv Slick! I love it.

M.D.