@quanta I'll try and find time to give it a shot on Win7. (My cygwin's gcc is doing ABI=32, I think. But with some time I ought to be able to figure out using mingw for it. Maybe I can get the ABI=64 for gmp using the appropriate msvc++. Finding time is often the problem.)

If you enjoy reading older articles on this site, there are some interesting ones available under various "tag" pages. I like the performance and blog tags.

Maybe you were remembering this old post.

acer

@dalmas64

In your other posts, it was shown that supplying Optimization:-Maximize with the optional argunment method=branchandbound generates the correct solution (for your other differing univariate examples).

@dalmas64

In your other posts, it was shown that supplying Optimization:-Maximize with the optional argunment method=branchandbound generates the correct solution (for your other differing univariate examples).

@Robert Israel Thanks, Robert. I don't know why I forgot that.

@Robert Israel Thanks, Robert. I don't know why I forgot that.

Preben is quite correct about the cause.

Another solution is to keep the locals declared as they are, but to change the optional argument to SingularValues to be,

   output = [':-U', ':-S', ':-Vt']

acer

Preben is quite correct about the cause.

Another solution is to keep the locals declared as they are, but to change the optional argument to SingularValues to be,

   output = [':-U', ':-S', ':-Vt']

acer

@bhornsby89 Your worksheet now has it with three with() calls, inside the procedure body. Don't code with(...) inside a proc. It is not guaranteed to work at all.

Instead, try doing it exactly as was suggested and code it with `uses`.

So, replace your three with() calls inside the proc body to be instead the single line,

   uses LinearAlgebra, Statistics, combinat:

@bhornsby89 Your worksheet now has it with three with() calls, inside the procedure body. Don't code with(...) inside a proc. It is not guaranteed to work at all.

Instead, try doing it exactly as was suggested and code it with `uses`.

So, replace your three with() calls inside the proc body to be instead the single line,

   uses LinearAlgebra, Statistics, combinat:

Really super, Joe. I mean that even more for showing everyone such nice clean techniques.

I have a very minor variation to suggest, just to the installation location. Above you have it as,

installed_so  := $(MAPLE_BIN)/$(shared_lib)
installed_mla := ${HOME}/maple/lib/$(pkg).mla

That's maybe not ideal for everyone. The MAPLE_BIN directory might not be writable, if that is a network Maple installation. And someone might not want to tamper even in the slightest with the existing, nonempty folders of their Maple installation. And that `lib` location would require that the user's Maple sessions be configured so that `libname` included that location (either done manually each time, or in one's Maple initialization file).

An alternative pair of installation locations might be,

installed_so  := $(HOME)/maple/toolbox/pkg/bin.$SYS/$(shared_lib)
installed_mla := ${HOME}/maple/toolbox/pkg/lib/$(pkg).mla

By bin.$SYS I mean setting SYS like the last part of kernelopts(bindir). The reason I suggest these is that I believe that modern Maple will automatically pick them up. Such directories/folders as maple/toolbox/foo/lib, under kernelopts(homedir), get automatically added to libname. And those bin.$SYS directories/folders automatically get prepended to LD_LIBRARY_PATH/PATH according to whether the OS is Windows/UNIX.

Of course, you might decide that such automatic detection of binary+Library packages is something you don't want. But if you do, then these locations can be quite useful. Another neat twist is that the folders can be named like {$HOME}/maple/toolbox/13/pkg/lib/ and as such would get detected by Maple 13 but not by Maple 14. And so on.

For some years now I've thought that it might be more generally useful if this functionality were documented explicitly. There are lots of packages on the Application Center which don't clearly explain how to alter libname and thus gain access to the commands in the bundled .mla Library archive. But a simple, general solution might be documentation which described re-usable locations for personal libraries (and any associated binaries) that would just work, automagically. Locations that were not the central `lib` or bin.$SYS location of the user's Maple installation itself, to avoid danger of clobbering anything crucial to Maple proper.

Of course, many Application Center entries don't even use .mla archives at all, but merely provide their functionality in a bare worksheet. That's another issue altogether, to address another time.

Back to the reusable location idea. One could stick more than one archive (and binary, if applicable) under one such folder. A single folder location could hold several such personal apps, as long as the .mla's had distinct filenames. (Or the apps could be merged into a single archive, if the package names were distinct. But that's more complicated, and gets away from the ease-of-use theme.) A common location could contains various add-on archives such as,

   ${HOME}/maple/toolbox/misc/lib/pkgOne.mla
   ${HOME}/maple/toolbox/misc/lib/pkgTwo.mla

etc. That be much easier to explain, as far as where to place an Add-on .mla archive. "Just stick it in HOME/maple/toolbox/misc/lib" is a lot simpler than "Ok, place it anywhere, and then find your Maple initialization file, and then edit it and add the line libname:=...,libname".

acer

This folks, deserves yours thumbs-up votes, as it should be a Great Answer.

It makes me misty-eyed to read it.

acer

This folks, deserves yours thumbs-up votes, as it should be a Great Answer.

It makes me misty-eyed to read it.

acer

I had noticed that Christopher2222's integral wasn't quite the same as the SIAM Challenge problem, but I didn't mention it above. In Maple 14 one can get some more digits by specifying the method, etc, as above. But 100 digits accuracy, over the whole range from 0 to 1, should prompt one to hunt for another scheme altogether, I think. (Robert's solutions implemented in Maple to that SIAM 100 Digits Challenge, which he has linked to above, are a thrilling read.)

> evalf(Int(cos(log(x)/x)/x, x = .0001 .. 1, epsilon=1e-8)); # takes 20-30 secs to fail...

                       /1.      /ln(x)\   
                      |      cos|-----|   
                      |         \  x  /   
                      |      ---------- dx
                     /            x       
                      0.0001              

> evalf(Int(cos(log(x)/x)/x, x = .00001 .. 1,
>           maxintervals=50000, epsilon=1e-8, method=_d01akc));

                          0.3233669608

acer

I had noticed that Christopher2222's integral wasn't quite the same as the SIAM Challenge problem, but I didn't mention it above. In Maple 14 one can get some more digits by specifying the method, etc, as above. But 100 digits accuracy, over the whole range from 0 to 1, should prompt one to hunt for another scheme altogether, I think. (Robert's solutions implemented in Maple to that SIAM 100 Digits Challenge, which he has linked to above, are a thrilling read.)

> evalf(Int(cos(log(x)/x)/x, x = .0001 .. 1, epsilon=1e-8)); # takes 20-30 secs to fail...

                       /1.      /ln(x)\   
                      |      cos|-----|   
                      |         \  x  /   
                      |      ---------- dx
                     /            x       
                      0.0001              

> evalf(Int(cos(log(x)/x)/x, x = .00001 .. 1,
>           maxintervals=50000, epsilon=1e-8, method=_d01akc));

                          0.3233669608

acer

In 1D Maple notation, the following takes a range from -1 to 1 (one).

plot(x, x=-1...1);

But if one takes that code and simply pastes it in as 2D input in either a Worksheet or a Document then the range will be taken from -1 to 0.1 (1/10). It's totally different. Some implicitplot's will come out empty if mistakenly pasted like this.

There are decades' worth of 1D code around, including as content on web pages. Some one (or people) may have thought that they were doing everyone a minor favour, by implementing the 2D Math parser to suit their own new ideas of what's best. But the actual result is that there are these major rifts between old legacy code and the newest versions' default mode's parser.

All such "differences of minor convenience" should be fixed, changing 2D mode to be compatible with 1D mode as far as is possible.

acer