ipld:schema Clarify rules-of-engagement with floats in our own schemas

[ribasushi]

A couple month ago there was a pretty lengthy discussion on floats: #236 (comment)

The consensus (as far as I understand) was that while floats are a necessary evil - we should avoid using them ourselves. This proposal contradicts that: https://github.com/ipld/specs/pull/270/files#r439290976

The purpose of this issue is twofold:

• clear up where the IPLD team stands on this
• write this as a very short "recommendation note" for schema writers

[mikeal]

We may have compressed our notes a few times on this but we are still lacking a written resource other than “read these threads.”

We definitely need a clearer and shorter statement on numbers.

[rvagg]

To be clear on that linked #270 reference including Float, this is not something that touches binary encoding or decoding so is not concerned with bit/byte layout. It's purely a Data Model conceptualisation of something that's encoded as an integer. Similar to what we'd do if we faked a stable float ourselves by encoding as two integers [significand,exponent] or even as a string.

The advice I think we still all agree on is to avoid encoding/decoding raw floats on the wire because that just sucks. Thankfully Filecoin is already avoiding that entirely. And really, Bitcoin has avoided it completely as well, even BTC values are encoded as satoshis and multiplied to find the BTC value.

[warpfork]

There's some touch made on this in https://github.com/ipld/specs/blob/babe8137b78192db89367536230f1431e8260ead/concepts/type-theory-glossary.md#what-about-numbers , which simply says

we tend to pretend and build abstractions as if numbers are infinite scalars

and then salts on mounds of warnings about how at some point there's probably a practical consideration which makes that untrue.

But... yes. Agree we should make recommendations content; that's just as important as specification content. Maybe something should be appended to the "authoring guide" section of our docs?