Why not FP for Money?

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

I understand that when your numbers got large enough, you'd start to
lose the pennies, but how many of us have the luxury of doing
computation with quadrillions of dollars actually care about the
pennies? Besides, you could check for HUGE numbers and do something
special with them if you wanted.

What am I missing here?

Noone would use or buy your software if it throws money out the window.
Even pennies.

 

[Alex Martelli]

Lots of currency symbols are suffixed (3.52 DM) instead of prefixed.
How about $ as a suffix?

Once you're going suffix, you could dispense with the horrid ambiguity
of '$' (which might play havoc with values if a program is ever moved
across, say, the US/Canada border;-) and go for the unambiguous standard
three-letter suffixes, such as USD, EUR, &c...;-)


Alex

 

[Alex Martelli]

A native Money type, either with the $ signal ($35.72) or the suffix
(35.72D) would not present the same issues, because the literal would

Right, but in practice I find that:

def d(x): return decimal.Decimal(str(x))

appears to work pretty well, judging from early experimentation.


Alex

 

[Paul Rubin]

Right, but in practice I find that:

def d(x): return decimal.Decimal(str(x))

appears to work pretty well, judging from early experimentation.

Hmm. What does d(35.72) give you? The same thing as d('35.72')?
Either answer is arguably wrong.

 

[Alex Martelli]

Hmm. What does d(35.72) give you? The same thing as d('35.72')?
Either answer is arguably wrong.

yep, str(35.72) == '35.72'. As I use d() only on literals, and will
carefully avoid it if I should ever enter more than six digits in such a
literal, _in practice_ (as I said) I find it works well, whether _in
theory_ it's arguably wrong or not. Were it a built-in I'd no doubt
have different feelings, but as a handy user-coded one-liner it's fine.


Alex

 

[Paul Rubin]

yep, str(35.72) == '35.72'.
Hmm.

35.719999999999999

I wonder why str(35.72) is different from repr(35.72).

 

[Peter Hansen]

35.719999999999999

I wonder why str(35.72) is different from repr(35.72).

Because "str( [object]) Return a string containing a nicely
printable representation of an object" contains the key
phrase "nicely printable"?

-Peter

 

[Alex Martelli]

35.719999999999999

I wonder why str(35.72) is different from repr(35.72).

Because they serve different purposes. As the Tutorial (appendix B)
puts it, "you'll see the result you expect in the end if you simply
round the display of your final results to the number of decimal digits
you expect. str() usually suffices". repr is such [when feasible] that
x==eval(repr(x)), str on the other hand is expected to present a nice
display for humans, fudging things a bit for the purpose.


Alex

 

[Dan Bishop]

35.719999999999999

I wonder why str(35.72) is different from repr(35.72).

Because str and repr have different purposes.

repr(x) is meant to provide enough information to re-create x, so all
float values must be distinguished from each other. This requires at
least 17 significant digits, so repr(x) == '%.17g' % x.

str(x), however, is meant to return a "nice" string representation,
and so it only uses '%.12g' % x (ignoring 5 "noise" digits at the end
of repr(x)).

 

[Paul Rubin]

str(x), however, is meant to return a "nice" string representation,
and so it only uses '%.12g' % x (ignoring 5 "noise" digits at the end
of repr(x)).

Thanks. I didn't realize that 'nice' means 'inaccurate':
0.0

I really do think now that if we're serious about supporting decimals,
we need decimal literals.

 

[Michael Hoffman]

Thanks. I didn't realize that 'nice' means 'inaccurate':

No, in this case, "nice" means "less precise." You frequently cannot get
the kind of accuracy in floating point numbers that you seem to want.

0.0

If you had chosen different values, you would have gotten differing
results even without a str/float conversion:
0.10000000000000001

Fun!