I'd like to know what sorts of value m can take here.
Isn't the value of m going to make a difference, when you ask whether something like m+(m^2-pa^2-4*m+4*pa)^(1/2) is less than pa or not?
acer
I'd like to know what sorts of value m can take here.
Isn't the value of m going to make a difference, when you ask whether something like m+(m^2-pa^2-4*m+4*pa)^(1/2) is less than pa or not?
acer
Thanks Joe,
It's tricky. If one doesn't re-select the whole entry, in between those steps, then one can end up with the object conjugate(`#mi("foo")`). It has to be done just right, to get `#mover(mi("foo"),mo("¯"))` as the atomic identifier.
And there doesn't seem to be a nice easy visual way to tell what one has actually obtained. I notice that, having already tagged this accented foo as an atomic identifier, reselecting it and going into the context-menu again does not show the Atomic identifier checkbox as checked. This may be a bug. So not only is there no nice (not lprint) programmatic or visual way to ascertain the input object's "atomic identifier status", the clicky context-menu way is also problematic.
It would be very nice to have a fully programmatic (no mouse, non-interactive, non-command-completion) way in which to enter all types of object -- including those from the palettes -- that get fully typeset as 2D Math input.
acer
Thanks Joe,
It's tricky. If one doesn't re-select the whole entry, in between those steps, then one can end up with the object conjugate(`#mi("foo")`). It has to be done just right, to get `#mover(mi("foo"),mo("¯"))` as the atomic identifier.
And there doesn't seem to be a nice easy visual way to tell what one has actually obtained. I notice that, having already tagged this accented foo as an atomic identifier, reselecting it and going into the context-menu again does not show the Atomic identifier checkbox as checked. This may be a bug. So not only is there no nice (not lprint) programmatic or visual way to ascertain the input object's "atomic identifier status", the clicky context-menu way is also problematic.
It would be very nice to have a fully programmatic (no mouse, non-interactive, non-command-completion) way in which to enter all types of object -- including those from the palettes -- that get fully typeset as 2D Math input.
acer
It's not the initial double underscore that is key, judging by experiment. It is that particular string.
It may be used internally to denote the absence of a supplied legend by the user. As a design, I'd prefer to see the kernel or interface's built-in plotter be able to accept *no* legend to denote that situation. Maybe that's a matter of taste.
acer
There are quite a few talented Maple programmers in this world. An open source distributed computing maple add-on might be a good project. I could imagine that it might use Maple's Sockets package to distribute well-packaged subtasks out to seperate, distributed maple instances.
I'm surprised that there are few significant add-on packages for Maple developed outside of Maplesoft itself. I don't see why, with such a large an talented expert base, a commercial piece of software like Maple doesn't have more high quality open source (and possibly "free") contributions.
After all, one of Maple's strengths is the relative ease with which it can be extended.
acer
There are quite a few talented Maple programmers in this world. An open source distributed computing maple add-on might be a good project. I could imagine that it might use Maple's Sockets package to distribute well-packaged subtasks out to seperate, distributed maple instances.
I'm surprised that there are few significant add-on packages for Maple developed outside of Maplesoft itself. I don't see why, with such a large an talented expert base, a commercial piece of software like Maple doesn't have more high quality open source (and possibly "free") contributions.
After all, one of Maple's strengths is the relative ease with which it can be extended.
acer
> f := module() export g; g:=proc(x) x; end proc; end module:
> evalhf(f:-g(1.1));
1.10000000000000008
> evalhf(proc() f:-g(1.1); end proc());
Error, unable to evaluate function `f:-g` in evalhf
> proc() f:-g(1.1); end proc();
1.1
> g:=proc(x) x; end proc:
> evalhf(proc() g(1.1); end proc());
1.10000000000000008
There are two problems. The first was that top-level global sin was used instead of the module export foo:-sin. The second is that, more generally, evalhf can find and use module exports when outside a procedure but not when within procedures.
acer
To evaluate an expression at an instance of a variable, use the eval() command in its two-argument form.
For example,
E := sin(x)+x;
eval(E,x=4.0);
That will evaluate E with 4.0 as the value for x.
acer
The left-column space has almost nothing in it, while the right column space is much too full.
The "Recent Comments" list, in the right column, is the fastest changing, so it should be right up near the top.
It's unpleasant how, if one misses a comment before it passes out of this summary list by being superceded, it can't be found again without having to scan the dates on all the forums. And even then, clicking in the forum pages' topic links gets one only to the start of the topic, not to the most recent comment which is then so much harder to find.
Slowly changing summaries like recent blogs should be lower in the right column, and it changes so slowly. It also has a nice convenient backup mechanism to help one locate the recent blogs, in the top bar. If it has a top bar tab, like blogs does, it should be father down in the right column.
The announcements could go in the left column. Good idea, Axel.
My last suggestion here is that some (any, actually) of the other suggestions posted in the past be addressed. Those include comment title's overwriting content when browsers are not maximized, adding a bug reporting mechanism, fixing the way commonalities in user profiles (which appear as links) don't work, and returning the view count on blog entires (which Will said he look into, quite a while ago).
acer
While I thank you for the response, Jacques, I'll say that it sounds more like a description of the mechanism that might be used than a rationale for the behaviour. Which new user wouldn't get caught by this? Which expert would guess the (new to Maple 11) behaviour?
It's quite a fumble.
In Maple 10, it did not work like that. Maple would issue an error saying that p:-sin was unknown to it. Eg, "Error, unable to evaluate function `p:-sin` in evalhf".
If Maple 10 can figure out that p:-sin is unknown to it, then Maple 11 should be able to figure out not to dispatch to the global :-sin wherever the code contains the module member p:-sin.
It's a strange behaviour. Did I miss where it's documented, I wonder? Would it affect all function names mentioned in the help-page ?evalhf,fcnlist ?
acer
In Maple 11,
> save "myfile.m":
Error, must specify names to save
> a:=proc() local x; x; end:
> x:=5;
> y:=a();
> save y,a,x, "gg.m";
> quit
And now, in a new session,
> read "gg.m";
> y;
5
Did it ever actually save the local nature of the `x` which had been assigned to y?
Could it be done with a .mla and savelib? It seems not.
Also, did the save to .m mechanism ever fully support modules?
Another interesting example. Robert Israel (and Joe Riel) showed recently on comp.soft-sys.math.maple how to create a Vector/Matrix with the same symbol for the "unassigned" entries. For example,
U := Vector(2,symbol=convert('U',`local`));
(I doubt this is a sensible desire, since it bypasses certain guards on recursive assignments -- which would normally be desirable. Eg, U:=5*U, followed by accessing U[1]. Compare with the behaviour there of last_name_eval vector/matrix/array. But the user seemed insistent.)
If I do,
> save U, "gg.m";
> quit
then,
> read "gg.m";
> U;
Execution stopped: Stack limit reached.
so again the local nature of the U in the entries seems not preserved.
But, if instead I savelib the U Vector to a .mla, then in a susequent session I can apparently access U, U[1], etc. The difference is interesting.
acer
In Maple 11,
> save "myfile.m":
Error, must specify names to save
> a:=proc() local x; x; end:
> x:=5;
> y:=a();
> save y,a,x, "gg.m";
> quit
And now, in a new session,
> read "gg.m";
> y;
5
Did it ever actually save the local nature of the `x` which had been assigned to y?
Could it be done with a .mla and savelib? It seems not.
Also, did the save to .m mechanism ever fully support modules?
Another interesting example. Robert Israel (and Joe Riel) showed recently on comp.soft-sys.math.maple how to create a Vector/Matrix with the same symbol for the "unassigned" entries. For example,
U := Vector(2,symbol=convert('U',`local`));
(I doubt this is a sensible desire, since it bypasses certain guards on recursive assignments -- which would normally be desirable. Eg, U:=5*U, followed by accessing U[1]. Compare with the behaviour there of last_name_eval vector/matrix/array. But the user seemed insistent.)
If I do,
> save U, "gg.m";
> quit
then,
> read "gg.m";
> U;
Execution stopped: Stack limit reached.
so again the local nature of the U in the entries seems not preserved.
But, if instead I savelib the U Vector to a .mla, then in a susequent session I can apparently access U, U[1], etc. The difference is interesting.
acer
