(-5)^(2/5) is not real and is not the same as - 5^(2/5) .
acer
A piece of code may be "close" to more than one (possibly quite different) valid interpretaton. Reporting well on a syntax error in such cases is not a "solved" problem.
For illustration of this, consider sections 3.1 and 3.3.3 of your last "truly modern" link, which hint at some of the difficulties. Also tradeoffs between completeness and redundancy in the reporting are, apparently, hard to avoid. As concluding section 3.4 points out, even that work's omniscient algorithm is not always suitable in such situations (eg. only for smaller sentences where the error is likely left of the detection point). Other difficulties arise when the code comes from a 3rd party, and the intended interpretation is not available -- see concluding section 3.4.
acer
A piece of code may be "close" to more than one (possibly quite different) valid interpretaton. Reporting well on a syntax error in such cases is not a "solved" problem.
For illustration of this, consider sections 3.1 and 3.3.3 of your last "truly modern" link, which hint at some of the difficulties. Also tradeoffs between completeness and redundancy in the reporting are, apparently, hard to avoid. As concluding section 3.4 points out, even that work's omniscient algorithm is not always suitable in such situations (eg. only for smaller sentences where the error is likely left of the detection point). Other difficulties arise when the code comes from a 3rd party, and the intended interpretation is not available -- see concluding section 3.4.
acer
It would be nice to get an on-the-fly syntax aware code editor within the Standard interface. It'd also be nice to get $include support in that interface. And it would also be nice to get lots of the other mint functionality right in that interface. (I wonder how hard it would be to write a context-menu kludge for that last one, possibly using temp files and system calls.) I susepct that lots of users would appreciate such enhancements.
You described a few different situations. One was editing within a GUI (you mentioned execution groups). But you also mentioned the possibility of using an external editor, which to me connotes use of plaintext source files. You say that mint does not help, and is of little help in syntax checking. But when authoring code in an external editor, I do find that mint can help, including sometimes showing the location of syntax errors. This is related to why its help-page description calls it the Mint Syntax Checker.
I do see why it would be so much nicer to see the code marked up graphically on-the-fly, to show some common syntax problems. That's why I mentioned that using mint requires an extra step.
Defining the best location for indicating a syntax error is difficult in general. And there must be some sorts of syntax error which are quite a bit harder to detect than, say, bracket matching.
acer
It would be nice to get an on-the-fly syntax aware code editor within the Standard interface. It'd also be nice to get $include support in that interface. And it would also be nice to get lots of the other mint functionality right in that interface. (I wonder how hard it would be to write a context-menu kludge for that last one, possibly using temp files and system calls.) I susepct that lots of users would appreciate such enhancements.
You described a few different situations. One was editing within a GUI (you mentioned execution groups). But you also mentioned the possibility of using an external editor, which to me connotes use of plaintext source files. You say that mint does not help, and is of little help in syntax checking. But when authoring code in an external editor, I do find that mint can help, including sometimes showing the location of syntax errors. This is related to why its help-page description calls it the Mint Syntax Checker.
I do see why it would be so much nicer to see the code marked up graphically on-the-fly, to show some common syntax problems. That's why I mentioned that using mint requires an extra step.
Defining the best location for indicating a syntax error is difficult in general. And there must be some sorts of syntax error which are quite a bit harder to detect than, say, bracket matching.
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
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
