From 443a2cbe7f2d515e8d2d6f99ea5229852571ec62 Mon Sep 17 00:00:00 2001 From: alisdair sullivan Date: Tue, 24 Jan 2012 23:44:46 -0800 Subject: [PATCH] doc updates --- README.markdown | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.markdown b/README.markdown index a87eecf..f552665 100644 --- a/README.markdown +++ b/README.markdown @@ -148,7 +148,7 @@ json must be encoded in `utf8`. if it's invalid `utf8`, it probably won't parse **numbers** -javascript and thus json represent all numeric values with floats. as this is woefully insufficient for many uses, **jsx**, just like erlang, supports bigints. whenever possible, this library will interpret json numbers that look like integers as integers. other numbers will be converted to erlang's floating point type, which is nearly but not quite iee754. numbers not representable with either type are beyond the concern of this implementation, and will result in parsing errors (with the exception of negative zero, which is converted into plain old zero) +javascript and thus json represent all numeric values with floats. as this is woefully insufficient for many uses, **jsx**, just like erlang, supports bigints. whenever possible, this library will interpret json numbers that look like integers as integers. other numbers will be converted to erlang's floating point type, which is nearly but not quite iee754. negative zero is not representable in erlang (zero is unsigned in erlang and `0` is equivalent to `-0`) and will be interpreted as regular zero. numbers not representable are beyond the concern of this implementation, and will result in parsing errors when converting from erlang to json, numbers are represented with their shortest representation that will round trip without loss of precision. this means that some floats may be superficially dissimilar (although functionally equivalent). for example, `1.0000000000000001` will be represented by `1.0` @@ -158,11 +158,11 @@ the [json spec][rfc4627] is frustratingly vague on the exact details of json str all erlang strings are represented by *valid* `utf8` encoded binaries -this implementation performs no normalization on strings beyond that detailed here. be careful when comparing strings +this implementation performs no normalization on strings beyond that detailed here. be careful when comparing strings as equivalent strings may have different `utf8` encodings **true, false and null** -the json primitives `true`, `false` and `null` are represented by the erlang atoms `true`, `false` and `null`. suprise +the json primitives `true`, `false` and `null` are represented by the erlang atoms `true`, `false` and `null`. surprise **arrays**