Hi Sven,
I just tried 46.79 asScaledDecimal and 46.79 asScaledDecimal: 2 in both
VAST and Pharo and see quite different results.
In VAST, not providing a scale returns 46.79, but with a scale of 14
(46.79s14). But it is still 46.79.
What's good is that the results of "asScaledDecimal: 2" yields the same
results on VAST and Pharo.
Your examples also use a fixed scale of 2. So is it safe to assume that
when you provide the scale, ScaledDecimal is good for monetary amounts
in Pharo? I ask because that is what I once learned in an IBM training
decades ago: use ScaledDecimals for money and percentages, never use floats.
Would you agree that as a rule of thumb, Pounds, Dollars and Euros are
safely stored and processed when you make sure to always provide the
scale of 2 (unless you manage stock or petrol prices which use 3 or 4 or
even more digits)?
Joachim
Am 30.08.21 um 14:31 schrieb Sven Van Caekenberghe:
David,
On 30 Aug 2021, at 14:02, David Pennington <da...@totallyobjects.com> wrote:
Hi everyone. I have a little bank analysis package for my own use but having
trouble displaying and storing amounts. I parse out a CSV file from the bank
and convert the amounts from text to ScaledDecimal. I then store these into a
STON file, which converts them back to text. I then read them in and convert
them back to ScaledDecimal again.
I am not used to ~Pharo have spent 24 years using VisualAge Smalltalk so I need
a little bit of help because I am getting 1 Penny errors in the conversions. I
can cope with this but I would like to get it right.
Can anyone give me a simple means of managing, say, an amount like £76.49 from
the bank so that it stops coming back to me as £76.48?
David
Totally Objects
Working with money is always challenging. I know that many people say 'Use
ScaledDecimal' as if that magically solves all problems but it does not.
ScaledDecimal is a bit of a dangerous class to use. It is just a fraction with
a certain precision. Internally it might be pretty accurate with respect to
most operations, its external representation as floating point number can be
misleading, as this representation is prone to all problems related to floating
point (including the fact that decimal and binary floating point are not the
same).
STON does not doing anything wrong as far as I know. Consider the following:
| amount ston |
amount := 76.49 asScaledDecimal.
ston := STON toString: amount.
STON fromString: ston.
(STON fromString: ston) = amount.
"true"
| amount ston |
amount := 76.49 asScaledDecimal: 2.
ston := STON toString: amount.
STON fromString: ston.
(STON fromString: ston) = amount.
"true"
| amount ston |
amount := 76.49.
ston := STON toString: amount.
STON fromString: ston.
(STON fromString: ston) = amount.
"true"
BUT, 76.49 asScaledDecimal already has your penny loss (if rounded to pennies).
HTH,
Sven
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
