RE: Serialization of math.huge

[Dan Tull <dtull@...>]

> I've been working on a simple serialization module... and 
> came across an issue with math.huge...

> Does this indeed need to be handled as a special case, or am I missing
> some simple solution?

I ran into this same problem with the serialization mechanism used
by Lightroom's code. It emits infinity (math.huge) and undefined ( 0 / 0 )
as expressions that will re-create those values.

That is, if the value being serialized is equal to math.huge, instead 
write out the expression 1 / 0 and if the value being serialized is not
equal to itself (the only way I found to identify the undefined value),
serialize it as the expression 0 / 0 and otherwise use tostring.

This fixed a bug similar to what you describe. If I recall correctly, the 
failure was due to sprintf on Windows behaving differently.

Dan Tull
Adobe

________________________________________
From: lua-l-bounces@lists.lua.org [lua-l-bounces@lists.lua.org] On Behalf Of Paul K [paulclinger@yahoo.com]
Sent: Tuesday, May 29, 2012 12:03 PM
To: Lua mailing list
Subject: Serialization of math.huge

Hi All,

I've been working on a simple serialization module (yes, I carefully
reviewed the implementations listed here
http://lua-users.org/wiki/TableSerialization) and came across an issue
with math.huge. tostring(math.huge) returns "1.#INF", but this value
isn't interpreted as a valid number (when I'm loading the generated
string with loadstring). It seems like these values (+/-math.huge)
need to be treated as special cases, but I don't see this logic in any
of the modules I reviewed (including those that aim to provide a
complete serialization solution).

A simple test using serialize.lua from metalua:

require "serialize"
local s = serialize {[math.huge] = -math.huge}
local _, err = loadstring(s)
print(s, err)

This outputs:

return { [1.#INF] = -1.#INF }   [string "return { [1.#INF] = -1.#INF
}"]:1: ']' expected near '#'

Does this indeed need to be handled as a special case, or am I missing
some simple solution?

Paul (http://notebook.kulchenko.com/).