in reply to Detecting whether UV fits into an NV
|Replies are listed 'Best First'.|
Re^2: Detecting whether UV fits into an NV
by syphilis (Bishop) on Feb 26, 2020 at 10:58 UTC
I think that checking whether the UV arg == (UV)((NV)arg) is a splendid idea.
Interestingly, it's only very slightly faster (at least for the value ranges I've tested) than the XSub I posted at the beginning of this thread, but it's far, far simpler.
As an aside, whilst this approach is quite simple to implement inside XS space, is it even possible to do inside perl space ?
That is, inside a perl sub, how would one coerce a UV to an NV and then back to a UV ?
(This aspect is not an issue for me - which is the reason that I've presented it "as an aside". Just curious as to if/how it's possible, that's all.)
Unfortunately this check fails for some UV values with less recent Microsoft Compilers - eg Visual Studio 2010 and earlier.
No problems with Visual Studio 2017 and Visual Studio 2019.
I suspect that Visual Studio 2015 is the oldest Microsoft Compiler that doesn't suffer from this problem, but I haven't confirmed that.
This particular issue looks like another manifestation of the problem that sent me down this path in the first place.
Here's the demo I ran:
I doubt it's faster than some of hte others
To support negative numbers, use I instead of J for negative numbers.
The following is a little bit truer to a cast, but it's far more complicated, far more fragile (can fail for overloaded and magical vars), and technically uses XS:
Both of your approaches still fail to deal correctly with certain values when older Microsoft compilers are used.
All is good for the value of 18014398509481985, irrespective of compiler. The value of $x changes from 18014398509481985 to 18014398509481984, indicating correctly that 18014398509481985 is not representable as a double.
However, IIUC, the value of $x should not alter if $x is initialized to (eg) 18446744073709549568 or 18446744073709139968 as both values are representable as a double.
But those values do change with those older Microsoft compilers - again, I believe, indicative of that same problem (that I keep hitting) that afflicted Microsoft compilers until some point after Visual Studio 2010 and no later than Visual Studio 2017.
At this point, the only thing that's working on these troublesome Microsoft compilers are the subs I provided in my initial post.
I should point out that I haven't yet got to assessing jcb's contribution. I'll try to get to it over the weekend, or whenever I can find the time.