[Xml-compile] $_[0] + 0.0 for sloppy floats
Patrick Powell
papowell at astart.com
Tue Dec 16 15:34:27 GMT 2014
Floats are evil. This discussion brings back horrible memories of
1960's and dealing with multiple hardware architectures and floating
point formats. IEEE 754 cleared a lot of this up but as we can see
there are still *())(*& issues with textual representation.
Ummm... and look at JSON and 'true' and 'false'.
Patrick ("True? You can't handle the 'true'") Powell
On 12/16/14 05:04, Mark Overmeer wrote:
> * hmepas (hmepas at gmail.com) [141216 12:30]:
>> Talking about JSON, I am not seeing any other options actually, than
>> looking into SV. It's the only way to check type of the scalar, beside
>> having scalar stored into object. So the options are:
>> * having objects (slow down and overcomplicate things);
>> * having everything stringified in json;
>> * look into SV.
> When you look at the SV, my choice would be to take the float representation
> over the string representation: a float is more special.
>
>> Bonus option: use language with strict types.
> YAML and JSON are typical examples of "let's make it simpler" (silenty
> to be extended with "to shoot in your own foot") That's one of the
> few justifications of XML: it is as complex as you can think ;-)
>
> I think strict interfaces are the most important base for stable
> programming. Why do people pick a sloppy interface format (JSON), and
> then a strict programming language (Java)? Better use string interaces
> (XML) and sloppy languages (Perl) ;-b
>
>> About making every key in json a string
>> { "MapPoint" : { x : "10.2", y : "45.9" } }
>> this json code will break deserialization for strict typing languages like,
>> java. If x and y is floats in java.
> I don't know. Probably depends on the JSON library used. As parser, I
> would implemented some smartness if untyped information gets read for
> my strongly typed language.
>
>> Do I miss something?
> If you feel that JSON should produce typed info, you may ask the authors
> of those implementations to solve that.
--
Patrick Powell Astart Technologies
papowell at astart.com 1530 Jamacha Rd, Suite X
Network and System San Diego, CA 92019
Consulting 858-874-6543 FAX 858-751-2435
Web: www.astart.com
More information about the Xml-compile
mailing list