Numeric support in Noms

[aboodman]

I'd like to fix numbers in Noms. For now, this bug will just collect ideas and desired features. These might be in conflict or not make sense - rationalizing desired features will come later.

• Precisely store any integer
• Precisely store any rational number
• Store values compactly (e.g., as a product of an exponent) to save space
• Store values as common encodings (e.g., little-endian int32) to make encoding and decoding cheap
• Use the type system to communicate useful information about sets of numbers to users:
  • Whether the set contains signed numbers
  • Whether the set contains fractional numbers
  • If the set contains fractional numbers, what is their lcd
  • If all the numbers in the set can be represented precisely by common programming types like {(u)int(8|16|32|64), float{32|64}, decimal}
• The above information communicated by the type system should work properly with type accretion... it should be kept up to date as items are added to collections, without having to inspect the collections' contents manually

[coriolinus]

The requirement to precisely store any integer or any rational implies bignum / bigrat support. While cool, a subset feature capturing most of the value would be the ability to precisely store integer primitives: u?int(32|64)?.

The type system and type accretion system is cool, but from the perspective of my use case, it's not a key noms feature. It's much simpler to build a model struct, and serialize / deserialize the struct into noms, without performing any type introspection whatsoever.

[aboodman]

OK, thanks. Totally understood, but I would like to do something more general if possible as long as a change is being made.

[aboodman]

Also, I think (hope?) it's likely that as your system grows you'll come to appreciate the ability to introspect the data. I would imagine this comes in handy for changing schemas across versions, for example.