You've got one case that isn't done as well as you'd like. Somebody could spend some time doing some dodgy hack to try to take care of this one case (have you started writing this patch? -- I don't believe your assessment of the difficulty involved if you haven't). Then you'd be left to whine about a ton of other cases that you just haven't run into yet.
So what's your brilliant, simple way to just know that 1.4...e17 (and every other numeric literal) fits in this perl's version of IV "better" than in this perl's version of NV? Are you going add comparisons/tests to determine this each time Perl runs into a literal? And then, for each of the new cases you eventually run into, add more comparisons/tests again, basically boiling down to doing every calculation twice and then doing extra work to determine whether the NV or IV result is "better"?
Stop looking at just your one pet case and try to look at the larger problem. Predicting whether a result would be better represented in an IV or an NV isn't a simple problem, whether you'd like to think it is or not... except in the excellent case of making the NVs able to hold any IV, which is a route open to you.
So your argument boils down to not really understanding how to do it, not being interested in doing it yourself, rather blithely assuming that it isn't difficult for someone else to do for you, complaining because they aren't running off to do it, and not offering any response as to why you aren't fixing the problem yourself by just changing one more option in your build. Can you see how that might not be persuasive to everyone? :)
- tye
In reply to Re^3: Exasperated with 64-bit integer builds of perl (magic)
by tye
in thread Exasperated with 64-bit integer builds of perl
by syphilis
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |