Front page | perl.perl5.porters |
Postings from September 2015
On 21 September 2015 at 23:46, Zefram <zefram@fysh.org> wrote: > Are you expecting it to behave equivalently to == for numbers originating > from numeric processes (i.e., getting standard stringification)? > It doesn't: > > $ perl -MData::Float=nextup -lwe 'print nextup(42) == 42 ? "yes" : "no"; print nextup(42) eq 42 ? "yes" : "no"' > no > yes > > Behaviour also differs between == and eq on NaN. > > Having ~~ mean eq when the rhs is a plain defined scalar is certainly > defensible, but don't expect it to be terribly useful on numbers. > Just to be clear, trying to split ~~ into stringy and numeric cases would > be worse. There's no sane version of this that gets us decent implicit > numeric behaviour. Isn't this a moot point because doing "==" on floats is considered a bad idea at best anyway? So there, neither == or eq is appropriate. You generally want "within tolerance X", for which stringification serves as a reasonable proxy, and this thus gives you a *somewhat* sensible default. And there, you can also easily convert that second condition from a "yes" into a "no" with simply 'use bignum', so if people want that level of accuracy, its not hard to make it happen, and happen sensibly using string eq. perl -MData::Float=nextup -Mbignum -lwe 'print nextup(42) == 42 ? "yes" : "no"; print nextup(42) eq 42 ? "yes" : "no"' no no Yes, bignum is probably overkill here, but all I'm doing is using it to make sure nextup(42) stringifies to its full precision. But I'd be generally expecting something like: use SmartMatch::Utils qw( within ); nextup(42) ~~ within( 42, sigfig => 20, ) Or better. ( Obviously better ) -- Kent KENTNL - https://metacpan.org/author/KENTNLThread Previous | Thread Next