О, спасибо за цынк. Думаю, напишу свой int(), как водится — с преферансом и гимназистками.
13.12.2012, 12:26, "Vladimir Timofeev" <[email protected]>: > 2012/12/13 Oleg Alistratov <[email protected]>: > >> Мда. Это у меня мелкие претензии. Дело не в inf и nan. >> Вообще любой литерал, который не влазит в IV, создает NV. > > Там даже коммент на эту тему в коде pp.c (5.16.1): > /* XXX it's arguable that compiler casting to IV might be subtly > different from modf (for numbers inside (IV_MIN,UV_MAX)) in which > else preferring IV has introduced a subtle behaviour change bug. OTOH > relying on floating point to be accurate is a bug. */ > > и дальше, если не SvIOK: > const NV value = SvNV_nomg(sv); > if (value >= 0.0) { > if (value < (NV)UV_MAX + 0.5) { > SETu(U_V(value)); > } else { > SETn(Perl_floor(value)); > } > } > else { > if (value > (NV)IV_MIN - 0.5) { > SETi(I_V(value)); > } else { > SETn(Perl_ceil(value)); > } > } > >> Так что в perldoc -f int написана не вся правда :) >> >> 13.12.2012, 11:46, "Oleg Alistratov" <[email protected]>: >>> Внезапно: >>> >>> % perl -e 'print int("Inf"), "\n";' >>> inf >>> >>> Чудес там, конечно, нет, возвращается NV: >>> >>> % perl -mDevel::Peek -e '$a = int("Inf"); print Devel::Peek::Dump($a), >>> "\n";' >>> SV = NV(0x7f9cf1830e00) at 0x7f9cf18290e8 >>> REFCNT = 1 >>> FLAGS = (NOK,pNOK) >>> NV = inf >>> >>> но получается, что функции int() нельзя доверять в плане возвращения целых >>> чисел. >>> Кто-нибудь знает, откуда растет это явление? >>> >>> -- >>> Oleg Alistratov >> -- >> Oleg Alistratov >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org > > -- > Vladimir Timofeev <[email protected]> > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Oleg Alistratov -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
