Converting gamma to a local is not easy if it's not obvious or well-documented enough for new users to discover it.
Suppose that one wants to be able to get the nice typeset 2D Math greek symbol for gamma to appear (and be used as a variable) in 2D input regions. How would one do that, precisely, after the convert(gamma,`local`) assignment to vargamma?
acer
Converting gamma to a local is not easy if it's not obvious or well-documented enough for new users to discover it.
Suppose that one wants to be able to get the nice typeset 2D Math greek symbol for gamma to appear (and be used as a variable) in 2D input regions. How would one do that, precisely, after the convert(gamma,`local`) assignment to vargamma?
acer
It should be easy for Maplesoft to allow support for a nice 2D typeset symbol which can be used as a variable even when the maple system already uses the name somehow. The user should not have to unprotect the name in order to do this, since in general that may cause the maple engine untold problems.
For example, it should be possible to teach maple to typeset, say, vargamma as the 2D greek symbol in maple input and output. The same thing should go for 2D typeset Pi, which some branch of science may wish to use as a variable name.
The extension prefix "var" may not be a good choice, as it is already used to distinguish two forms of symbol epsilon. But all that ought to be needed is some convention that is simple, consistent, and documented in order to give these 2D symbols safely back to the user as variables.
acer
It should be easy for Maplesoft to allow support for a nice 2D typeset symbol which can be used as a variable even when the maple system already uses the name somehow. The user should not have to unprotect the name in order to do this, since in general that may cause the maple engine untold problems.
For example, it should be possible to teach maple to typeset, say, vargamma as the 2D greek symbol in maple input and output. The same thing should go for 2D typeset Pi, which some branch of science may wish to use as a variable name.
The extension prefix "var" may not be a good choice, as it is already used to distinguish two forms of symbol epsilon. But all that ought to be needed is some convention that is simple, consistent, and documented in order to give these 2D symbols safely back to the user as variables.
acer
If one wishes to use maple to do such mathematics then it helps to understand its conventions.
Compare,
sols:=seq(RootOf(_Z^5+1,index=i),i=1..5);
evalf(sols);
with,
x:= (-1)^(1/5);
convert(x,RootOf);
This should illustrate how maple considers (-1)^(1/5), as the first 1/5th root of -1 going counterclockwise from the positive real axis.
Maple needs a convention for such things. It's pretty natural to talk here on mapleprimes with maple's conventions in mind. In that context, I think that I'm correct when stating that (-1)^(1/5) is not real. That's maple's default.
For more explanation, see the sections on principal roots at,
http://mathworld.wolfram.com/CubeRoot.html
http://en.wikipedia.org/wiki/Nth_root
There is a mechanism in maple which allows some operations to take place with only the reals in mind. Eg,
with(RealDomain):
x:= (-1)^(1/5);
acer
If one wishes to use maple to do such mathematics then it helps to understand its conventions.
Compare,
sols:=seq(RootOf(_Z^5+1,index=i),i=1..5);
evalf(sols);
with,
x:= (-1)^(1/5);
convert(x,RootOf);
This should illustrate how maple considers (-1)^(1/5), as the first 1/5th root of -1 going counterclockwise from the positive real axis.
Maple needs a convention for such things. It's pretty natural to talk here on mapleprimes with maple's conventions in mind. In that context, I think that I'm correct when stating that (-1)^(1/5) is not real. That's maple's default.
For more explanation, see the sections on principal roots at,
http://mathworld.wolfram.com/CubeRoot.html
http://en.wikipedia.org/wiki/Nth_root
There is a mechanism in maple which allows some operations to take place with only the reals in mind. Eg,
with(RealDomain):
x:= (-1)^(1/5);
acer
What you wrote, Robert, adds clarity to the Description section of the help-page ?module . Thanks.
At first I found the eleventh paragraph of the Description in ?module somewhat mysterious, especially the references to mimicking procedure evaluation and an "invocation step". Perhaps it is during this invocation step that any encountered `return` statements cause the instantiation to stop.
The statement in that help-page, "You can think of a module as the result of invoking a procedure that ``returns'' some of its local variables (its exported locals)" is interesting. But alongside the final form of body of the module, which as you say consists of assignment statements containing the "final" instantiated values of the variables, the statement seems unusual. The Description doesn't seem to me to fully describe what's going on, and what the consequences are.
Perhaps the help-page makes it clear to everyone else. I think that some more illustrative Examples might improve it.
acer
(-5)^(2/5) is not real and is not the same as - 5^(2/5) .
acer
(-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
