search

ProtoDef-io / ProtoDef

ProtoDef specification: describe your protocol, and read it with ease.
36 stars 8 forks source link

Add half-precision floating-point type #32

Closed Saiv46 closed 4 years ago

Saiv46 commented 4 years ago

See https://en.wikipedia.org/wiki/Half-precision_floating-point_format

rom1504 commented 4 years ago

We could but why ? Any protocol using that ?

Saiv46 commented 4 years ago

It used by python struct module, I can convert it to ProtoDef

rom1504 commented 4 years ago

Yes I'm not saying it's hard to implement, it's definitely not hard. My question is why would we support it ? Is there any protocol you have in mind that uses this ?

roblabla commented 4 years ago

As a general rule, the vision I have for protodef is to have a very lean/minimal core that is mostly focused on generic containers and universal datatypes to enable 90% of the use-cases (in that sense, varint support in protodef was a mistake). More niche datatypes can exist as pluggable extensions, like how NMP adds UUID. This reduces maintenance of the core library and more easily allows experimentation (e.g. with compilers and such) since they don't initially have to worry about every weird datatype.

f16 feels extremely niche - I've never seen it used outside deep learning frameworks. Most languages don't natively support it (e.g. nodejs doesn't have a function on Buffer to read a half-float, Rust doesn't natively support f16, etc...), which would mean we'd have to roll our own. IMO this likely means that it'd be better suited as an out-of-tree extension.

Saiv46 commented 4 years ago

Maybe we should have additional datatypes as one extension package?

And name it like protodef-extensions to standartalize additional datatypes and node-protodef-extensions for implementation

rom1504 commented 4 years ago

Why not but I think it would be good to have a name more specific than this so it doesn't end up being a pile of hundred of random types.

What else but float16 would go in that ?

On Mon, May 18, 2020, 09:40 Alexander Ivanov notifications@github.com wrote:

Maybe we should have additional datatypes as one extension package?

And name it like protodef-extensions to standartalize additional datatypes and node-protodef-extensions for implementation

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ProtoDef-io/ProtoDef/issues/32#issuecomment-630003559, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437VJGEQNTLRHPWLVT3TRSDRARANCNFSM4NDNBHVQ .

rom1504 commented 4 years ago

What I've been doing is putting specific types where they are needed (eg in prismarine-nbt, in node-minecraft-protocol, in pocket-minecraft-protocol, in node-diablo-protocol) and it works pretty well since protodef is extendable. There has been only a few rare case (one was adding little endians numerical types for pocket-minecraft-protocol) where the types where generic enough and common enough that we thought it was useful to add them in protodef itself.

Maybe that approach would work for your use case too ?

On Mon, May 18, 2020, 13:16 Romain Beaumont romain.rom1@gmail.com wrote:

Why not but I think it would be good to have a name more specific than this so it doesn't end up being a pile of hundred of random types.

What else but float16 would go in that ?

On Mon, May 18, 2020, 09:40 Alexander Ivanov notifications@github.com wrote:

Maybe we should have additional datatypes as one extension package?

And name it like protodef-extensions to standartalize additional datatypes and node-protodef-extensions for implementation

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ProtoDef-io/ProtoDef/issues/32#issuecomment-630003559, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437VJGEQNTLRHPWLVT3TRSDRARANCNFSM4NDNBHVQ .