The desirable goal seems not to avoid `op`, but rather to find a single methodology which automatically does the simplification for expressions in the given class. (Hence, more examples might be useful, although we might be able to guess the general class as involving rational powers, etc.)

In your subs/eval code, the foerknowledge of the power 1/3 & 3 seemed key. An automatic method wouldn't rely on having determined that by inspection.

acer

And what you wrote there (including &^ vs Power) is good to know, and to be reminded about.

acer

And what you wrote there (including &^ vs Power) is good to know, and to be reminded about.

acer

Curious coincidences are fascinating. I might only imagine it, but it seems to happen often that some topic in Maple comes up in a cluster of different places.

For some weeks now, I've been hoping to find time for a semi-finished blog post, about how one might "load" a function from a "3rd party" .dll while in Maple, and then pass that to another external routine using the techniques of address+function-pointer. The idea is to get better efficiency when using Compiler:-Compile'd routines, as opposed to using the usual, less direct evalMapleProc callback. I hope to find time to finish the post in about 2 weeks.

And then by another coincidence, the same technique came up as the way to solve a very similar issue is a project I was working on last week. And now Axel mentions what sounds like the same thing in essence.  (I'm not at all surprised that Axel would have done it -- just amused that it arises right now.)

acer

Curious coincidences are fascinating. I might only imagine it, but it seems to happen often that some topic in Maple comes up in a cluster of different places.

For some weeks now, I've been hoping to find time for a semi-finished blog post, about how one might "load" a function from a "3rd party" .dll while in Maple, and then pass that to another external routine using the techniques of address+function-pointer. The idea is to get better efficiency when using Compiler:-Compile'd routines, as opposed to using the usual, less direct evalMapleProc callback. I hope to find time to finish the post in about 2 weeks.

And then by another coincidence, the same technique came up as the way to solve a very similar issue is a project I was working on last week. And now Axel mentions what sounds like the same thing in essence.  (I'm not at all surprised that Axel would have done it -- just amused that it arises right now.)

acer

Those results don't make it as clear as it could be.

The timings for that above code actually vary, on my machine. Sometimes they appear as .047, sometimes as .031 for both seq and map when all else is handled the same. I get no consistent timing difference. So, much less interesting than the subsop vs map distinction.

Secondly, the memory allocation (increase) ratio between subsop and map was a factor of 14, while between map and seq was shown (above) as the less dramatic factor of 4. See next point for more on this.

Thirdly, the method using seq above also uses &^ instead of `Power`.  But the map method's memory increase is halved if &^ is used there too. So the memory increase ratio between map and seq is actually closer to 2.

Lastly, both seq and map should be linear in memory allocation (when used in ways as equivalent as possible, all other things being equal, unlike as shown above). So their relative merit is likely not in the same class as the distinction between quadratic memory use with subsops vs linear use with map.

acer

Those results don't make it as clear as it could be.

The timings for that above code actually vary, on my machine. Sometimes they appear as .047, sometimes as .031 for both seq and map when all else is handled the same. I get no consistent timing difference. So, much less interesting than the subsop vs map distinction.

Secondly, the memory allocation (increase) ratio between subsop and map was a factor of 14, while between map and seq was shown (above) as the less dramatic factor of 4. See next point for more on this.

Thirdly, the method using seq above also uses &^ instead of `Power`.  But the map method's memory increase is halved if &^ is used there too. So the memory increase ratio between map and seq is actually closer to 2.

Lastly, both seq and map should be linear in memory allocation (when used in ways as equivalent as possible, all other things being equal, unlike as shown above). So their relative merit is likely not in the same class as the distinction between quadratic memory use with subsops vs linear use with map.

acer

It appears that the "Alternate text" in the Properties of the images of 2D Math Example in the Online Help now contain the equivalent 1D Maple notation input. That makes it possible to copy Example code using the mouse pointer. That's great.

It seems to work even for lines that refer to an equation label.

The copying process may require a little effort depending on the browser (for me, it is right click on a 2D Math image, choose Properties from the popup menu, then select and copy the Alternate text field in the Element Properties popup window). But it can now be done.

Hopefully there will eventually be a mechanism to view the Examples with all input code displayed in (directly selectable) plaintext 1D Maple notation.

Thanks, Will.

acer

It goes wrong not because it is called as Sum(rec(...)) but rather because it is called with symbolic argument.

> forget(evalf):
> evalf(rec(4, 0.2, 3-u, 4, 1)):
> subs(u=0,%):
> evalf(%);
                                      22.

> forget(evalf):
> evalf(rec(4, 0.2, 3-u, 4, 1)):
> eval(%,u=0):
> evalf(%);
                                      22.

When called with symbolic 3rd argument, the lack of protection against invalid cancellation of "k"'s gets a wrong result. One can see this by stopat(`evalf/Sum1`) and observing the args coming in, I think.

The call rec(4, 0.2, 3-u, 4, 1) evaluates because evalf/Sum has normal evaluation rules as mentioned earlier.

note: mint and maplemint print the message,

    These names were used as global names, but were not declared:
      k

acer

If the names inside an expression get assigned, then why do you need to call `subs`? Why isn't usual assignment of the names, by itself, enough? What's your example, for which subsequent evaluation of the expression wouldn't serve?

> expr := a+b+c;
                               expr := a + b + c
 
> (a,b,c):=17,Z,Pi:
> expr;
                                  17 + Z + Pi

acer

As was pointed out earlier, it is still wrong because there is multiplication by,

((D@@2)(f))

((D@@2)(f)(x))

x := evalf(x -(f(x)/D(f)(x)) + ((((D@@2)(f)(x))*((f(x))^2))/(2*(D(f)(x))^3)));

> NEWTON_RAPH(x->x^3-5,1,10);
                                  1.709975947
 
> %^3;
                                  5.000000003

acer

As was pointed out earlier, it is still wrong because there is multiplication by,

((D@@2)(f))

((D@@2)(f)(x))

x := evalf(x -(f(x)/D(f)(x)) + ((((D@@2)(f)(x))*((f(x))^2))/(2*(D(f)(x))^3)));

> NEWTON_RAPH(x->x^3-5,1,10);
                                  1.709975947
 
> %^3;
                                  5.000000003

acer

A graph was not needed for this one,

Student:-Calculus1:-Roots(df,x=-1..3,numeric);

acer

A graph was not needed for this one,

Student:-Calculus1:-Roots(df,x=-1..3,numeric);

acer

I don't quite understand what your meaning.

On second glance, it appears as if you might have 2D Math input there. (That lprint and prettyprint stuff was all about what one can do with prior results and output, rather than input.) Now, that should still be handled properly and converted to lineprinted 1D input if you Export as "Maple Input (.mpl)". Make sure to choose that export file type, not any of the others.

Also, are you in a Document or a Worksheet? Is your default 2D Math or 1D Maple notation input? Note that you can easily change both of those, via the Tools -> Options choices on the top menubar. I mean, why enter equations as 2D if you just end up wanting 1D in the end...?

Sorry, if I still haven't understood you.

acer