@stefanv Thanks for the historical info, Stefan, and confirming that the plot code has its silver anniversary next year. I remember talking to some of the students working on Maple back in the mid-80s at U of Waterloo. A very enthusiastic bunch they were.

Paulina

@Oliver K Very fitting for a Maple anniversary! Thanks.

Paulina

I'm not a big Rush fan (Leonard Cohen is more my style), but my husband took my 15-year-old daughter to the Rush concert in Toronto this past Saturday. Now we have two generations of fans in my house.

Here's another Rush anecdote. Last fall, my husband and I attended a show at the Toronto International Film Festival. Before the movie started, we engaged in small talk with a friendly guy sitting next to us. He told us he saw Penelope Cruz at a film premiere the day before. Just then, the guy spots a friend walking by who shouts to him, “Guess who I just saw? Geddy Lee!” My husband and the guy both said almost simultaneously, “Wow, that’s WAY better than seeing Penelope Cruz!”

Paulina

Thanks for posting the workaround, acer. Yes, there seems to be a bug in NLPSolve in this particular situation (operator form, with failure of codegen automatic differentiation routines). Providing your own gradient routine is a good workaround.

Paulina

@Robert Israel: Nice! I'm impressed.

What Robert says is correct. The plots:-display command accepts plot structures that have already been created. It does not cause the plots to be regenerated with new sample points.

The other thing to keep in mind is that Maple uses a default range of -10..10 when there is no other information given. To get a plot that is sufficiently smooth, it's a good idea to give Maple as much information as you can. If you know that the region of interest is -1..2, then it's best to specify that in the initial plot calls.

By the way, in Maple 14, you can create the plots in these examples with one command. See this post.

Paulina

Robert, I don't think your example is a bug:

> NLPSolve(int(exp(sin(c*x)), x=0..1));

In this situation, the optimization variables are not specified, so NLPSolve thinks they are 'x' and 'c'. It tries to evaluate the expression at x=1.0, thus generating an error when int is called. The solution is to add the variables option:

> NLPSolve(int(exp(sin(c*x)), x=0..1), variables=[c]);

Paulina

Robert, I don't think your example is a bug:

> NLPSolve(int(exp(sin(c*x)), x=0..1));

In this situation, the optimization variables are not specified, so NLPSolve thinks they are 'x' and 'c'. It tries to evaluate the expression at x=1.0, thus generating an error when int is called. The solution is to add the variables option:

> NLPSolve(int(exp(sin(c*x)), x=0..1), variables=[c]);

Paulina

Thanks for the suggestion, acer. Indeed, I was rather hasty with my reply. I meant to explain that the backslash character has a different meaning in 2-d math, but we will look at the situation to see if can be improved in any way. I haven't had the chance to test this out thoroughly, but in some cases (e.g. when output in Maple with the line continuation character is copied and pasted back into an input line), the input is parsed as expected. The backslash, entered directly, has a different meaning in 2-d math from 1-d math, and that is unlikely to change, but you are right that some of the copy-paste situations might be fixable.

Paulina

A correction to my previous post: 

# valid in 1D but not in 2D
x := 12.34567\
89012345;

This is not a bug. In 2-d math, the backslash is not used as a line continuation character but it is used as the set minus operator. This is one of the situations where there is an intended difference between the two parsers. I'll add a note to the documentation if it's not already mentioned in the help pages.

Paulina
 

We'll definitely consider your comments, acer, and we'll review the current design for parsing m!=n to see if it's reasonable. Can't promise anything, though. Changing the interpretation will have some consequences, so we'll have to think it over carefully.

Paulina

Thanks for the thorough post, acer. I'll go through each of the cases you mentioned.

restart:
# valid in 1D but not in 2D
f:= x -> if x < 0 then a else b end if;

This is a known bug. I realize it has been reported before. We're not ignoring it, but it is somewhat difficult to fix and not of the highest priority right now, because there is a workaround available (using proc syntax instead of the arrow operator). We will try to deal with this as soon as possible or make a note of it in our documentation, as has been suggested elsewhere.

restart:
# valid in 1D but not in 2D
x := 12.34567\
89012345;

This is a bug.

restart:
# works differently in 1D and 2D
sin (x);

restart:
# works differently in 1D and 2D
f := proc (x)
  x^2;
end proc:
f(3); f (3);

Both of the above examples are a consequence of 2-d input's implicit-multiplication rules.

restart:
# works differently in 1D and 2D
m!=n;

This is, as you observed, by design. When you enter != or paste it, it immediately turns into <>, so at least users are not misled into thinking it has a different meaning.

restart:
# valid in 2D but not in 1D
2.sin(x);

This again is an instance of implicit multiplication. You are right in that the parsing rules regarding the decimal point vs. the dot operator should be explained more clearly in the documentation. I will add that request to our bugs database.

restart:
# valid in 2D but not in 1D
f := proc(x);
local a,b,c;
a:=x^2;
end proc;

This is a bug in the 2-d parser.

restart:
# bug in 2D
# first enter this in 2D mode, but don't Return
<|>(7);
# now wrap the <|> in ` name quotes, using the arrow
# keys to move the input cursor around. The result is not the same as before.
`<|>`(7);

This also looks like a bug.

I'll check our database to see if these bug reports are already present, and if not, I will add them. If you've submitted any of them already, please let me know. Thanks.

Paulina Chin
Maplesoft

Yes, you are quite right, Robert. It looks as if the differences in Doug's post are related to the numberfunctions setting. This is a situation where we deliberately veered from compatibility with 1-d. In 1-d math, 3(x) evaluated to 3. Most 2-d math users would not expect this, so we changed the default interpretation. However, the numberfunctions setting had to be added for users who wanted to have this interpreted as in the 1-d input case. We're aware that this feature can be a potential source of confusion when worksheets are shared between users. This issue is also on our list of things to investigate and improve.

Paulina

A number of you have brought up, in this and earlier threads, problems related to implicit multiplication. I'd like to mention that we are indeed aware of these weaknesses and bugs and we are investigating long-term solutions. As Jacques suggests, there are some fundamental issues we need to examine, so it may take some time to complete the improvements. I just wanted to reassure everyone that we are taking these problems seriously and are working on making 2-d math more usable.

Also, to clarify some points that have been raised here: there are two parsers in Maple, one for 1-d math and one for 2-d math. Generally, documents don't contain execution groups and input is in 2-d math, while worksheets have execution groups in which it is easy to switch between 1-d math and 2-d math input. The same 2-d parser in used in both cases. There shouldn't be differences in the results if the same command is issued in a Document and in a Worksheet.

Paulina Chin
Maplesoft

Sorry, I missed seeing that BoxPlot has its own 'captions' option. I'll enter this bug into our database.

Paulina