sscanf question

[Edward A. Falk]

Integer times 100 - i.e., in integer units of the smallest unit in the monetary system.

So $1.23 is stored as 123

The reason is to avoid roundoff and truncation errors.

Well, when it comes time to compute the daily interest, there's really
no way to avoid roundoff and truncation errors. We struggled with the
problem for a month and never really solved it. Now I now know why people
steal round-off error -- it really would have simplified things for us.

But yes, at the very least don't use a format that has no representation
for your unit of currency. There's no floating point representation of
$.01. Even floating point would be acceptable as long as you multiplied
by 100, e.g. 123.0 *is* an exact representation.

 

[Les Cargill]

Well, when it comes time to compute the daily interest, there's really
no way to avoid roundoff and truncation errors. We struggled with the
problem for a month and never really solved it. Now I now know why people
steal round-off error -- it really would have simplified things for us.

BCD was no help? Or am I the last person to have used BCD in anger...

 

[Barry Schwarz]

Well, when it comes time to compute the daily interest, there's really
no way to avoid roundoff and truncation errors. We struggled with the
problem for a month and never really solved it. Now I now know why people
steal round-off error -- it really would have simplified things for us.

But yes, at the very least don't use a format that has no representation
for your unit of currency. There's no floating point representation of
$.01. Even floating point would be acceptable as long as you multiplied
by 100, e.g. 123.0 *is* an exact representation.

What you say may be true for systems that use the IEEE format (or
similar ones) for floating point but there are systems that have
actual decimal floating point built into the hardware. On these
systems, .01 is represented exactly and so is any other decimal value
with at most x_DIG (where x is FLT, DBL, or LDBL) digits.

 

[glen herrmannsfeldt]

(snip)

But yes, at the very least don't use a format that has no representation
for your unit of currency. There's no floating point representation of
$.01. Even floating point would be acceptable as long as you multiplied
by 100, e.g. 123.0 *is* an exact representation.

Actually, there is in IEEE 754-2008 if you have a computer that
implements the new formats.

Still, not so much reason to use it over fixed point for financial
calculations.

-- glen

 

[Keith Thompson]

BCD was no help? Or am I the last person to have used BCD in anger...

BCD is just another way of representing integers. It makes certain
operations (multiplying or dividing by powers of 10) more efficient, but
it doesn't really give you any more expressive power than decimal.

[...]

 

[glen herrmannsfeldt]

(snip)

BCD is just another way of representing integers. It makes certain
operations (multiplying or dividing by powers of 10) more efficient, but
it doesn't really give you any more expressive power than decimal.

And you can do a lot of multiplying and dividing by powers
of ten working with integers scaled by powers of ten.

Whether you do it explicitly, or the compiler does it for
you, it is done either way.

Also, BCD is easier to convert to/from human readable
(printable, or zoned decimal) form. If you want to read data,
do a small amount of computation, and then print it out, it
is often faster in BCD form.

-- glen

 

[Les Cargill]

BCD was no help? Or am I the last person to have used BCD in anger...

BCD is just another way of representing integers. It makes certain
operations (multiplying or dividing by powers of 10) more efficient, but
it doesn't really give you any more expressive power than decimal.

[...]

I vaguely recall that the ability to have arbitrary precision was
deemed important.

 

[glen herrmannsfeldt]

Keith Thompson wrote:

(snip, someone wrote)

I vaguely recall that the ability to have arbitrary precision was
deemed important.

Some of the earlier decimal machines (with a variety of different
representations) used word marks to indicate the end of a field, and
so allowed arbitrary field width.

S/360 style BCD provides up to 31 digits for add and subtract.
The limits for multiply and divide are more complicated, but
PL/I (F) allows up to 15 digits.

So, a little more than 32 bit binary.

-- glen

 

[Les Cargill]

(snip, someone wrote)


Some of the earlier decimal machines (with a variety of different
representations) used word marks to indicate the end of a field, and
so allowed arbitrary field width.

S/360 style BCD provides up to 31 digits for add and subtract.
The limits for multiply and divide are more complicated, but
PL/I (F) allows up to 15 digits.

So, a little more than 32 bit binary.

-- glen

This wasn't machine-based BCD. This was through a library,
in a 32-bit machine. I do not recall if there was long long
(64 bit) support. Probably wasn't.

We had to keep gallon totalizers for the life of a fuel
dispenser that had to have documented agreement with a mechanical
(odometer) totalizer to the limits of what Weights and Measures
required. So that requirement rippled throughout the system.

 

[Eric Sosman]

[...]
S/360 style BCD provides up to 31 digits for add and subtract.
The limits for multiply and divide are more complicated, but
PL/I (F) allows up to 15 digits.

So, a little more than 32 bit binary.

This wasn't machine-based BCD. This was through a library,
in a 32-bit machine. I do not recall if there was long long
(64 bit) support. Probably wasn't.

It was "machine-based" at least to the extent of having
instruction codes defined to perform it. See pages 34ff of
<http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf>.

On some S/360 models the hardware to implement decimal
opcodes was an optional feature (the "Commercial Instruction
Set option"). But then, on some S/360 models floating-point
hardware (the "Scientific Instruction Set" option) was also
an optional feature, and I haven't heard anyone claim that
S/360 floating-point wasn't "machine-based."

 

[glen herrmannsfeldt]

(snip, I wrote)

It was "machine-based" at least to the extent of having
instruction codes defined to perform it. See pages 34ff of
<http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf>.

On some S/360 models the hardware to implement decimal
opcodes was an optional feature (the "Commercial Instruction
Set option"). But then, on some S/360 models floating-point
hardware (the "Scientific Instruction Set" option) was also
an optional feature, and I haven't heard anyone claim that
S/360 floating-point wasn't "machine-based."

Well, the smaller S/360 processors were all microcoded, so the
real question was optional microcode for both the decimal
and floating point case.

I believe even on machines without the floating point
option that the registers were still there.

The decimal instructions are storage to storage, except
for CVB (storage to register) and CVD (register to storage).
(Those are ConVert to Binary and ConVert to Decimal.)

Also, the 360/91 didn't implement the decimal instructions,
though it did have CVB and CVD. The OS based emulation mostly
used those instructions to do the emulation.

-- glen

 

[Nick Keighley]

OK, by using 'special methods' as I mentioned. You've now also introduced
the arbitrary figures 10 (10*15.9), 500 and 1000, and presumably need to
impose some arbitrary convention as to how percentage values are going tobe
represented in the program (I guess you can't just have 15.9 or 0.159).

At this level of program, just using floating point is a lot easier! You
just need to round to a cent at every stage, taking care when values are
negative; one little function.


Do you have a calculation where that rounding (which will be to the
low-order bits of the representation) will actually give a different result
to doing the whole thing with integers? (And with ordinary amounts that are
likely to be encountered.)


No. Waste of time inventing floating point, really!

and rather horrid and easy to get wrong floating point! Fixed point is
just nasty- leave it to the embedded programmers.