Sorry this is an electronic translations
Hello how to evaluate (True / False) an expression of the form (# = #) to be useful within the algorithm?
Hola, como evaluar (V/F) una expresion de la forma (# = #) para que sea útil dentro de un algoritmo?
x² = 9| (x = 3.1) = > ( 9.61 = 9 )
eval( 9.61 = 9 ) => false
Thanks
Jaimeza
(10-28-2014 02:13 AM)compsystems Wrote: [ -> ]Sorry this is an electronic translations
Hello how to evaluate (True / False) an expression of the form (# = #) to be useful within the algorithm?
Hola, como evaluar (V/F) una expresion de la forma (# = #) para que sea útil dentro de un algoritmo?
x² = 9| (x = 3.1) = > ( 9.61 = 9 )
eval( 9.61 = 9 ) => false
Thanks
Jaimeza
Use == if you want a test :
x² == 9| (x = 3.1)
x² == 9 | (x = 3.1) works fine, but the idea is that the input is an equation, entry is very ugly expression ( expr == expr )
eg I ask a user to enter an equation and the algorithm evaluates to a value. ( an equation has NOT double equal)
REQUEST HP-PRIME TEAM => I think the solution is that the EVAL command will return 1/0 in the case of # = #
eval(#=#) => 1/0
Thanks
I also encountered this in working with a problem just the other day, where it was explained that "==" is a test for "representational" equivalence, but not mathematical equivalence. As long as the operands are numerical, or symbolically the same, the test is usable.
For me, there IS room for confusion on "==." The user guide definition: "Equality test. Returns 1 if the left side and right side are equal, and 0 otherwise."
Two expressions will fail the test if the expressions are equivalent, BUT represented differently:
(√(-2.*cos(t)+2.))== (2*ABS(sin((1/2)*t))) => 0
to pass the '==' test, make an assumption on the variable (t), in effect converting them to a number:
(((√((-2.)*cos(t)+2.))==(2*ABS(sin((1/2)*t))))|(t )= (π/4)) => 1
I think the "==" test would be more beneficial if it operated as the user guide described, for both cases. Especially, in a programmatic context. I don't know if this is worthy of a bug report, though.
Maybe others will have additional thinking to share.
-Dale-
(10-31-2014 01:49 PM)DrD Wrote: [ -> ]I also encountered this in working with a problem just the other day, where it was explained that "==" is a test for "representational" equivalence, but not mathematical equivalence. As long as the operands are numerical, or symbolically the same, the test is usable.
Maybe others will have additional thinking to share.
-Dale-
ICYMI: A particular bug in == was discussed in a previous thread.
Programming question and strange == result
Thanks for the reference, that is indeed the kind of problem I encountered.
-Dale-