@Markiyan Hirnyk No, you are wrong. That was a problem with premature evaluation. This is different, being a distinction between behavior with exact exponent 0 and floating-point exponent 0.0.

@Markiyan Hirnyk 

Download goldy.mw

@Markiyan Hirnyk This is one of several times that you have failed by mistakenly pasting in 1D Maple Notation plaintext code in as 2D Input. That will not work in general. It is very bizarre that you keep making this mistake.

It doesn't matter that you try to convert to 1D input, after pasting in as 2D Input. It's the initial pasting in as 2D Input that is invalid.

Paste it in as 1D Maple Notation code, into an input prompt that is in 1D Maple Notation mode. That works.

@moeinvh What does the command

libname;

return in your fresh Maple session?

If it doesn't contain that new folder location then your initialization file is not being run. (Is it perhaps saved as maple.ini.txt by accident? Or saved as rich-text by accident? What editor did you use?)

It seemed to open Ok for me using 64bit Maple 2015.1 on Linux.

Attached is a zipped copy, with the sections expanded.

Tema_a1.zip

acer

@Carl Love I had pasted in in from Maple, where it was correct. But then I mispasted when I changed instances of < and > to &lt; and &gt; inside the <pre> tags in html edit mode. I corrected it, thanks.

I prefer it with the wrapped procedure around `assuming` so that square brackets around expression on the left of the &as are not always needed, like in the following example of a function call.

restart;

`&as`:=proc(a::uneval) eval(`assuming`([a],[args[2..-1]])); end:

is(a^2 >= 0);

                             false

is(a^2 >= 0) &as (a::real);

                              true

@JVLB Sorry, I had forgotten what I was doing before. Yes, that's related to why I put in the comment, "Now, how shall we handle the derivative of this returned proc?". I'd have to think about it more, to try and get the repeated partials handled better in this way.

@JVLB That d is the list by which the original call to D was indexed. By this I mean that if I call D[3,2,2](A) then `D/A` gets passed the list [3,2,2] as its argument.

That subs(__d=d[],'D[__d](A)') business was just a way for me to make the procedure `D/A` returned the original call, as if unevaluated. There may be another simpler way to achieve that, but it's the first thing that came to mind. So if there is a situation with some list d that one doesn't know how to handle in `D/A` then the original input can just be returned.

For example, using the above code, these inputs just return as if unevaluated (or as if `D/A` and A had not been defined),

D[3,2,2](A);

D[3,2,2](A)(s,t,2);

Well, it not exactly the same. If `D/A` and A were not assigned then Maple may change the indexing [3,2,2] into [2,2,3]. I suppose this old post may be related.

@tomleslie Are floating-point implementations of the Heun function available in stock Matlab 2015b? Or does one have to resort to 3rd party code (such as by John Matthews)?

You appear to have omitted either a space or an explicit multiplication symbol at a few places.

For example, after the "2 u" in your very first line you have an opening round-bracket without any space or explicit multiplication symbol between them. This gets parsed as an instance of function application. Ie, as u(...) an application of the unassigned operator `u`. But you appear to have intended u*(...).

And then this issue continues throughout the document, as you subtitute in for `u`, etc.

acer

In case anyone was wondering about ways to reverse the order of integration, "by hand or using IntegrationTools".

Also, here too one must avoid use of typed literal `phi` and `theta` in the presence of escaped locals in the double integral returned by the `Flux` command.

Download fluxfoo2.mw

Intsead of converting the names to `global` and typing in the literal name `phi` I could also have used IntegrationTools:-GetVariable.

with(IntegrationTools):
Change(op(1,G), cos(GetVariable(op(1,G)))=t, t);

@Axel Vogt The names `phi` and `theta` in G are locals. Presumably this is so to cover the case that the user had previously assigned values to either of them. This makes it awkward to use IntegrationTools:-Change, since its 2nd and 3rd arguments have to contain the appropriate names.

Download fluxbah.mw

@EugeneKalentev By numeric quadrature,

evalf(Flux(vv, Sphere(<0, 0, 0>, 2.3), inert));
                          79.86766283

evalf(Flux(ee, Sphere(<0, 0, 0>, 2.3), inert));
                          79.86766283

@Carl Love I was pretty sure that's what you meant, sure.

However for this example it is faster to do evalhf(map(...)) than map[evalhf](...) on my 64bit Maple 2015 for Linux at least.

restart;
with(ImageTools):
img := Scale(Read(cat(kernelopts(datadir), "/tree.jpg")),10.0):

cimg:=CodeTools:-Usage( Complement(img) ):
memory used=243.56MiB, alloc change=241.09MiB, cpu time=190.00ms, real time=206.00ms, gc time=10.00ms

fimg:=CodeTools:-Usage( FitIntensity(img,1..0) ):
memory used=0.71GiB, alloc change=0.71GiB, cpu time=2.96s, real time=993.00ms, gc time=50.00ms

eimg:=CodeTools:-Usage( evalhf(map(x->1-x,img)) ):
memory used=243.53MiB, alloc change=243.53MiB, cpu time=2.90s, real time=2.21s, gc time=0ns

mimg:=CodeTools:-Usage( map[evalhf](x->1-x,img) ):
memory used=1.90GiB, alloc change=-243.53MiB, cpu time=7.08s, real time=6.67s, gc time=1.20s

One may also observe that neither map(x->1-x,img) nor evalf(map(x->1-x,img)) produce a result that Maple accepts as an image, since the result lacks the float[8] datatype. So I don't know what the OP intended -- there may even have been a typo.

And neither is as fast as FitItensity, which in turn is not as fast as Complement. Somewhat interestingly the former appears to be using multiple cores -- see the "cpu time" versus "real time". I ran the above on a quad-core machine. Perhaps with many more CPU cores I'd see FitIntensity perform more like Complement. Perhaps Complement could be multithreaded.