Implicit multiplication
163Here's a tip for people new to Maple or to 2-D input: always use a space for implied multiplication. 2-D math input in Maple allows for implicit multiplication, which is writing a multiplication operation without an explicit multiplication operator. An example is x y.
The space is not always required in cases where there is no ambiguity. However, it is highly recommended that you include it. An example that catches many new users (and some experienced ones as well) is s(t+u). This does not mean s times t+u, but the function s applied to t+u
An exception to this rule is when the multiplier is a constant. By default, 2(x+y) is interpreted as 2 times x+y rather than the operator 2 applied to x+y. (Note that this expression entered in 1-D math returns the value 2.) See the 2DMathDetails help page for more information about changing this default behavior and further details about implicit multiplication.
- pchin's blog
- Login or register to post comments
- Try Maple 9.5
48 min 3 sec ago - Thanks a lot.
I have
7 hours 13 min ago - This site
7 hours 16 min ago - Great improvement
7 hours 23 min ago - 64-bit Ubuntu
8 hours 27 min ago - misunderstood
9 hours 1 sec ago - java -version
9 hours 51 sec ago - Exactly
8 hours 53 min ago - Standard vs. command line
9 hours 52 min ago - sort of
9 hours 53 min ago
- Does Maple 12 support Ternary diagrams?
- Table from procedure
- Maple Mentor Awards: The Big Kahuna
- The actual architecture
- new package adoption
- Conjectures ripe for Maple experimentation
- overloaded operators
- poll: change in Maple that you want most?
- The future of FourierTrigSeries package
- Maple 12.01 is now Available
Comments
Explicit multiplication
Even better: use * and there's never any problem.
Implicit multiplication is a good example of how trying to make something easier can end up making it more complicated.
Does the .mw save that parsing rule?
Does the .mw file itself save any preferences that dictate how "ambiguous" typed 2D input expressions such as 2(x+y) is to be parsed?
If not, then how do you debug a problematic worksheet sent from someone else? Or does the input somehow become an "object", as opposed to mere syntax? Would the typesetting itself embed the distinction, and if so would one still need to convert it to 1D maple input in order to understand it for debugging purposes?
acer
In fact, it does
If you look at the XML code of the .mw file, you'll notice that without the Typesetting[Settings](numberfunctions=true); option set, 2(x+y) is stored as
"`*`(2, `+`(x, y))", and with that setting active, it is stored as"(2)(`+`(x, y))".Another interesting note: The expression 15(7+6) was stored as
"`+`(`*`(15, `*`(`+`(7, 6))));". There seems to be an unnecessary `+` added into the expression.Re: In fact, it does
Yes, the parsed input is saved in the worksheet but it's safer to use the Typesetting[Settings] command. If the user of the worksheet re-executes it, then the user's default settings are applied and the original parsed meaning is lost.
Paulina
design
So the user has to do this optional thing, explicitly, to get the .mw file to save enough about the parsed meaning for it to be reproducible when re-executed by someone else?
And if that optional thing (involving Typesetting[Settings]) is not done then the worksheet works for the original user regardless? And the natural method of 2D Math input can provide the user's desired parsed meaning for something, without having to do that optional thing?
That isn't a good design.
It'd be OK for some display characteristics (display of floats, etc) to be different. And different security settings should be respected. But parsed meaning of the input, that should be preserved. The author should not have to do anything special, for the intended parsed meaning to be saved along with the file, so as to allow correct reproduction upon execution elsewhere.
Moreover, the typesetting settings of any other user should control only what they themselves enter. Having the user's settings affect re-execution of pre-existing worksheets, by reparsing the input as if it were being re-entered altogether, is not good.
I'm having a hard time believing that this is the default behaviour, and that things can be that bad if the original author does not take an extra unobvious step. I'm hoping that I've misunderstood.
acer
Typesetting package = bad
Unfortunately, it appears that you have not misunderstood what is happening.
This only goes to strengthening my belief in the idea that the Typesetting package has not improved Maple in any way.
You forget the intended audience
The new GUI was designed for beginner users. And beginners don't do weird things like change default settings for input.
All the bugs that are being documented here are indeed bugs as far as I am concerned, but their source isn't faulty design. The source is faulty requirements analysis! At the absolute minimum, there should have been a requirement that said "these new beginner features should have no undesirable effects on advanced users", from which what you document above could clearly be identified as bugs. But it does not seem like there was such a requirement, and so no use cases (or test cases) were developed to ensure that these negative effects were not present.
The funny thing is, on another mailing list I was arguing with some of the Maple developers that it might, in fact, be a good idea if sometimes the interpretation of user input was context-dependent (i.e. so you could use notation more like standard mathematics, which is very context-dependent). I was shot down in flames by several developers, telling me how horrible it would be to have the interpretation of user input be context-dependent. And now I see that that is exactly what they implemented, albeit most probably by mistake!
Use Typesetting[Settings]
Acer, if you are creating a worksheet and using a non-default parsing rule, then I would suggest adding the rule to the worksheet with Typesetting[Settings]. For this particular case, you'd add the command Typesetting[Settings](numberfunctions=true).
Paulina
re-map keyboard
Maybe I will re-map my keyboard so that the spacebar becomes * and * becomes the "space character".
Then I will have implied multiplication with dignity.
Maple syntax is mathematical syntax
Implicit multiplication is common in mathematics. And function application is commonly written as f(x), which makes z(x+y) syntactically ambiguous. Maple is just trying to be like mathematics. It is not Maple's fault if mathematics has inherent syntactic ambiguities, no explicit indication of function application, and so on.
People have been happy with Maple's 2-D output. Now they are starting to use 2-D input, and are discovering the problem. But WYSIWYG input is naturally wanted by many users. And it is surely nice to be able to Ctrl+c some output and then do Ctrl-v and have the pasted input look exactly the same.
In other words, if you agree that Maple output should look like common math, then you should agree with allowing input that looks the same. The choice is to either keep common mathematical notation, with its problems, or use some other notation that is unambiguous. I like the Maple choice.
Unambiguation
For a somewhat detailed treatise on the world of ambiguous mathematical statements, please read The Foundations of Differential Geometry by Kobayashi and Nomizu.
That comment aside, Kobayashi and Nomizu's work (as well as most mathematical statements, such as the ones you pointed out) are only ambiguous when taken out of context. It is context that makes sense out of similar mathematical statement. The statements f(x+y) and x(y+z) are ambiguous until I state (explicitly or implicitly) that f is a function (of one variable), and x, y, and z are all constants (elements of the same ring, where the operation of "multiplication" is written as juxtaposition of elements). If a user were able to explicitly put such context into a Maple worksheet in a visible and executable manner (I do not believe that the
assume()command has enough power to support all of this), then there wouldn't be any problem.I, for one, do not like the Maple choice. I seek unambiguous notation.
Mathematics is a typed language, Maple is not
What you are saying is that, while the language of mathematics is syntactically ambiguous, it is generally not semantically ambiguous because most mathematical statements are done in a context from which types can be inferred, which serve to disambiguate the syntax. With this, I agree wholeheartedly.
However, Maple is a fundamentally untyped system. It is not, however, context-free. Assignments (and assume) build "context" after-all, and this context is used in all subsequent computations. Is it possible to use the current notion of context to disambiguate enough of mathematics to make things useful? I don't know, but it is certainly an interesting question.
There is another interesting book on this topic: Cajori's A History of Mathematical Notation (never mind that it dates from 1929, nothing substantial has changed in mathematical notation since!).
unambiguous notation
Suppose that f,g,h are functions. What does f(g+h) mean?—f×(g+h) or f applied to g+h? (This assumes that f has an appropriately large domain.) As this illustrates, even knowing the types, you cannot unambiguously parse all expressions in mathematics.
I suspect that what users really want is for Maple to have a
psychicmode. André Heck discusses something a little related in his Introduction to Maple [2003: p.250]: evaluateThe answer given by Maple is too complicated and includes a limit; reevaluating with the assumption c>0 gives the expected (simple) answer. Heck comments thus: “… you may think of c as a positive real constant, by Maple does not start from this assumption!” Until the developers implement
psychicmode, we will have issues.I agree that having an unambiguous notation has strong advantages. Way back when, Ken Iverson proposed revising mathematical notation, or at least a subset of it. Modern notation for floor/ceiling is due to him; previously, brackets were commonly used. Little else made it into the mainstream. (Some of his ideas were implemented as a computer language, APL; originally, though, his plan was for inter-human communication.)
I thought that Iverson's basic idea was really good—so good that I spent time working as a colleague of his on the plan. It is fair to say, then, that I am a really big supporter of unambiguous notation.
But mathematics has its conventional notation. Maple should support this on output. Given that and WYSIWYG, then, as I said above, you have current Maple input, or something very similar.
Chicken and the egg
Suppose that f,g,h are functions. What does f(g+h) mean?—f×(g+h) or f applied to g+h?
Well, then we get back to nitpicking context. Are f,g, and h functions from the same ring? Are g and h functions from the same group? Is g+h in the domain of f? How are you representing multiplication in other cases? How are you representing function application in other cases? Etc. ...
This game can be played ad nauseam. Instead, I'd like to agree that most of Iverson's ideas were (and still are) really good, and note that APL seems to still have a decent user base (myself included).
Mathematics may have its conventional notation, but conventions change over time and space; not everybody uses the same conventions for marking up mathematics. To move away from implicit multiplication (as we seem to be riding it like a dead horse in the Kentucky Derby), take line breaking for example: If one must line break between the two operands of a sum or difference ( e.g. a + \n b ), does one put the plus/minus sign before the new line, after the new line, or both? Depending on who you ask, you'll get all three answers.
It's one thing for Maple to support a certain convention for output, it's quite another for Maple to try to support as many conventions as possible via WYSIWYG input. If personal typesetting rules were somewhow inherent in the worksheet and would enforce themselves when opened on foreign machines, then things wouldn't be as problematic; however, that would, itself open a large can of worms.
I think I'm just rambling at this point--I should try to make a concise point and end this post.
The .mw format of the worksheet does store the specific typesetting rules/format for any line input and run in the Maple worksheet. This format / these rules are disregarded when lines of the worksheet are executed in a foreign environment. This design would lead to unnecessary clutter caused by the user entering extra lines specifying typesetting rules for particular lines so that when the worksheet is run in its entirety (and sequentially) in a foreign environment, the work remains correct. Disregarding my opposition to Maple's current 2-D Math Input mode, this simply does not seem to be an effective system overall.
Maple should not have psychic pretensions
A colleague who works with physicists likes to make some of the above points about context with the following example:
...
T(x,y)=k*(x^2+y^2)
T(r,theta)=???
...
A true mathematician, and Maple (at least for now), will respond that T(r,theta)=k*(r^2+theta^2).
A physicist or psychic, who infers meaningful context, will respond that T(r,theta)=k*r^2.
It is fine with me if the physicists and psychics do this, but I do not want Maple to infer syntactical context without my explicit permission, invoked with something like
with(psychic);
----------
On a related side note:
Try this sequence of symbols (issued from a keyboard of course...not with carpal-tunnel point-and-click!)
x/y/z
(a) when input is in Maple notation and (b) when input is 2D.
In case (a) you will get x/(y*z), and in case (b) you get (x*z)/y. Disgusting.
I had a polite discussion with my daughter's elementary school teacher about the keystrokes x/y*z
(they were using numbers instead of variables, and paper-pencil not keyboard, and the division sign.. \div in LaTeX..instead of fraction bars.)
She marked my daughter wrong when she parsed it as (x/y)*z. The teacher's reasoning amounted to the assumption that multiplication takes precedence over division. My reasoning was that multiplication and division are equivalent just like + and - are equivalent, and so you break ties from left to right.
I did not confuse the polite discussion by telling her that I learned linear algebra out of Herstein, who writes xT instead of T(x).
On the topic of literal input
Maple is horrendous when it comes to input in Maple (1D) versus 2D notation. When multiple exact same keystroke sequences or lines (see this post) end up parsing as entirely different entities, it's amazing to think that Maple can actually understand itself (see this post for a discussion of a major area in which Maple does NOT understand itself).
Interestingly enough, if one escapes the slashes in the division when entering
x/y/zinto Maple in 2D input (i.e. the literal keystrokes would bex\/y\/z;), then Maple returns the same result one would have received from entering the division in as Maple (1D) notation.2-D input
Those are pretty strong terms— “disgusting” and “horrendous”! I guess that if you are used to 1-D input, 2-D input can be a little strange at first.
Maple, though, is behaving fine. As another example, suppose that you type “2^3+4” (without the quotes). In 2-D, as soon as you type the “^”, you are put into superscript; thereafter, everything that you type is in superscript, until you specify otherwise. Thus we get following.
“2^3+4” in 2-D:
“2^3+4” in 1-D:
2^3+4 = 12We've typed the exact same keys in both cases, yet we get different results—correctly.
As Schivnorr observes, you can prevent treating a character specially by escaping it.
“2\^3+4” in 2-D:
typesetting interpretation of a/bc
And yet, a/bc is usually interpreted in typeset notation as a/(b*c). In the International Union of Pure and Appled Chemistry rules: "In evaluating combinations of many factors, multiplication takes precedence over division in the sense that a/bc should be interpretaed as a/(bc) rather than (a/b)c; however in complex expressions it is desirable to use brackets to eliminate any ambiguity" Usually the IUPAP (physics) and IUPAC (chemistry) rules are in agreement, and when I write papers with my mathematics colleagure, we also use this convention, so I think it is fairly universal.
(I am thinking as it it written on the page, i.e., output, here; I am not suggesting input a/b*c be interpreted this way, since (a/b)*c is the standard programming interpretation of input.)