sqrt(4)=?
I have difficulties understanding why exactly Maple finds the question difficult to answer.
First attempt:
assume(a>0); a:=sqrt(b^2); eval(a, b=2);
(1/2)
/ 2\
a := \b /
(1/2)
4
I suppose the problem is that after the assignment Maple forgets the assumption a>0(?). Is there a way to make _real_ assumptions on variables, which Maple will not forget and possibly warn me if I try to violate?
Second attempt:
c:=sqrt(d^2); assume(c>0); eval(c, d=2);
(1/2)
/ 2\
c := \d /
(1/2)
4
What is the problem here?
P.S. I assume everyone (except Maple) knows that 2x2=4.
- more generally, limits
17 min 40 sec ago - Thanks!
6 hours 49 min ago - The Rollercoaster?
8 hours 39 min ago - sorry; did some research and
10 hours 46 min ago - high dimension differentiability test
11 hours 27 min ago - Help to solve the
11 hours 45 min ago - I will have to update when i
12 hours 13 min ago - worked OK
12 hours 21 min ago - restart:
x:=(u,v)->cos(v);
y:
12 hours 34 min ago - right
12 hours 57 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
simplify
simplify( sqrt(4) );
assume(d>0);
sqrt(d^2);
acer
evalf or simplify
To get the answer you are looking for just run a simplify on the answer you are getting. You can do this either by calling simplify or by right-clicking on the answer and select "Simplify".
Also, the simplify can be avoided if you change the assumption from your first attempt to
assume(b>0);
Scott
Data-structure versus functions
You don't need all the calls to assume to generate the same ''problem''. The issue here is that the powering operator (^) is a data-structure constructor which does not automatically "do" anything. Your various calls return a call to that constructor.
sqrton the other hand is a Maple function, which does do computations - and knows that sqrt(4) = 2. The fact that Maple displays them the same is certainly a huge source of confusion for many users, including advanced users.simplifyjust happens to know that the data-structure constructor (^) corresponds to 'powering', and so can apply various rules of powering. But that is really a sledge-hammer.Sorry, I don't get it . I
Sorry, I don't get it . I read (in the Help) that sqrt(b^2) is not simplified because b could be negative. I thought eval(a, b=2) would provide a hint that b is not negative.
Why doesn't "a:=sqrt(b^2);eval(a, b=2);" produce the same result for a as "b:=2; a:=sqrt(b^2)"?
I thought eval(a, b=2) treats whatever a is defined so far as a function of b and evaluates it. If not, how do I get this effect? Do I have to write a special procedure
a:=proc(b); return sqrt(b^2); end proc; a(2);
?
another shot at it
There's no object "sqrt(b^2)". Instead, the call sqrt(b^2) passes b^2 to a somewhat smart routine. The output is the object (b^2)^(1/2).
So this is the sort of object at hand, this (b^2)^(1/2) thing. It's a structure, or an expression. It's a power thing. It's not a function, or an unevaluated function call. If you evaluate it at a specific b, then doing so won't do anything clever. It won't call sqrt() again.
On the other hand, sqrt() is a function. And it is somewhat clever. So sqrt(2^2) produces 2 right away.
Notice that (b^2)^(1/2) and sqrt(b^2) are not the same thing. The first is a structure, or expression. The second is a function call, which happens to return the first (under no assumptions on b).
The sqrt() function is not the only mechanism that can construct (b^2)^(1/2). It could be constructed directly, typing it in just as it is. (That's a partial rationale for why evaluating the expression at a particular b doesn't call sqrt() again.)
There's nothing clever in (b^2)^(1/2), that can take advantage of b>0 say. The cleverness resided in sqrt(), the function.
Evaluating (b^2)^(1/2) at b=<whatever> will not call sqrt(<whatever>^2) once more. Once sqrt() returns its result, the opportunity for sqrt() to be clever has gone.
In fact, you don't need to create the "special procedure " that you mentioned, because sqrt() is such a thing already.
The issue that you are seeing is also present with your own procedure,
a:=proc(b); return sqrt(b^2); end proc;
To see that, just try,
a(b);
eval(%,b=2);
Just like for sqrt(), once your a() gets called it returns an expression. Evaluating the expression doesn't cause anything clever to re-evaluate or simplify it. That's why a suggestion to hit it with a big hammer like simplify() was made.
Also, there is no automatic simplification of <whatever>^(1/2) for this positive sort of <whatever>. Depending on whom you ask, you may get different opinions about how much merit there is in that.
A slightly smaller hammer is normal(). That is,
4^(1/2);
normal(%);
acer
Thank you
This is exactly right. I don't know if it is a frequently asked question, but it certainly does come up now and then.
Where is the Maple Wiki when you need it? This is exactly the kind of material that belongs there. Right now there is no good repository for 'intermediate' information about Maple.
strong assumptions context
No, Maple does not provide such "strong assumptions context" facility. I wonder whether it would be useful.
On the other hand, an error message occurs the other way, eg:
a:=-1;assume(a>0);
Error, (in assume) contradictory assumptions
Theorist/MathView/LiveMath can do this
The product Theorist/MathView/LiveMath has the facility of being able to provide "context regions". And, of course, all "theorem proving" software have that capability as well.
Completely forgotten
Yes, in fact I have played with Theorist twelve years ago and I had forgotten completely about it. In particular, I was not aware that it is still alive (with such an intricate story though).
Thank you for remind me about it and the link.
On the other hand I do not know much about "theorem proving" software but it sounds to me that its convergence with CAS is something that should occur in the future.
Convergence
That convergence is what the Calculemus interest group is all about. It was initiated in 1999, and is still alive, with the next conference to be held jointly with MKM and AISC.
I am definitely involved in trying to get that convergence to happen, in part through the MathScheme project. While the general framework has been in place for a while, various foundational work remained, much of which is now done: we now have a logic (Chiron) that can deal with deduction and computation, a proper case study of how to specify such a system, as well as some definite implementation ideas (3 links).