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

Thanks for clarifying that, Doug.

Apart from this Table element mutability issue, what would you want to see improved in Maplets? The way in which only a child maplet can have the current focus, but not the parent (until the child is closed), is another issue.

And how would you rank the importance of elements missing from Embedded Components? What about the inability to programmatically control or define those components?

You've obviously had a great deal of experience with Maplets. Where do you think efforts would be best spent?

acer

Thanks for clarifying that, Doug.

Apart from this Table element mutability issue, what would you want to see improved in Maplets? The way in which only a child maplet can have the current focus, but not the parent (until the child is closed), is another issue.

And how would you rank the importance of elements missing from Embedded Components? What about the inability to programmatically control or define those components?

You've obviously had a great deal of experience with Maplets. Where do you think efforts would be best spent?

acer

It does seem like there are jumps, at elements 2,4,8,15,18, 21,26,28,..

plots[pointplot]([seq([i, 1/abs(ln(S[i]))], i = 1 .. 30)]);

acer

Is this illustrating how it might be done in Matlab?

acer

Is this illustrating how it might be done in Matlab?

acer