The problem with that is in “treated as” – remember that native complex numbers are an area of memory very closely resembling two floating-point numbers of whatever precision. There is no way to persuade the computer to “treat” an area of memory which is only one floating-point number as that. All that one could do is convert it over. Doing that implicitly, or at least in a way that’s not clearly spelled out, would lead to chaos.
This all comes down to humans’ understanding of things, and quirks of the PDL implementation. The asin(2) changing behaviour was a bug, and a fixable one. Conversions should, for the most part, be explicit. I’m planning to make r2C and i2C functions/methods within Ops that will convert (not just “treat as”, sorry 😉) data to native complex numbers, with type conversion as necessary, using the forthcoming “complex” type qualifier. I’ll be making the tests reflect this conversation’s revealed expectations. By the way, one serious pain-point has been keeping things working with BADVAL_USENAN, because it’s off by default. Is there any reason not to switch to BADVAL_USENAN being on, BADVAL_PER_PDL the same, and in fact making these things permanent by removing the configurability? Lots of maintenance stuff would get a lot simpler, but that’s only viable if it won’t harm users. Thoughts?
_______________________________________________ pdl-devel mailing list pdl-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdl-devel
