undefined | Better HN

story

0 pointsjgtrosh6y ago0 comments

Sounds like fractions cleanly describe what you're saying?

But that practically holds only for a reasonable amount of simple arithmetics. Fractional components tend to grow exponential for many numerical methods repeated multiple times. This can happen if you're describing money and want to apply a complex numerical method from an economics article for whatever purpose. Might be worth it but be careful not to carry ever expanding fractions in your system.

0 comments

NohatCoder6y ago

This only for dealing with actual money, generally our banking systems have rounding rules that prevent the fractions from getting out of hand.

If you are running an economic simulation you generally don't have to worry about rounding, the whole thing is only approximate anyway.

hermitdev6y ago

Yup. Once worked on a big project with one of the largest US exchanges. We were migrating large OTC (over the counter) CDS (credit default swaps) contracts to standardized centralized contracts. We were testing with large contracts, millions of contracts worth trillions of dollars. I was off by a single penny and failed the test. Took a while to find, but it was due to a truncate to zero instead of a proper round. I was using a floating point type instead of a proper decimal. Dont think the language I was using had a proper decimal type at the time, though it does now, 11 years later.

j / k navigate · click thread line to collapse

0 comments

NohatCoder6y ago

This only for dealing with actual money, generally our banking systems have rounding rules that prevent the fractions from getting out of hand.

If you are running an economic simulation you generally don't have to worry about rounding, the whole thing is only approximate anyway.

hermitdev6y ago

j / k navigate · click thread line to collapse