I feel obligated to post a link to this excellent (albeit incomplete) writeup of posits and unums, which can more accurately represent common fractions in memory at the same (or lower) bit size compared to traditional floating point.
Said page also includes the single best slightly-above-entry-level explanation of how floating point works I’ve ever seen.
i have so many protocols to represent the most common fractions perfectly without needing more than just ONE bit. They even work with positive and negative infinity!
The trick is to first negotiate the protocol youre using.
Can you explain how this works exactly? Do you mean you have like a “third type” or “fraction”: 3 and you just store 00 for 0/3, 01 for 1/3, 10 for 2/3, 11 for 3/3? If it’s an object, struct, or class type to store the context, then it’s not a primative and has a lot of overhead for arithmetic and I don’t see how you could possibly even do simple things like 1/3 + 2/6
As far as I understand, it seems to sacrifice accuracy at larger numbers, for more accuracy at smaller numbers. As they say, that seems like a reasonable tradeoff, because we tend to mostly use smaller numbers in our software.
In my honest opinion though, if accuracy is a concern, I reach for decimal or integer based mathematical libraries. For example, in a JavaScript project that needed to handle currency, I used Dinero, because $0.1 + $0.2 needs to actually work properly. As far as I understand, it just does all math in integers, and then you can display it as a string in the UI or export it as an integer for storage as a realised decimal in the database.
It’s easier to just compute the smallest atomic amount of a currency, usually cents, using integers. Then display it as full dollars, pounds, euros—what have you—to the end user. For Division you need some way to account for the remainder across transactions, but that’s probably rules from accounting and not integer math.
What’s the benefit of Dinero? Is that like the financial equivalent of the iseven() dependency?
JavaScript is a bit funny and doesn’t actually have native integers… every number is a floating point, which means even whole number math gets weird sometimes. Not often, but enough that cents were lost and people were upset.
I haven’t looked at how Dinero works under the hood, but I never had any problems at all with it after we started using it. Front end works in cents, back end works in decimal, is what I’d suggest for anyone else reading this. Statically typed languages are much easier to control and you don’t need a library at all if you’re careful.
I don’t know how people deal with JavaScript. It’s like it was made for rapidly making shitty canoes out of tarps and duct tape for the early internet, and now you’re expected to build deep sea submersibles with reinforced tarps and extra-strong duct tape. Wtf…
Yeah… I like the syntax, but I hate the old jank. Still one of my favourite languages regardless. But definitely your first year will be variations of “why does JavaScript do that” 😂 I damn near quit when I had to do timezone and scheduling stuff with native date objects
Btw I’m not the one downvoting you someone else is. And yeah it sounds like an entirely different beast from normal programming almost like memory constrained embedded programming is its own beast.
Lol that makes a lot of sense now! I thought you had a hate stalker downvoting every new comment you make which seems to be a thing on Lemmy for some reason.
Isn’t a big point of floating point that it can easily have mathematical operators done on them on CPUs? Sure, complex circuitry is no big deal these days, but IIRC, there were very good reasons for what was chosen.
One of the linked papers makes the claim that the circuitry would be less complex than that needed for floats, but also includes this note:
Floats have one advantage over posits for the hardware designer: the fixed location of bits
for the exponent and the fraction mean they can be decoded in parallel. With posits, there is a
little serialization in having to determine the regime bits before the other bits can be decoded.
There is a simple workaround for this in a processor design, similar to a trick used to speed the
exception handling of floats: Some extra register bits can be attached to each value to save the
need for extracting size information when decoding instructions.
The proposed system also lacks NaN and separate positive/negative infinities, so it wouldn’t be a drop-in replacement.
I feel obligated to post a link to this excellent (albeit incomplete) writeup of posits and unums, which can more accurately represent common fractions in memory at the same (or lower) bit size compared to traditional floating point.
Said page also includes the single best slightly-above-entry-level explanation of how floating point works I’ve ever seen.
i have so many protocols to represent the most common fractions perfectly without needing more than just ONE bit. They even work with positive and negative infinity!
The trick is to first negotiate the protocol youre using.
protocol schema 1/2
1 bit, little endian
if one: value is exactly 1/2
If zero: value is NOT one half
Schema 1/3
if one: value is 1/3
I’ve managed to create a compression algorithm that reduces files down to a single bit. I call it “is this file ‘loss.png’?”.
It’s guaranteed 100% lossless with any input!
Reminds me of MetaGolfScript.
Can you explain how this works exactly? Do you mean you have like a “third type” or “fraction”: 3 and you just store 00 for 0/3, 01 for 1/3, 10 for 2/3, 11 for 3/3? If it’s an object, struct, or class type to store the context, then it’s not a primative and has a lot of overhead for arithmetic and I don’t see how you could possibly even do simple things like 1/3 + 2/6
is_half = True is_third = TrueAs far as I understand, it seems to sacrifice accuracy at larger numbers, for more accuracy at smaller numbers. As they say, that seems like a reasonable tradeoff, because we tend to mostly use smaller numbers in our software.
In my honest opinion though, if accuracy is a concern, I reach for decimal or integer based mathematical libraries. For example, in a JavaScript project that needed to handle currency, I used Dinero, because $0.1 + $0.2 needs to actually work properly. As far as I understand, it just does all math in integers, and then you can display it as a string in the UI or export it as an integer for storage as a realised decimal in the database.
It’s easier to just compute the smallest atomic amount of a currency, usually cents, using integers. Then display it as full dollars, pounds, euros—what have you—to the end user. For Division you need some way to account for the remainder across transactions, but that’s probably rules from accounting and not integer math.
What’s the benefit of Dinero? Is that like the financial equivalent of the iseven() dependency?
JavaScript is a bit funny and doesn’t actually have native integers… every number is a floating point, which means even whole number math gets weird sometimes. Not often, but enough that cents were lost and people were upset.
I haven’t looked at how Dinero works under the hood, but I never had any problems at all with it after we started using it. Front end works in cents, back end works in decimal, is what I’d suggest for anyone else reading this. Statically typed languages are much easier to control and you don’t need a library at all if you’re careful.
That’s cursed.
I don’t know how people deal with JavaScript. It’s like it was made for rapidly making shitty canoes out of tarps and duct tape for the early internet, and now you’re expected to build deep sea submersibles with reinforced tarps and extra-strong duct tape. Wtf…
Yeah… I like the syntax, but I hate the old jank. Still one of my favourite languages regardless. But definitely your first year will be variations of “why does JavaScript do that” 😂 I damn near quit when I had to do timezone and scheduling stuff with native date objects
Btw I’m not the one downvoting you someone else is. And yeah it sounds like an entirely different beast from normal programming almost like memory constrained embedded programming is its own beast.
I remove my own default upvote from my comments because I’m a weirdo
Lol that makes a lot of sense now! I thought you had a hate stalker downvoting every new comment you make which seems to be a thing on Lemmy for some reason.
Isn’t a big point of floating point that it can easily have mathematical operators done on them on CPUs? Sure, complex circuitry is no big deal these days, but IIRC, there were very good reasons for what was chosen.
One of the linked papers makes the claim that the circuitry would be less complex than that needed for floats, but also includes this note:
The proposed system also lacks NaN and separate positive/negative infinities, so it wouldn’t be a drop-in replacement.