From ffc08a5732bb4380932730dcd346da1a9817d8d1 Mon Sep 17 00:00:00 2001 From: Aaron Boodman Date: Sat, 2 Jun 2018 17:38:32 -0700 Subject: [PATCH] Update numbers.md --- doc/proposals/numbers.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/doc/proposals/numbers.md b/doc/proposals/numbers.md index 0d61229abb..bcb3d3ea6b 100644 --- a/doc/proposals/numbers.md +++ b/doc/proposals/numbers.md @@ -8,12 +8,14 @@ The last time we looked at this, we concluded we didn't have a clear enough idea It's now clear to me that desiderata include: -Use cases: +## Use cases + * It should be possible to store arbitrarily large integers in Noms * It should be possible to store arbitrarily precise non-integral numbers in Noms * It should be possible to store rational, non-integral numbers precisely in Noms -Integration: +## Integration + * The Noms type system should report useful information about numbers: * Whether the number can be represented precisely in binary * The number of bits required to represent a number precisely @@ -23,12 +25,15 @@ Integration: * It should be possible to use native Go numeric types like `int64`, `float`, and `big.Rat` to work with Noms numbers in the cases they fit * It should be possible to conveniently work with _all_ Noms values via some consistent interface if so desired -Efficiency: +## Efficiency + * It should be as close as possible to zero work to decode and encode all the common numeric types * Large, imprecise numbers (e.g., 2^1000) should be stored compactly so that users don't have to manually mess with scale to try and save space -Non-goals: +## Non-goals + * I do not think a database system like Noms should support fixed-size (e.g., floating point) fractional values. +* I do not care if it is possible to represent every possible IEEE float (e.g., NaN, Infinity, etc) # Proposal for type system integration