Skip to content
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.

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

Open
ribasushi opened this issue Jun 12, 2020 · 3 comments
Open

Comments

@ribasushi
Copy link
Contributor

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
Copy link
Contributor

mikeal commented Jun 12, 2020

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
Copy link
Member

rvagg commented Jun 15, 2020

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
Copy link
Contributor

warpfork commented Jul 1, 2020

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants