assume' not working with find(x,y,z) ...?

[SylvainFlamant]

I was solving a simple geometry problem for my son... I reduced the problem to a set of 3 equations with 3 positive unknown variables ( 3 distances so they need to be positive) .

Using the symbolic engine, Mathcad 14.0 has no problem finding a set of 4 solutions... including the one I was looking for , with positive numbers.

So I wanted to add the constraint that the solution had to be real and positive using the modifier "assume, ALL = RealRange(0,100))" in conjunction with the Given and Find(a,b.c) block.

I know that the syntax "assume, ALL = RealRange(0,100))" works when trying to simplify one single equation with multiple variables as shown in the tutorials, but it seems to be ignored in the context of a Given and Find block...

Maybe somebody can tell me what I am doing wrong in the attached file.

Thanks

sylvain flamant

[PhilipLeitch]

You said you got a solution with all positives, but then wanted to express it in terms of "real" positive numbers.

Do you mean the third column of the first find?

The first find shows that the numbers aren't rational. So I'm assuming you are trying to pull out this irrational numbers (since they are there).

That is - express the lengths in terms of sqrt 2.

I don't know why MathCad isn't returning that solution so I have saved back to version 11 so that someone might be able to shed some light.

Philip
___________________
Nobody can hear you scream in Euclidean space.

[ptc-1368288]

>I don't know why MathCad isn't returning that solution<<br> __________________________

Because there is nothing correct in the work sheet. An octogone is in the domain of the "UnitCircle", therefore has the corresponding roots of unity in complex form because the octogone is a complex plane figure.

jmG

[ptc-1368288]

... here is another look.

jmG

[PhilipLeitch]

Sorry - over my head.

The question - as I understand it - is why can't the worksheet be modified to only return the highlighted result in image in my attachment.

Philip
___________________
Nobody can hear you scream in Euclidean space.

[ptc-1368288]

On 3/4/2009 8:32:08 AM, pleitch wrote:
...
>The question - as I understand
>it - is why can't the
>worksheet be modified to only
>return the highlighted result
>in image in my attachment.
>
>Philip
>__________________

Try same method used in 11, attached

jmG

[alnstevens]

Don't know why "assume" doesn't work as expected (it also doesn't work if the system of equations as written is solved using the solve command). However, by rewriting the equations slightly, you can get the all-positive solution set, without "assuming" anything - see attached.

stv

[PhilipLeitch]

My guess is that the irrational sqare root 2 is throwing the Assume.

Mathcad can create the solution - but the assume isn't returning the solution.

Philip
___________________
Nobody can hear you scream in Euclidean space.

[ptc-1368288]

On 3/5/2009 8:00:43 AM, pleitch wrote:
>My guess is that the
>irrational sqare root 2 is
>throwing the Assume.
>
>Mathcad can create the
>solution - but the assume
>isn't returning the solution.
>
>Philip
_____________________________

ASSUME does not seem to belong to the context.
You may solve for either separate or grouped, and there are 6 ways to skin the cat in groups. 3 are shown in the attached and there are more ways to group. The point is that you are not solving for variable, but for a, b, c as numbers (algebraically represented).

Solutions are circular and undefined if not forced.

jmG

[SylvainFlamant]

Thanks to everybody...

Philip , you are correct, I just wanted to have a solution where all the 3 variables would be real and positive , which corresponded to the 3rd column in the matrix as you have shown in red.

I had also noticed that I could modify slightly my equations to force the solution to positive numbers, but I didn't like that, as I was doing the work Mathcad should be able to do on its own.
I also thought as jmg did, of equating the solution to a matrix, and "select" the 3rd column, but what would be the point of painfully doing what the syntax "assume, ALL = RealRange(0,100))" should be doing, I think ?

I didn't get the point of jmg talking about octogon and unit cercle... Even though my equations had to do with an octogon, I shouldn't have mentioned it , and just say : Here are 3 equations, and I would like to know what is the simple Mathcad way to do it, and ask if somebody had an idea why my syntax didn't give the expected result.

From the numerous responses I got, it doesn't appear that somebody knows why my file "didn't work" and why my "assume" statement is totally ignored, and I didn't see among the responses a good simple way to force Mathcad to only select the solution with positive numbers ( equating the solution to a matrix, and then painfully getting Mathcad to ignore the non-positive solutions would work, but wouldn't be elegant, or what I had in mind )

sylvain flamant

[ptc-1368288]

On 3/9/2009 10:07:10 PM, sflamant wrote:
>Thanks to everybody...
>
>Philip , you are correct, I
>just wanted to have a solution
>where all the 3 variables
>would be real and positive ,
>which corresponded to the 3rd
>column in the matrix as you
>have shown in red.
>
>I had also noticed that I
>could modify slightly my
>equations to force the
>solution to positive numbers,
>but I didn't like that, as I
>was doing the work Mathcad
>should be able to do on its
>own.
>I also thought as jmg did, of
>equating the solution to a
>matrix, and "select" the 3rd
>column, but what would be the
>point of painfully doing what
>the syntax "assume, ALL =
>RealRange(0,100))" should be
>doing, I think ?
>
>I didn't get the point of jmg
>talking about octogon and unit
>cercle... Even though my
>equations had to do with an
>octogon, I shouldn't have
>mentioned it , and just say :
>Here are 3 equations, and I
>would like to know what is the
>simple Mathcad way to do it,
>and ask if somebody had an
>idea why my syntax didn't give
>the expected result.
>
>From the numerous responses I
>got, it doesn't appear that
>somebody knows why my file
>"didn't work" and why my
>"assume" statement is totally
>ignored, and I didn't see
>among the responses a good
>simple way to force Mathcad to
>only select the solution with
>positive numbers ( equating
>the solution to a matrix, and
>then painfully getting Mathcad
>to ignore the non-positive
>solutions would work, but
>wouldn't be elegant, or what I
>had in mind )
>
>sylvain flamant
_______________________________

If you can take it Sylvain,

No CAS system will reply what you think it should because you are like most user ignorant of the symbolic rules, which are called "Advanced Algebra". No matter how much you ASSUME, or else forcing, NIET ! You have to go by the rules, the rules replied by the solution(s). If you have an octagon like you said initially the only answer is my answer and Mathcad answer [presuming your version has the roots of unity]. An octagon is a reduced circle and all CAS will reply for the "roots of unity" as it is fundamental in maths.

>why my "assume" statement is totally ignored <

because the statement means "totally" nothing paper+pencil, therefore nothing algebraically speaking. No CAS go past the maths and mathematicians. Good thing they often go further than the keyboard entries. The other point is that versions 13, 14 are MuPad a very low level symbolic engine vs Maple the top notch.

jmG

[PhilipLeitch]

Jean, although you are answering the original question you seem to be missing the subtext. That's why the thread is becoming somewhat circular (no punn intended).

The question is - given the provided equations, how do we make Mathcad show the values which produce only positive values for A, B and C?

By what means do we configure Mathcad so that we only see that red highlighted portion of values in my previous post?

We thought Assume should do it - but as you point out we are wrong and obviously don't know the rules of this advanced algebra. Fine - so how do we do it?

Philip
___________________
Nobody can hear you scream in Euclidean space.

[TomGutman]

>>Fine - so how do we do it?<<

The usual with a 1.0 release (the symbolic processor in MC14 is brand new) -- we wait a release or two for the major bugs to be ironed out.

The ability to filter the results of a solve is brand new in MC14, also. Prior to that if you used an assume on a name, you could not subsequently refer to that name (such as as a solve variable). Nor were inequalities allowed in a solve block to be evaluated symbolically (that is allowed in MC14 M020). But there are still many bugs, this is just one of them (or perhaps a family of them).

In the meantime, the order in which you specify the variables makes a difference. There is also something odd about "a". Regardless of the order, putting an inequality on it results in a numeric (symbolic processor float) result rather than an exact expression. The same is not true for "b", for which one can successfully filter for positive or negative and still get the exact solutions.
__________________
� � � � Tom Gutman

[ptc-1368288]

Philip,

Your quesion contains the answer.

>Fine - so how do we do it ? <<br>
You do by letting Mathcad do on its own , not knowing what it will be. Then submatrix for what you want. I have mentioned the order and the different answers and it is mentioned here again.

>In the meantime, the order in which you specify the variables makes a difference <<br>
All in all the problem seems to have no meaning and it does not relate to the octagon it was supposed to solve, but that was done and posted. Mathcad does it right, but it does right something that's wrong or not solvable. There are few of this kind of encounter, even functions that have no derivatives. From recollection, you wanted only the positive column, but from which sequence. The problem is circular a stated, there may be a way of expliciting f(a,b):= ,,,,

For what you want if that's what you want: here is.

jmG

[ptc-1368288]

... further: your setup is identically incorrect.
It must be like this.



jmG

[PhilipLeitch]

Thanks all.

Jean - that last solution (with SOL) was interesting.

You use the term "Identically incorrect", what doest that mean? What difference does it make if I do this:
a = b + c

rather than this:
0 = b + c - a

Or even this:
1 = (b + c)/a


To me this is semantics (semantically equivalent � where the statement rearranged to but has same meaning). Is this not the case?

Thank you.
Philip
___________________
Nobody can hear you scream in Euclidean space.

[ptc-1368288]

On 3/10/2009 10:50:01 PM, pleitch wrote:
>Thanks all.
>
>Jean - that last solution
>(with SOL) was interesting.
>
>You use the term "Identically
>incorrect", what does that
>mean? What difference does it
>make if I do this:
>a = b + c
>
>rather than this:
>0 = b + c - a
>
>Or even this:
>1 = (b + c)/a
>
>
>To me this is semantics
>(semantically equivalent �
>where the statement rearranged
>to but has same meaning). Is
>this not the case?
>
>Thank you.
>Philip
>___________________

Sorry Philip, you haven't got any of them correct !

a-(b+c)=0

To make a long story short:

I read it in Maple, and in Mathcad. At the time I understood it and admitted, and by coincidence there were solving problem in the forum , but that is several moons ago. Also true in Mathematica. In some way it is also true with Minerr and Lambert. It seems easier checking for the change in sign on the RHS than checking between the last and before last calculated, as may be it is if there is a way to check if a function does exist. It's a great modern trick to relate solution(s) to other functions, simpler or more easily expressible.

Algebraic expressions don't come out always by rules (brackets & sign), you may have to force the meaning and by doing the right way you are sure the solver won't get confused and eventually get a wrong answer or a red error message.

You can imagine that solving means solving over a scalar and checking with a library of scalar functions is then a straight forward task. Assume you solve symbolic for an integral, no big business to internally tabulate and check if any other functions does match. Then comparing a scalar function to another one with the identity F(x)-Unk(x)=0


Jean

[ptc-1368288]

How come I didn't attach the work sheet ?

I have seen many MuPad symbolic results, they may be right to some as they looked right to the MuPad designers, but they are in essence incorrect as incorrect as expressing a polynomial a0 +a1*x + a2*x ... A symbolic result is in essence in term of the variables as if the variables would be true and at the user disposal. In that respect when Maple refuses more simplifications, then zap ... Maple gives a more complete mathematical meaning.

jmG

[PhilipOakley]

On 3/10/2009 10:50:01 PM, pleitch wrote:
..
> What difference does it
>make if I do this:
>a = b + c
>
>rather than this:
>0 = b + c - a
>
>Or even this:
>1 = (b + c)/a
>
>
>To me this is semantics
>(semantically equivalent �
>where the statement rearranged
>to but has same meaning). Is
>this not the case?
>
>Thank you.
>Philip
>___________________
>Nobody can hear you scream in
>Euclidean space.

Having been there, I have seen mathematicians make the distinctions between such different representations. Usually it was to emphasise a point, or allow them to multiply through by a special term (using 0*term=>0), or carefully rescale values [e.g. re-labelling points as +1 & -1 for determininig optimal separation], etc.

Many tricks depend on the representaion, so getting the formulas in the right form allows the computer to execute the trick.

Philip Oakley

[ptc-1368288]

Here are two examples of "formula reduction":

1. The denom in the Laplace domain makes the InverseLaplace solver work immediately from tables in the CAS symbolic.

2. The reduced rational fraction economizes 1 AOP's [Arithmetic Operations]. It has a cleaning effect vis numerical stability. It enables the Genfit to be initialized simple by nulling terms a2*x, a3*x... & a4*x, a5*x or similar configurations. What that means: the genfit is initialized by a straight line adjusted to cross the data set.



Good books are full of such formula reduction.

jmG

[PhilipLeitch]

Laplace is one of the things I want to learn about - because I had never heard of it (or him) before playing around with Mathcad.

Where is a good place to learn about Laplace transformations and Laplace domain? I.e. what books would you reccomend?

Philip
___________________
Nobody can hear you scream in Euclidean space.

[Al2000]

On 3/10/2009 10:50:01 PM, pleitch wrote:
>Thanks all.
>
>Jean - that last solution
>(with SOL) was interesting.
>
>You use the term "Identically
>incorrect", what doest that
>mean? What difference does it
>make if I do this:
>a = b + c
>
>rather than this:
>0 = b + c - a
>
>Or even this:
>1 = (b + c)/a
>
...

Warning, that last expression is not equivalent to the first two. In that last expression you had forced that a<>0.

Al

[ptc-1368288]

On 3/11/2009 11:00:21 AM, Al2000 wrote:
>On 3/10/2009 10:50:01 PM, pleitch wrote:
>>Thanks all.
>>
>>Jean - that last solution
>>(with SOL) was interesting.
>>
>>You use the term "Identically
>>incorrect", what does that
>>mean? What difference does it
>>make if I do this:
>>a = b + c
>>
>>rather than this:
>>0 = b + c - a
>>
>>Or even this:
>>1 = (b + c)/a
>>
>...
>
>Warning, that last expression is not
>equivalent to the first two. In that
>last expression you had forced that
>a<>0.
>
>Al
__________________

[PhilipLeitch]

No - what Al2000 was getting at was that in that I was excluding the posibility that b and c combine to zero:

a = 0
b = 5
c = -5

a = b + c (true)
0 = b + c - a (true)

BUT
1 = (b + c)/a (false - division by zero)

Division by zero is erronious even if the numerator is also zero (that's correct isn't it?).

Therefore of the three statements the final one isn't equivalent as it asserts a non-zero value of a.

Philip
___________________
Nobody can hear you scream in Euclidean space.

[ptc-1368288]

> Division by zero is erroneous even if the numerator is also zero (that's correct isn't it?).<<br> ________________________

0/0 = 0 a convention as well as a true value.

Dividing by zero is what we look for in maths
so you know how to manipulate 1/x +++ like.

jmG

[RichardJ]

On 3/11/2009 6:55:39 PM, jmG wrote:
>> Division by zero is erroneous even if the numerator is also zero (that's correct isn't it?).<<br> >________________________
>
>0/0 = 0 a convention as well
>as a true value.

Division by zero can never result in a valid answer. But we ave had this discussion before.

Richard

[ptc-1368288]

On 3/12/2009 1:36:56 AM, rijackson wrote:
>On 3/11/2009 6:55:39 PM, jmG wrote:
>>> Division by zero is erroneous even if the numerator is also zero (that's correct isn't it?).< [Philip asked the question]
>>________________________
>>
>>0/0 = 0 a convention as well as a true value <<.
>
>Division by zero can never result in a
>valid answer. But we ave had this
>discussion before.
>
>Richard
_______________________

OK Richard,

You may not like my agreement with Mathcad and the Pentium conventions, let those more mathematicians word the 0/0, demonstrate and what it means . You like the indeterminate, me too. What's important is how it behaves in work sheets.

0/0 = 0 makes Mathcad work because Pentium is so designed understanding that Mathcad is not an AU [Arithmetic Unit] and performs no such a thing as 0/0 by itself.



0/0 is not erroneous, only indeterminate

jmG

[RichardJ]

On 3/12/2009 2:56:29 AM, jmG wrote:

>0/0 is not erroneous, only indeterminate

"indeterminate" means "cannot be determined". In other words, the result of 0/0 could be anything, and there is no way for you, me, Mathcad, or any other piece of software to know what it is. Therefore evaluating to an answer (any answer) is indeed erroneous.

Richard

[PhilipLeitch]

Hmmm.... I disagree.

I take nothing, and don't divide it. How many units do I have? None.

Seriously though...

When a numerator becomes very small compared to the denomenator, the number approaches zero.

When the denomenator becomes very small compared to the numerator, the number approches infinity.

If it is concluded that zero is infinately small then zero has a value and thus 0/0 = 1.

If it is concluded that any number divided by zero becomes infinately large, we could arague that anything divided by zero becomes an infinate value: 0/0 = infinite (or maybe infinately smaller than every other number but still not zero???).

If it is concluded that any value with a numerator of zero is zero regardless of the denomenator, then: 0/0 = 0

As far as I'm concerned I'll just avoid every dividing zero by zero because I can't see that I will need the answer.

Philip
___________________
Nobody can hear you scream in Euclidean space.

[AlvaroDíaz]

On 3/12/2009 6:26:05 AM, pleitch wrote:
>When the denomenator becomes
>very small compared to the ...

So, you are considering a various kinds of zeros. There are three basic:

- The natural zero, constructed (from the hard 'nothing').
- The becomes zero, under construction, but never (or not just at this time, as subtype) constructed.
- The zero finally constructed, but by an approximation (and not related with the concept of the nothing directly, only as an 'accident').

In the operations n/0 and 0/0 you must say which zero are under consideration. For example, the last zero is problematic because destroy information, like a black hole, and don't agree with what Hawking say about the event horizont. And some peoples refuses their consideration.

The 'indetermination' of n/0 for n not zero is the entire complex plane, with a hole in the origin (every 'number' is solution for the eqn z=n/0). And 'complex' is the default meaning of 'number'. But a 'plane' isn't an 'indeterminate' concept in geometry. The problem is the representation of a 2 dimensional entity with only one variable without the knowdolage of the position in the plane of the points (but isn't like Peano curves. Is more related with the concept of radiation of lines - 'Haz de rectas' in spanish). And again, the concept of information is pressent. Remember that the bit is now considered as a trully physical unit (and then the information is a palpable dimension).

The assignation of 0/0 is then a question about which pair of zeros are under consideration. For example, if num = 0 constructed and den = 0 under construction, then whe are forced to assign 0/0 = 0.

As their reciprocal (or dual, in projective geometry language) the infinite is the same thing.

Alvaro.