Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

0.30000000000000004

0.30000000000000004.com

Post reply on HN
Print view View original

101–110 of 422 posts

Re: 0.30000000000000004

#101

Post by Smaug123 »

_bxg1 wrote: post #40
miketuritzin wrote: post #21

Earlier quoted context omitted.

Reminds me of this Inigo Quilez article on experimenting with rendering using rational numbers: https://iquilezles.org/www/articles/floatingbar/floatingbar....

I actually ran into a bug recently while implementing my first raytracer, where the point calculated from the sphere-intersect test would just occasionally end up inside the sphere due to floating point imprecision, so the diffuse sample rays would have their origins completely in the dark, leading to randomly black pixels. Solved it by bumping every intersection out by 0.01 in the direction of its normal. And then o…

This phenomenon has a name, by the way: "shadow acne" (which is actually a more general phenomenon, but this is an example of it).

Re: 0.30000000000000004

#103

Post by tombert »

_bxg1 wrote: post #79
_y5hn wrote: post #67

Earlier quoted context omitted.

It's actually in use in many places, for things like handling currency and money, and for when you get funny corner cases involving rounding such numbers and pooling the change. Whenever I see someone handling currency in floats, something inside me wither and die a small death.

I haven't worked in fintech but I've read that money is often represented (at least in storage) as plain integers, since for example US currency only ever goes to two decimal places. But I guess once you start operating on it you run into potential truncation unless you use rationals.

You can still get reasonable enough approximations with more than two decimals if you do something like `int64 myWorkingMoneyVal = currentMoney * 100000`, do your work, then divide the final result by 100000. You still risk some potential truncation if your work involves division, but the larger your multiplier that you're working with, the larger divisor at the end, which will help minimize how much of an error this ends up being. The 64 bit integer space is pretty darn big, so you typically don't risk an overflow, and you will typically get better performance than using a regular "decimal" type, since on-chip integer operations are usually very fast.

EDIT: Just a note, there's nothing special about the number 100000; pick the largest exponent of 10 that you can get away with a reasonable assurance that no overflow is possible. For a vast majority of money applications, I seriously doubt you're going to be hitting the limits of int64, so you could probably even get away with something like 1000000000.

Re: 0.30000000000000004

#105

Post by Tade0 »

jonny_eh wrote: post #36

> It's actually pretty simple The explanation then goes on to be very complex. e.g. "it can only express fractions that use a prime factor of the base". Please don't say things like this when explaining things to people, it makes them feel stupid if it doesn't click with the first explanation. I suggest instead "It's actually rather interesting".

I had to use google translate for this one, because I didn't suspect the translation to my language to be so literal.

My take is that this sentence is badly worded. How do these fractions specifically use those prime factors?

Apparently the idea is that a fraction 1/N, where N is a prime factor of the base, is rational in that base.

So for base 10, at least 1/2 and 1/5 have to be rational.

And given that a product of rational numbers is rational, no matter what combination of those two you multiply, you'll get a number rational in base 10, so 1/2 * 1/2 = 1/4 is rational, (1/2)^3 = 1/8 is rational etc.

Same thing goes for the sum of course.

So apparently those fractions use those prime factors by being a product of their reciprocals, which isn't mentioned here but should have been.

Re: 0.30000000000000004

#106

Post by saagarjha »

pmarreck wrote: post #100
saagarjha wrote: post #74

Earlier quoted context omitted.

IEEE is deterministic and (IMO) quite well thought-out. What specifically do you not like about it?

The fact that the most trivial floating-point addition of 0.1 + 0.2 = 0.300000000000004 was insufficient to make this seem HUMAN-nondeterministic to you? (I mean sure, if you thoroughly understood the entire spec, you might not be surprised by this result, but many people would be! Otherwise the original post and website would not exist, no?) It’s kind of a hallmark of bad design when you have to go into a long-winde…

You don't need to thoroughly understand the entire spec, nor do you need to know that 0.1 + 0.2 = 0.300000000000004. "Computers can't really represent floating point numbers exactly" is generally good enough. (Also: you added "human" as a qualifier; you didn't have that before so I responded to your statement as it was written.)

Re: 0.30000000000000004

#107

Post by School-Cotton »

saagarjha wrote: post #94
School-Cotton wrote: post #89

Earlier quoted context omitted.

Curious, when can't you? My mental model of floating-point types is that they are useful for scientific/numeric computations where values are sampled from a probability distribution and there is inherently noise, and not really useful for discrete/exact logic.

Right; for the former integer arithmetic won't do.

Yep, absolutely (and increasingly often people are using 16-bit floats on GPUs to go even faster).

But the person you replied to said programming logic, not programming anything.

Honestly I think if you care about the difference between `<` and `<=`, or if you use `==` ever, it's a red flag that floating-point numbers might be the wrong data type.

Re: 0.30000000000000004

#108

Post by snickerbockers »

crazygringo wrote: post #81
snickerbockers wrote: post #48

Earlier quoted context omitted.

There is no "better floating point model" because floating point will always be floating point. Fixed point always has been and always will be an option if you don't like the exponential notation.

> Fixed point always has been and always will be an option Not really. It would be really cool if fixed point number storage were an option... but I'm not aware of any popular language that provides it as a built-in primitive along with int and float, just as easy to use and choose as floats themselves. Yes probably every language has libraries somewhere that let you do it where you have to learn a lot of function ca…

You don't need special support from the language, fixed-point arithmetic is effectively the same as integer.

DOOM's implementation of fixed-point is a good example which should work on any platform as long as sizeof(int) >= 4.

https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.... https://github.com/id-Software/DOOM/blob/master/linuxdoom-1....

Addition and subtraction will work normally. Multiplication also works normally except you need to right-shift by FRAC_BITS afterwards (and probably also cast to a larger integer type beforehand to protect against overflow).

Division is somewhat difficult since integer division is not what you want to do. DOOM's solution was to cast to double, perform the division, and then convert that back to fixed-point by multiplying by 1.0 before casting back to integer. This seems like cheating since it's using floating-point as an intermediate type, but it is safe to do because 64-bit floating point can represent all 32-bit integers. As long as you're on a platform with an FPU it's probably also faster than trying to roll your own division implementation.

Re: 0.30000000000000004

#109

Post by megous »

_bxg1 wrote: post #17

I remember in college when we learned about this and I had the thought, "Why don't we just store the numerator and denominator?", and threw together a little C++ class complete with (then novel, to me) operator-overloads, which implemented the concept. I felt very proud of myself. Then years later I learned that it's a thing people actually use: https://en.wikipedia.org/wiki/Rational_data_type

Not all numbers are rational.

Re: 0.30000000000000004

#110

Post by daniel-thompson »

_bxg1 wrote: post #40
miketuritzin wrote: post #21

Earlier quoted context omitted.

Reminds me of this Inigo Quilez article on experimenting with rendering using rational numbers: https://iquilezles.org/www/articles/floatingbar/floatingbar....

I actually ran into a bug recently while implementing my first raytracer, where the point calculated from the sphere-intersect test would just occasionally end up inside the sphere due to floating point imprecision, so the diffuse sample rays would have their origins completely in the dark, leading to randomly black pixels. Solved it by bumping every intersection out by 0.01 in the direction of its normal. And then o…

Here's some good reading on robust ways to fix this without an arbitrary epsilon bump: http://www.pbr-book.org/3ed-2018/Shapes/Managing_Rounding_Er...
Post reply on HN