Dr. Paulina Chin

## 1301 Reputation

17 years, 185 days
Maplesoft
Senior Architect

## Thanks...

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

Paulina

## Rush fans in my family too...

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...

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

## A very good approximation...

@Robert Israel: Nice! I'm impressed.

## Default range...

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

## Use 'variables' option...

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

## Use 'variables' option...

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...

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

## Correction...

```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

## Will consider...

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

## Explanation of parser differences...

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

## Typesetting[Settings]...

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

## Implicit Multiplication...

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

## BoxPlot captions...

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

Paulina

## BoxPlot captions...

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

Paulina

 1 2 3 4 5 6 7 Page 3 of 8
﻿