+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: HP Prime (/forum-5.html)
+--- Thread: ==/EQ() and approx() (/thread-7030.html)
==/EQ() and approx() - TravisE - 10-13-2016 07:48 AM
I expect to write some code where I intend to test the literal contents of a variable or value to see whether it is a list and, if it is, whether it contains a specific sequence of values. Since == does an element-by-element comparison, and I want to do a full comparison, EQ() would appear to be the proper function to use.
But I find that == and EQ() are annoyingly picky and error out if the types of the objects do not match. (For my purposes, I'd much rather it simply return 0 instead, since logically, they are not equivalent.)
While fooling around, though, I discovered that wrapping an == test comparing a list and any other object inside approx() seems to do what I want. It appears to does a literal list comparison like EQ(), returning 1 only if the two lists are exactly the same, 0 if they aren't, and 0 instead of an error if the object types are not the same.
But this seems kind of strange and counterintuitive to me—what do equivalence and approx() have in common? Is this actually doing what I think it is? Can I rely on this behavior? I wasn't immediately able to find any reference to this in the on-calc help.
RE: ==/EQ() and approx() - Tim Wessman - 10-13-2016 05:56 PM
approx is going to be using the CAS for evaluation, and since the CAS will do some simplification this may work.
EQ is for testing exact equality of a list - which is something that was impossible to do without a custom made user function due to automatic list processing and hence it was added. Automatic list processing means you can do something like SIN{1,2,3} and it is handled properly as expected.
However, 2 and '1+1' are not identical objects even though on evaluation they would be. Nor would A and 0, even if A contained 0 because one is a variable and the other a number.
Could you show an example of what you are trying to compare?
For example, if it was {1,2,3} and {1,'1+1',3}, doing an EQ(EVAL({1,2,3}),EVAL({1,'1+1',3})) would do what you want. That might be your solution as well for your case.
RE: ==/EQ() and approx() - Tim Wessman - 10-13-2016 06:03 PM
Note that I'll bring up the "Error" part you mention. Currently, it errors on anything except two lists. I assume you are talking about this. Might make more sense to return a 0 like you suggest. Or did I misunderstand what you mean?
RE: ==/EQ() and approx() - TravisE - 10-14-2016 04:43 AM
Hi, Tim,
Yes, I was referring specifically to the Bad Argument Type error on types other than two lists. Sorry; it looks like I should have provided some examples.
Essentially, I was looking for some sort of analog to ==/SAME on the HP 48/49/50 family, or even ==/is in Python, which treat the objects being compared as atomic units but also work on objects of dissimilar types (where the exact mechanics vary slightly between == vs. SAME/is, but this isn't my primary concern at the moment). So, if a variable named ‘foo’ contains a string "1", then such a comparison operator (I'll just call it == for the same of example) would give:
Code:
foo=="1" → 1 (same type, same contents)
foo=="11" → 0 (same type, not same size or contents)
foo==1 → 0 (not same type)
foo=={1} → 0 (not same type)
foo=={} → 0 (not same type)or if ‘foo’ contains {}:
Code:
foo=={} → 1
foo=={0} → 0
foo=={"A"} → 0
foo==0 → 0
foo=="{}" → 0EQ() was pretty much what I wanted except for the outright error if the types aren't the same—I was expecting it to simply return 0 in that case. This unfortunately complicates a task like simply checking if a variable contains, for instance, an empty list (vs. anything else, list or not); or if it contains a string of a specific value (vs. anything else, string, list or not), and so on. Instead of writing a simple one-line expression, it seems necessary to also wrap it inside an IFERR, or write additional code to check the types first, then the sizes if it's a list, etc. That's kind of a pain.