Real / floating-point numbers about lofi-schema-elm HOT 5 OPEN

Given a choice between #whole and #integer, I lean toward #integer since there are at least three somewhat common but inconsistent definitions of "whole numbers".

Everything but unbounded integers can be specified by min/max:

#number / Real
#number #min: 0   / Positive Integer
#number #min:0.0 / Positive Real

The problem is that we have two axes: integral-ness and range. The range notation can hint the integralness, but only if the value is bounded. There's just no way to get an unbounded integer without a way to address that one axis. This implies:

#integer / Integer
#integer #min: 0 / Positive Integer
#real / Real
#real #min: 0 / Positive Real
...

So there's no longer a concept of a "number"; there are only integers and reals. This may not be a bad thing, since it forces whomever is specifying the structure to decide whether fractional parts are valid.

But this: "having to type #number #whole #positive would be annoying to get the common case of an unsigned integer" makes me wonder whether that case should simply get its own dedicated tag, like #index or #count, since both of those concepts are traditionally positive integers.

from lofi-schema-elm.

A few ideas floating around:

#number / Real (usually Double Float)

#number #quantity / Unsigned Int
#quantity / Unsigned Int

#number #precision / Real (usually Double Float)
#precision / Real (usually Double Float)
#precision: float32 / Float (probably won’t add this)
#precision: float64 / Double Float (probably won’t add this)
#precision: 0 / Integer
#precision: 0 #min: 0 / Unsigned Integer
#precision: 0 #positive / Unsigned Integer (might just stick to #min: 0)

I want to avoid inferring based on content where possible, so not detection of real numbers based on #min: 0 vs #min: 0.0. It’s sometimes too tricky for a reader in my experience, It’s quite subtle.

from lofi-schema-elm.

Note, not sure whether #number #whole or #number #integer is better.

Also, not sure if having to type #number #whole #positive would be annoying to get the common case of an unsigned integer.

from lofi-schema-elm.

quantity is a very good name for that concept.

Fully agree that there shouldn't be an explicit choice between float32 and float64 since that difference is implementation specific and makes low-level assumptions about the underlying language/OS/hardware.

Good point about inferring based on content.

Design question: are you working from a principle of "there should be exactly one right way to specify X" or "I want this to feel as close to natural language as possible, so there may be multiple overlapping ways to specify X"?

from lofi-schema-elm.

Oh great!

Design question: are you working from a principle of "there should be exactly one right way to specify X" or "I want this to feel as close to natural language as possible, so there may be multiple overlapping ways to specify X"?

Yes, a bit of both! It is a tension between the two. I think it should be close to natural language that designers and managers would understand. And I think ideally there would be only one way of specifying something it’s light weight to learn. Especially to keep a lean foundation instead of deprecating half of it in a year.

In the case of an integer, something like #precision: 0 would do the trick perfectly, however #quantity would be more natural, so I’d probably say to include that.

Also whether to require #number all the time or to instead allow #quantity and #precision by themselves, I‘m not sure about that yet!

from lofi-schema-elm.