201–210 of 422 posts
In the Go example, can someone explain the difference between the first and the last case?
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.
Earlier quoted context omitted.
The real lesson is, no matter what base (radix) you use, floating point math is inexact. The value of floating point is that it can represent extremely huge or extremely infinitesimal values. If you're working with currency / money, floating point is the wrong thing to use. For the entire history of human civilization, currency has always been an integer type, possibly with a fixed decimal point. Money has always bee…
> 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…
Earlier quoted context omitted.
Amazon's EC2 hourly prices are rounded to mils ($0.011/hour). https://aws.amazon.com/emr/pricing/ Azure has some hourly prices with ten-thousandths of a cent ($0.0102/hour): https://azure.microsoft.com/en-ca/pricing/details/virtual-ma... Microsoft should use gas station 9/10 pricing conventions to just barely undercut Amazon's lowest price $0.011 with $0.0109. https://www.marketplace.org/2018/10/11/why-do-gas-prices-…
Tarsnap goes as low as counting attodollars . Yes, that's 10^-18 dollars, judging by the precision with which individual line items and total account funds are reported. Storage price is 250 picodollars per byte-month.
Earlier quoted context omitted.
When you start looking into all of this, it's interesting to see how many ways there are to represent numbers in a computer. It isn't actually obvious or trivial at all, there is no one "true" or "accurate" representation, and they all had to be invented by past computer scientists! If you're not a bank or similar but just dealing with currency to buy and sell things like for ecommerce, the default semantics of a fix…
Ask the COBOL guys and gals for the true answer ;) There are accounting, balancing, laws, regulations and reconciliation issues where for the really serious stuff, you use whatever fit spec and requirements, not the other way around. Ruby's BigDecimal will be fine, if you implement the detailed specification about how to calculate each operation every step of the way, with designated precision at various steps, toget…
Have you worked on ecommerce where you've been given such detailed specs? I have worked on ecommerce, I never have been.
I don't even understand exactly what you mean by "implementing detailed specifications about how to calculate each operation every step of the way" with ruby BigDecimal. Can you provide an example? Ordinarily, you just use ruby `+` and `*` etc operators with BigDecimal values. (Or SQL/postgres arithmetic operators with postgres money type). I don't even know what a "specification about how to calculate each operation every step of the way" would look like. This is something you've had to do with basic ecommerce apps?
I'm not sure what solution you are suggesting could be characterized as "simple stuff that are proven to work and not change over time"
Seriously, most everyone just uses something like BigDecimal or postgres Money type, and it's fine. (IEEE-754 float is NOT though. Neither, probably, is the rational type that you initially suggested... )
Earlier quoted context omitted.
Counterexample: gas prices in the US are frequently displayed with 3 decimals (tenth of cents)
It isn't really a price though, it is a rate for an infinitely divisible good, i. e. $/L. You get the price when you multiply with the quantity purchased.
Earlier quoted context omitted.
Currency handling is almost never done with rationals (numerator and denominator) and is frequently (and correctly so!) done with fixed or floating point decimal types.
This is false. It's not correct to handle currency with floating point types.
Earlier quoted context omitted.
Falsehoods programmers believe about prices: https://gist.github.com/rgs/6509585
Interesting list, though I'm not sure what do they mean by n. 7
Earlier quoted context omitted.
Tarsnap goes as low as counting attodollars . Yes, that's 10^-18 dollars, judging by the precision with which individual line items and total account funds are reported. Storage price is 250 picodollars per byte-month.
If it’s not possible to charge such amounts, what exactly is the point of the accuracy?
Earlier quoted context omitted.
Tarsnap goes as low as counting attodollars . Yes, that's 10^-18 dollars, judging by the precision with which individual line items and total account funds are reported. Storage price is 250 picodollars per byte-month.
If it’s not possible to charge such amounts, what exactly is the point of the accuracy?
Earlier quoted context omitted.
It's not correct, but in many cases it's plenty accurate
If you are dealing with other people’s money, the only accurate is accurate . Close enough should not be in any financial engineer’s mindset, imho.