Re:Understanding Ethereum Smart Contracts
by Kranar on Wednesday November 29, 2017 @05:21PM
(#15811445)
Yes, we are on the same page. BigDecimal is appropriate for representing money, fixed point arithmetic is not. I simply argue that in situations where you care about performance, you can actually drop BigDecimal and use floating point decimal or even floating point binary and get perfectly good results that have exact precision so long as you model your domain.
Re:Understanding Ethereum Smart Contracts
by Groxx on Wednesday November 29, 2017 @07:07PM
(#15812138)
Yeah, if you know your domain and know you're creating only an acceptable amount of error, by all means float it up. Floats are easy to use and predictable nearly everywhere, since nearly everyone follows the same spec.
Generally though, I think people don't quite do due-diligence here. And/or the domain changes enough that numbers get large enough to invalidate the earlier analysis. There are obviously exceptions to this though, and for them, they know what they're doing and why they're doing it and it's all good.
If so: totally agreed. Inflexible single-scaled-ints have been a plague in nearly every piece of production code I've seen them in. I'll take floats (well, doubles) any day over this.
Flexible scale tho (arbitrary precision / bigdecimal equivalents (I'd prefer bigdecimal over home-grown two-int variants, obv)) usually works out. And tends to avoid semi-frequent-though-usually-unimportant/unnoticed[1] issues with imprecise floats (~16 million for exact int representation[2] is awfully small, though doubles are generally Good Enough™).
[1]: usually. adding doubles/fractions often produces garbage-looking output unless you remember to round. but in my lines of work, nobody cares[1.1] if it's a couple cents off in analytics.
[2]: https://stackoverflow.com/questions/3793838/which-is-the-fir...
[1.1]: yet