As it was presented, it is not permanent and would vanish upon restart. To become permanent it would need either to be savelib'd to a .mla archive that would subsequently appear in libname in new sessions or to go in an initialization file.

By a strange coincidence, I've been trying to hammer out a decent blog item which relates to patching the Library. (Actually, I've learned that issues come in clumps and clusters, so coincidences suprise me less and less.) Maybe this will motivate me to post.

acer

If you enter a subliteral from the Layout palette (or a subscripted table-reference which you then toggle as Atomic Identifier) then conversion from 2D Math input to 1D input using the context-menus will show the mark-up syntax.

One must be careful, when creating such atomic identifiers (subscripted names which are not table references), to ensure that they are exactly the same wherever they are used. The font information can also be embedded in the atomic identifier. Eg,

`#msub(mi("V"),mi("BE",fontstyle = "normal"))`;

If one intends to use this name in several places, and have maple understand that they mean the same thing, then such embedded font information must also match. If it doesn't match, then Library routines can see the differing instances as wholly different names (and so might not work as one intends).

acer

If you enter a subliteral from the Layout palette (or a subscripted table-reference which you then toggle as Atomic Identifier) then conversion from 2D Math input to 1D input using the context-menus will show the mark-up syntax.

One must be careful, when creating such atomic identifiers (subscripted names which are not table references), to ensure that they are exactly the same wherever they are used. The font information can also be embedded in the atomic identifier. Eg,

`#msub(mi("V"),mi("BE",fontstyle = "normal"))`;

If one intends to use this name in several places, and have maple understand that they mean the same thing, then such embedded font information must also match. If it doesn't match, then Library routines can see the differing instances as wholly different names (and so might not work as one intends).

acer

Yes, thanks, I had seen such cases. It's what I had in mind when I wrote of taking guidance, if possible, from knowledge of the background problem that is being solved. It may be that the optional arguments allowed by the `identify` routine could be used. But there would still be a need for ingenuity.

acer

It may be an art, I suppose, to do the best thing in such cases.

Sometimes the floats may come from physical measurement, and be accidentally near a "wrong" exact quantity.

Sometimes the background of the motivating problem may give hints or provide guidance. Eg, to prefer a radical over a trigonometric quantity, from `identify`.

I should have mentioned that `dsolve` allows disabling of the automatic conversion of floats to exact rationals, by the convert_to_exact=false option. But that's pretty much all that ?dsolve,details says on the matter, as far as alternative conversions go.

And the behaviour of `int` and `dsolve` appear at odds with each other. For `int`, it matters whether floats appear in the range of integration, for definite integrals. And for indefinite integrals it's not clear whether both back- and front-end conversion to exact values is done. Meanwhile, `dsolve` doesn't appear to call `dsolve/numeric` even for IVPs with floats in both the DE and ICs.

> restart:
> infolevel[`evalf/int`]:=1:

> int(1.2*sin(x),x=1..2);
                                  1.147738971
 
> int(1.2*sin(x),x=1.0..2);
Control:   Entering NAGInt
Control:   trying d01ajc (nag_1d_quad_gen)
d01ajc:   result=1.14773897089833854
                                  1.147738971

The inexperienced Maple user may trip up. The help-pages ?int and ?dsolve,details do (briefly) describe their behaviour in the presence of floating-point data in the input. But the best course of action for a given problem may be less clear without more explanation.

I often wonder how these aspects of Maple appear to the new user.

acer

One thing that applet builders can do which can be frustrating is produce source which is too convoluted. If the source code automatically produced is so unnecessarily over-complicated that it cannot be easily understood, viewed, enhanced or patched then it's got less usability.

When I last used the Maplet Builder it fell into this category, although of course "over-complicated" is a subjective view.

acer

Yes, that's a nice post Doug, thanks.

Let me try to analyze another post for a moment. To me it says that embedded components are important to Maplesoft.

But it also reinforces a suspicion that some people (developers, not the original poster) have not yet fully understood the significant difference between ease-of-use of point-and-click at the user end versus pain-of-development of point-and-click at the application authoring end. Having to use the mouse in order to use an embedded component is fine. Having to use the mouse in order to develop the application that uses embedded components is not good.

Mathematic 6 attempts to do it well. Matlab does too.

To me, the most important remarks in your post have to do with the hardship of entering so much embedded component control code via point-and-click. Also, your remark that you leaned heavily to having just a single function call in the embedded code (which you author elsewhere) is very telling.

acer

You write that it should not be necessary to use the name-quoted global name when supplying an optional argument. But for very many such option names, it currently is necessary, in order to avoid all potential clashes when the equivalent global name is unprotected and assigned (or if the name is also a local at the same level).

The fact that the documentation does not invoke option names that way, in Examples, etc, does not mean that this stated usage is not currently generally necessary for safe and proper working of the routines. On the contrary, it means that the documentation fails to adequately describe the current situation.

No doubt there are individuals who load the plottools package and then try to use point as an option name, and it fails because they did not pass it as ':-point'.

Even if not every relevant and affected help-page could have its examples changed (or some entirely new option name mechanism implemented), it would be nicer if this general behaviour and current "need" were described in some up-front and central location.

I don't think that this is "hacker" syntax at all. I've argued why it should be considered as normal usage syntax (ugly and distracting or not).

acer

Compare,

restart:
infolevel[solve]:=2:
solve({z*x^3-7*y*z,z*x*y-x+z^3*y^2-4,z*x^2-x*z^5-1},{z,x,y};

restart:
infolevel[solve]:=2:
solve({z*x^3-7*y*z,z*x*y-x+z^3*y^2-4,z*x^2-x*z^5-1},{z,x,y},split);

Supplying the 'split' option seems to force some factorization. Examination of SolveTools:-findsubs(), which gets called by  SolveTools:-PolynomialSystem (), shows lines like,

    if `solve/split` = true or 50000 < leqns then
        userinfo(2, solve, `too big, factorization attempted,
                            size=`, leqns);
        eqns := map(factor, ieqns);

acer

It must be an oversight, that the Explicit option is not documented on that page.

The name Explicit is not protected and might be assigned, which is why it's safer to use that quoted as an option name. It might also be the name of a local, if you use it within a procedure. Hence for safety I prefer the syntax which uses the quoted global name, eg,

solve(x^4+x-1,x,':-Explicit');

You can also control the behaviour of `solve` in this regard using the environment variable _EnvExplicit . That, I believe, is documented in ?solve,details .

The other environment variables that control solve are,

• _EnvConditionalSolutions
• _EnvTryHard
• _EnvExplicit
• _MaxSols
• _EnvAllSolutions

The environment variable _SolutionsMayBeLost is also used by solve, as output and not as input.

It would be nice if it were a unified help-page policy to have relevant environment variables listed altogether, right under the calling-sequence.

acer

Hi Doug,

Usually I have in mind "things that one enters directly, or commands in a maple script or worksheet". But that's not very precise. So maybe one could use the term to refer to calls which have no parent environment or scope. No doubt Jacques could tell us the formal CS term for it.

Note that some things are slower, expectedly, at the top-level, because things evaluate fully there. This is as opposed to within a procedure, where locals and parameter references may do just 1-level evaluation. One can actually quite easily cook up examples which run much faster within a procedure than outside it at the top-level, because of this.

So, within a worksheet or document, everything typed and displayed as input is (almost always, see ps.) parsed and evaluated at the top-level. An additional and more broad and noticable slowdown at the top-level due to 2D Math input alone is significant. I'm tempted to say "put Typesetting in the kernel", but I'm not really sure just how much of the effect is due to (Java) code in the GUI itself.

ps. Next Easter egg, special-evaluation rules, (effectively, if not literally) at the top-level.

acer

Hi Doug,

Usually I have in mind "things that one enters directly, or commands in a maple script or worksheet". But that's not very precise. So maybe one could use the term to refer to calls which have no parent environment or scope. No doubt Jacques could tell us the formal CS term for it.

Note that some things are slower, expectedly, at the top-level, because things evaluate fully there. This is as opposed to within a procedure, where locals and parameter references may do just 1-level evaluation. One can actually quite easily cook up examples which run much faster within a procedure than outside it at the top-level, because of this.

So, within a worksheet or document, everything typed and displayed as input is (almost always, see ps.) parsed and evaluated at the top-level. An additional and more broad and noticable slowdown at the top-level due to 2D Math input alone is significant. I'm tempted to say "put Typesetting in the kernel", but I'm not really sure just how much of the effect is due to (Java) code in the GUI itself.

ps. Next Easter egg, special-evaluation rules, (effectively, if not literally) at the top-level.

acer

I have been noticing this effect recently. Several of the worksheets and Documents that mapleprimes members have uploaded are written in 2D Math, and often are full of lots of top-level code. Re-executing these documents often involves a surprising delay.

It seems worse on 64bit Linux, where I can almost watch the 2D Math parser and Typesetting system crawl through each individual command. It's like using a 1200 baud modem all over again.

Actually, even using procedures doesn't avoid it completely, as the system pauses also while digesting the definition of procs written in 2D Math. Of course, subsequent execution of the procedures is OK.

acer

I have been noticing this effect recently. Several of the worksheets and Documents that mapleprimes members have uploaded are written in 2D Math, and often are full of lots of top-level code. Re-executing these documents often involves a surprising delay.

It seems worse on 64bit Linux, where I can almost watch the 2D Math parser and Typesetting system crawl through each individual command. It's like using a 1200 baud modem all over again.

Actually, even using procedures doesn't avoid it completely, as the system pauses also while digesting the definition of procs written in 2D Math. Of course, subsequent execution of the procedures is OK.

acer

I'm not sure whether the "information jumps" to which Jacques alluded are better measured as (the ratio of) absolute deltas or actual entries.

Eg,

plots[pointplot]([seq([i, (S[i]-S[i+1])/(S[i+1]-S[i+2])], i = 1 .. 50)]);

That seems to bring out jump points that match OK with the reciprocal log plot in another comment below.

Like so much else with plots, it's sometimes far easier to see a quality than to measure and detect it with code in a reliable way.

acer