[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: Serialization of math.huge
- From: Dan Tull <dtull@...>
- Date: Tue, 29 May 2012 10:36:40 -0700
> 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/).