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

221–230 of 422 posts

Re: 0.30000000000000004

#221

Post by nitwit005 »

jsjohnst wrote: post #215
nitwit005 wrote: post #171

Earlier quoted context omitted.

Go to a bank and ask for a half penny or a thousandth of a dollar. Let me know how it goes.

Go to a bank and ask for a $500 or $1000 note too. They won’t give you one as they aren’t in circulation anymore, but most (all?) will let you deposit it for face value.

Because, unlike a thousandth of a dollar, those are valid amounts for real transactions.

It goes without saying that half pennies are dead. A mill seems to be from the Coinage Act of 1792, which is perhaps a tad outdated.

Re: 0.30000000000000004

#223

Post by okennedy »

This specific issue nearly drove me insane trying to debug a SQL -> C++/Scala/OCaml transpiler years ago. We were using the TPC-H benchmark as part of our test suite, and (unbeknownst to me), the validation parameters for one of the queries (Q6) triggered this behavior (0.6+0.1 != 0.7), but only in the C/Scala targets. OCaml (around which we had built most of our debugging infrastructure) handled the math correctly...

Fun times.

Re: 0.30000000000000004

#224

Post by WaldoDude »

dnautics wrote: post #187
Koshkin wrote: post #32

Earlier quoted context omitted.

But rationals are more expensive to compute with (compared to floating-point; this is another example of the trade-off between performance and accuracy.)

it's not just that they are expensive, it's that there is a nondetermistic compute time. Let's say we need to do a comparison. Set a = 34241432415/344425151233 and b = 45034983295/453218433828 Which is greater? Or even more feindish, Set a = 14488683657616/14488641242046 and b = 10733594563328/10733563140768 which is greater? By what algorithm would you do the computation, and could you guarantee me the same compute…

I’m not sure I follow. Isn’t it just two integer multiplications followed by a comparison.

a/b > x/y is the same as ay > xb

Assuming you don’t overflow your integer type.

Re: 0.30000000000000004

#225

Post by jsjohnst »

nitwit005 wrote: post #221
jsjohnst wrote: post #215

Earlier quoted context omitted.

Go to a bank and ask for a $500 or $1000 note too. They won’t give you one as they aren’t in circulation anymore, but most (all?) will let you deposit it for face value.

Because, unlike a thousandth of a dollar, those are valid amounts for real transactions. It goes without saying that half pennies are dead. A mill seems to be from the Coinage Act of 1792, which is perhaps a tad outdated.

Take two half penny coins or notes to the bank and they’ll credit your account a penny. Of course, just like with the $500 or $1000 notes, you’ll be losing money on the deal.

> A mill ... is perhaps a tad outdated.

Yet you use mills every time you pay for gas. Pointless in that case? Probably. Still used all the time? Certainly.

Re: 0.30000000000000004

#226

Post by lordnacho »

While it's true that floating point has its limitations, this stuff about not using it for money seems overblown to me. I've worked in finance for many years, and it really doesn't matter that much. There are de minimis clauses in contracts that basically say "forget about the fractions of a cent". Of course it might still trip up your position checking code, but that's easily fixed with a tiny tolerance.

Re: 0.30000000000000004

#227

Post by wostusername »

jrochkind1 wrote: post #145
_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.

> It's actually in use in many places, for things like handling currency and money Hm, are you sure? I don't believe "rational" types which encode numbers as a numerator and denominator are typically used for currency/money. If they were, would the denominator always be 100 or 1000? I guess you could use a rational type that way, although it'd be a small subset of what rational data types are intended for. But I gues…

>If they were, would the denominator always be 100 or 1000?

The numerator and denominator get automatically reduced to lowest terms (just like you learned in elementary school, so 15/100 becomes 3/20) internally by every implementation I know of. This comes at a performance cost for every operation, but it helps keeping the numerator and denominator from blowing up.

>not sure how rounding works -- or even if they do rounding at all

They do not. The point of a Rational type is to keep precise values, so it's up to the programmer to decide when and how values are rounded.

>"arbitrary precision floating point" type like ruby's BigDecimal

Not sure how Ruby implements BigDecimal, but Java internally represents it as an BigInteger of digits, and a second integer that represents where in the number the decimal point should go. This means that BigDecimal still can't truly represent a value such as 1/3, since you can't have an infinite amount of 3's, but a Rational can.

>I'm not actually sure what domains rational data types are good for.

I'll be honest and say I've never had to use them either, but it's nice to know they exist. The intended use case is when you need to perform calculations and maintain as much precision and accuracy as possible in the intermediate values and such accuracy is more important than speed.

Re: 0.30000000000000004

#228

Post by exegete »

DonHopkins wrote: post #166

The runner up for length is FORTRAN with: 0.300000000000000000000000000000000039 And the length (but not value) winner is GO with: 0.299999999999999988897769753748434595763683319091796875

Those look like the same length

Re: 0.30000000000000004

#229

Post by povik »

ehsankia wrote: post #201
povik wrote: post #194

In the Go example, can someone explain the difference between the first and the last case?

There's a link right below. It seems like 1. Constants have arbitrary precision 2. When you assign them, they lose precision (example 2) 3. You can format at as a arbitrary precision in a string (example 3) In that last example, they are getting 54 significant digits in base 10.

Thanks. What I didn’t realize is that although the sum is done precisely, the resulting 0.3 will be represented approximately once converted to float64. In the first case formatting hides that, in the last it doesn’t.

Re: 0.30000000000000004

#230

Post by seppel »

School-Cotton wrote: post #202
seppel wrote: post #196

Earlier quoted context omitted.

> The real lesson is, no matter what base (radix) you use, floating point math is inexact. This is just not true. If you add 1.5 + 4.25 with IEEE754, there is nothing inexact or rounded. That you cannot exactly represent 0.1 in base2 FP is a problem of base2, not FP. You get inexact results with FP math for underflows, overflows, or if you don't have enough precision for the result (or an intermediate result). But th…

I think what that commentator meant is that floating-point math is not an accurate model of rational-number arithmetic, not that there aren't certain computations that are in fact exact. (As you point out, there are: 1.5 + 4.25 is indeed exact)

> is that floating-point math is not an accurate model of rational-number arithmetic

Well, this is true. But integer math is also not an accurate model of rational-number arithmetic, yet nobody would claim that integer math is inexact.

Post reply on HN