@Østerbro Attached is an edited version of your File.mw Document, in which units appear within the object.

I have been extending the object's functionality, and while I'm not yet finished or 100% satisfied it may be that you find this of some use.

Filemodif2.mw

I put the code that defines the package (which defines the object) into the Startup Code region of the Document, merely for convenience. Soon I hope to have it in an .mla, useful perhaps to others. For now you could use it in Startup Code as I do here, or the Document's body as you did before, or a Code Edit region, or LibraryTools:-Save it to your own .mla.

I've learned a few lessons about objects which I eventually hope to share with full comments in the code (eg, sequence return from static `*` and `+`), and found a few bugs (eg, static Re and Im), etc. And I have a number of aspects still to deal with (eg. evalc of product of a name and an object, better float contagion, etc).

And I've had to make some choices. I'm trying to be pretty agressive with automatic simplification of the object data. As it stands now unassigned names get pulled out of the object to make a product of terms. It might possibly be more ideal to have unassigned terms remain in the object, say, in the modulus. But I have not yet found a good way to get assuming to work with that. If I can't subs or evalat to replace names in the object (let alone temporary assumed names) then what's the use of not pulling them outside it?

Do you mean linewraps that are an effect of the displayed width of the TextArea Component?

acer

@torabi Why do you use lowercase pi instead of Pi?

It looks like you are trying to use LinearAlgebra:-Transpose. Either load the LinearAlgebra package (using the with command) before using the short command name Transpose, or use the explicit long name LinearAlgebra:-Transpose, or simply raise it to the power %T.

In at least one instance `.` was being used to multiply a nonnumeric scalar expression by a Matrix (it was somescalar . T if I recall...).  Use `*` there instead, if you want the multiplication to be distributed across the Matrix. I changed it.

Are you trying to apply that integration across all entries of S?

Is Y supposed to have a numeric value?

maple2modif.mw

It could also be pointed out that the zero-detection (tests whether an entry is zero) could be done with a call to the Testzero command, instead of merely using evalb (which is done above, implicitly via if M[...] <> 0 then constructs). That would allow the reduced procedure to handle better other coefficient domains without inadvertant and invalid use of a "hidden zero" as pivot. By default it would allow coverage for polynomials with rational coefficients, and using it would allow for easy adjustment for other domains.

Additionally, in order to keep expression swell down while reducing the addition and multiplication steps could use the Normalizer command. Apart from benefitting the size of the final result that could also help unburden the work done while zero-testing. And then a simple strengthening assignment to Normalizer could cover both reducing stage simplification as well as zero-testing, leaving Testzero to use Normalizer just as it does by default.

@Carl Love I don't think that the three elementary procedures are correct. Given the way that `reduced` is trying to use them, they are wrongly implemented.

For example, use `perm` to interchange a row with itself (should get identity, but instead get something with a zero-row). Either `reduced` should avoid calling `perm` when i=j or `perm` itself should handle that case properly.

Also, considering the way that `addition` and `multiplikation` get used in `reduced`, their last parameters are mistyped as integer.

@Østerbro Ok, I have it now. I see two things to deal with: a problem in the static `*` procedure, and the Units Formatting mechanism. I will endeavor to accomodate both.

@Østerbro That download link does not work for me. Please try again (just insert a link to your comment, not the entire contents inlined). I suggest a simple name with no special Danish characters, such as file.mw with only one period in the filename (your above had two). You can test that it worked, using the Preview to test the download link, before posting any new comment.

I don't really understand why you have used the 2D Input that looks like & (ampersand) before the typeset angle symbol. Was that deliberate, because you knew it wasn't the way it's intended to be used, but just wanted to convey the computation flow you want?

I think that I can enhance it, to work with units...

@Østerbro I cannot read that tiny font, and have little wish to type it all in by hand. Please attach a worksheet/document. Thanks.

I am whipping the module object into better shape, and will augment if I can figure out exactly what more you want or need here.

@vv I think your original 1st and 2nd example can be covered by correcting the lhs/rhs thing, and robustifying the `is` call used to `ormap` to avoid problems with FAIL (from `is`).

And then, yes, the 3rd example would return unevaluated for me, which as you say is at least not a wrong result. I'll think about that 3rd one too. As you say, the solution is easy for a person, but how it may misstep in the code may be another thing...

@vv As far as I can see so far, the example runs without error primarily due to either passing restricted ranges of due to passing float ranges.

If you pass the ranges x=-3.4..0 and y=0..3.4 then Maple 2016.x will return an incorrect result (failing to find value -1 at x=-Pi and y=Pi), regardless of whether the `location` option is supplied. 

I see the following in all of Maple 2015.2, 2016.0, and 2016.1. Notice that the location option does not seem to make the difference. With entirely float ranges the incorrect result attains, and with entirely rational ranges the ormap error is emitted. (And with some mixed ranges I saw mixed situations, but always the same whether `location` was supplied or not, as far as I noticed...)

restart; minimize((x+y)^2+cos(y), x = -34/10 .. 0, y = 0 .. 34/10, location=true);
Error, (in unknown) mapped procedure in `ormap' must return true or false

restart; minimize((x+y)^2+cos(y), x = -34/10 .. 0, y = 0 .. 34/10);               
Error, (in unknown) mapped procedure in `ormap' must return true or false

restart; minimize((x+y)^2+cos(y), x = -3.4 .. 0.0, y = 0.0 .. 3.4);                   
                                              -0.96679819

restart; minimize((x+y)^2+cos(y), x = -3.4 .. 0.0, y = 0.0 .. 3.4, location=true);    
                           -0.96679819, {[{x = -3.4, y = 3.4}, -0.96679819]}

That error from `ormap` is due to a check against results from `is` without accounting for a possible FAIL return. But not finding x=-Pi, y=Pi seems another issue.

[edited] oof. Line 39 of `minimize/cell/multivariate` sets up simple bounding inequalities from the ranges on the variables. It looks like it could be mistakenly using lhs(boundL[i]) instead of rhs(boundL[i]) to utilize the upper bounds. For the example at hand that'd mean that `isolve` would get the wrong bounding inequalities for the special case for y=Pi*_ZXXX . So the interior point y=Pi,x=-Pi wouldn't get found.

It looks to me like what you might have shown in your second timing is the how long it takes for Maple's CUDA attempt to fail and fall back to its regular mechanism. That would not be the same as a comparison "with/out CUDA" -- which would need it to have succeeded.

So perhaps the CUDA linkage is not working on your machine. How about adding the details of your Maple version and operating system?

acer

@anton_dys It's still less efficient since it calls `rhs` each time it's called.

@Carl Love ModuleCopy is invoked each time ModuleApply makes the Object(...) call. I think of it as copying the prototype to a new instance.

The 3rd argument of ModuleCopy is assigned to the local `labs` (magnitude) of the new instance (object), and if there is a 4th argument of ModuleCopy then it is assigned to the local `larg` (argument) of that new instance. The 3rd argument of that ModuleCopy is the lhs of the infix call to `&angle;`and the 4th argument of that ModuleCopy is the rhs of the infix call to `&angle;`, because those are the 1st and 2nd arguments respectively to the prefix call to `&angle;`.

The word "ModuleCopy" doesn't seem especially intuitive to me. I sometimes think of it more like an Instantiator (from template), or Factory.

Hmm, I'm not entirely sure what would happen if you replaced the internal calls to `&angle;` (ie. those which are not uneval quoted) with a call to ModuleApply. It's possible that it'd not be correct... some distinction between the ModuleApply of the class template and that of the new instance? I mean, hmm, are those calls (inside static exports `*`,`+`,`evalf`) to be considered more like calls to thismodule? You could try both and see.

@Carl Love I am not sure what can and cannot by used as infix operators when typing in 2D Input mode. It's possible that it mostly only works for leading-ampersand entities which are not yet recognized by the parser as having special definition and handling. I just get implicit multiplication when I try it with typeset Greek letters as the entity.

In 1D Maple Notation using such entity names seems problematic. The parsing of infix operator application seems to demand the absence of wrapping name-quotes, and as you guessed those are needed to stop the training semicolon on the names from inducing a syntax error.

There is also a bug with the reverse situaion, for which I first submitted a bug report long ago. If you create a compound name from a typeset Greek letter followed by some other letters, and then use this for an unevaluated function call of two arguments, then the output will be displayed like an infix operator call. Whether you like it or not. Eg, in 1D notation,

T:=`ΦHZ2`;
T(a,b);
T:=`Φ__2`;
T(a,b);

So it seems you can't use a subscripted atomic identifier with an entity base (like a Greek name) as an unevaluated two-argument function call without the Std GUI rendering it like an infix operator call! Good grief.

One mechanism or syntax gets used for multiple purposes, which leads to problems. A familiar story.

If you replace nonreal (complex) numeric values with zero then your new plot might contain unexpected/false elements, where those zeroes cause additional points/lines/polygons/whatever to be rendered.

You could try replacing with Float(undefined) instead of 0.

acer