Yet another "unique" function and the NaN (Not a "Not a Nusiance")
I was playing around with sorting and decided (yet again) that I was frustrated by some of the restrictions. One thing led to another, and before I knew it, I was hip deep in ways to "improve" the lookup functions.
While contemplating Mathcad Zen Principles 3, 6, 7, 16, and 17, I wondered whether "unique" would be a worthwhile addition to the match/lookup modifiers.
Then my mind went blank when faced with how to handle NaNs. In principle, IEEE 754 NaNs are distinct. And they would be if a standard Mathcad user had any way to distinguish between them, but they're harder to tell apart than Zathras and Zathras. To the Mathcadder in the street, they might as well be indistinguishable, for all the good their distinctiveness does.
So, I've written two versions of unique to cater for both cases. The question is which one would a user expect to be the default (and hence all lowercase) version?
I've checked in a few other languages. Matlab seems to be an outlier in treating NaNs as distinct. Python (numpy), Julia, and (surprisingly) Mathematica appear to treat NaNs as indistinguishable from each other (for uniqueness testing); even XCas does so: set( [1,2,4,5,NaN, 6,2,NaN,5,1,4,2,5]) == 1,2,4,5,NaN,6
.
In the meantime, could a kind soul please check whether the attached Mathcad Express 10.0 worksheet works in Mathcad Prime?
I'd expect the results to look something like this:
Thank you,
Stuart
https://www.validlab.com/goldberg/paper.pdf
https://community.ptc.com/t5/Mathcad/MEP-00-The-Zen-of-Mathcad/m-p/1040983#M219315
3. Be like Zathras-- cover all possibilities. Zathras does not want other people being confoosed.
6. Explicit is better than implicit.
7. Unless implicit is better.
16. Functions should work over any data type.
17. Except where there is no meaning.