Страусов не пугать - пол бетонный

[netch80]

4> <<P:32/big-float>> = <<63,128,0,0>>.
<<63,128,0,0>>
5> P.
1.0
6> <<P:32/big-float>> = <<127,128,0,0>>.
** exception error: no match of right hand side value <<127,128,0,0>>
7> <<P:32/big-float>> = <<127,128,0,1>>.
** exception error: no match of right hand side value <<127,128,0,1>>

в команде 6 я пытался расшифровать +INF, 7 - +NAN(1)

А вот что пишет ползучий питоний:

>>> struct.unpack('>f', '\x7f\x8f\x00\x00')[0]
nan
>>> struct.unpack('>f', '\xff\x8f\x00\xff')[0]
nan

"это не число, и к дьяволу подробности!"
Зато хоть создавать не запрещает:

>>> a = float('nan')
>>> a
nan
>>> -a
nan

и на том спасибо.

Comments

[gegmopo4.livejournal.com]

Это зависит от реализации. Даже в CPython float('nan') и float('inf') работают только если нижележащая библиотека C поддерживает.

[netch]

> только если нижележащая библиотека C поддерживает.

А какая именно поддержка нужна для этого?

[gegmopo4.livejournal.com]

Ну, наверное существование таких нечисел, как NAN и INFINITY, функции вроде isnan()/nan(), а может и бинарной совместимости с соответствующим IEEE. Сам питон не гарантирует их существования. На какой-то экзотической платформе может не быть.

И в 2.4 pack/unpack с ними не работал.

[netch]

Мне что-то кажется, что результат зависит от того, что покажет sscanf("nan", "%lg", &d)
;)

[gegmopo4.livejournal.com]

Надо же, не знал, что scanf понимает nan. Но я с нечислами вообще дела не имел.

Тогда уж strtod, именно он используется для str->float.

[gegmopo4.livejournal.com]

А в struct и pickle вообще используется ручная платформо-независимая упаковка в 4/8 байт. И получатся ли нечисла на не-IEEE платформе зависит от везения.