search

ipld / specs

Content-addressed, authenticated, immutable data structures
Other
592 stars 108 forks source link

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

Open ribasushi opened 4 years ago

ribasushi commented 4 years ago

A couple month ago there was a pretty lengthy discussion on floats: https://github.com/ipld/specs/pull/236#issuecomment-579015374

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:

mikeal commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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?