6.68 assume and protect (11.9.98)

6.68.1 Brillet Jean

What do you think about that ? (MAPLE r5 for Mac)

> protect(Z): 
> assume(Z>0); 
Error, (in t1) attempting to assign to `Z` which is protected
 

OK, now

> unprotect(Z): 
> assume(Z>0): 
> protect(Z): 
 
> about(Z); 
Originally Z, renamed Z~: 
  is assumed to be: RealRange(Open(0),infinity)
 

OK, but

> assume(Z<0);
 

Despite the protect() statement, there is no error message and

> about(Z); 
 
Originally Z, renamed Z~: 
  is assumed to be: RealRange(-infinity,Open(0))
 

Is it a bug or a normal behavior?

6.68.2 Robert Israel (17.9.98)

| > protect(Z): 
| > assume(Z>0); 
| Error, (in t1) attempting to assign to `Z` which is protected
 

The point is that "assume" produces a new variable Z , and assigns this to Z. Protected variables cannot be assigned new values.

| > unprotect(Z): 
| > assume(Z>0): 
| > protect(Z): 
| > assume(Z<0); 
| Despite the protect() statement, there is no error  ...
 

Like most functions, "protect" has its arguments evaluated before it begins. So if you try to protect a variable that has been assigned a value, "protect" attempts to protect that value. In many cases this can’t be done, and produces an error message:

> a:= 3: protect(a); 
Error, (in protect) wrong number (or type) of parameters in function setattribute
 

The way to protect a variable that has been assigned a value is to delay evaluation with quotes:

> protect('a'); 
> a:= 4; 
Error, attempting to assign to `a` which is protected
 

So when you enter "protect(Z)", what is really protected is the value of Z, which is the new variable Z . The next "assume" doesn’t affect that Z , instead it produces a different Z  and assigns it to Z. So the protection has no effect. On the other hand, "protect(’Z’)" would work.

| Is it a bug or a normal behavior?
 

It’s slightly surprising behavior, but I wouldn’t call it a bug. Compared to all the other complaints about the "assume" facility, which really could use some major rethinking, I’d say this is a very minor point.

6.68.3 Willard, Daniel, Dr. (18.9.98)

It is not inconsistent. The second use of "assume" over-writes the first. If you had used "additionally" instead of "assume" the second time, You should have got an error message.