Velocity Reviews > sscanf question

# sscanf question

Edward A. Falk
Guest
Posts: n/a

 12-15-2012
In article <(E-Mail Removed)>,
Fred K <(E-Mail Removed)> wrote:
>
>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.

--
-Ed Falk, http://www.velocityreviews.com/forums/(E-Mail Removed)
http://thespamdiaries.blogspot.com/

Les Cargill
Guest
Posts: n/a

 12-15-2012
Edward A. Falk wrote:
> In article <(E-Mail Removed)>,
> Fred K <(E-Mail Removed)> wrote:
>>
>> 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.
>

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

> 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

Barry Schwarz
Guest
Posts: n/a

 12-15-2012
On Sat, 15 Dec 2012 03:28:28 +0000 (UTC), (E-Mail Removed) (Edward A.
Falk) wrote:

>In article <(E-Mail Removed)>,
>Fred K <(E-Mail Removed)> wrote:
>>
>>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.

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.

--
Remove del for email

glen herrmannsfeldt
Guest
Posts: n/a

 12-15-2012
Edward A. Falk <(E-Mail Removed)> wrote:

(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
Guest
Posts: n/a

 12-15-2012
Les Cargill <(E-Mail Removed)> writes:
> Edward A. Falk wrote:
>> In article <(E-Mail Removed)>,
>> Fred K <(E-Mail Removed)> wrote:
>>>
>>> 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.

>
> 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.

[...]

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

glen herrmannsfeldt
Guest
Posts: n/a

 12-15-2012
Keith Thompson <(E-Mail Removed)> wrote:
> Les Cargill <(E-Mail Removed)> writes:

(snip)
>> 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.

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
Guest
Posts: n/a

 12-15-2012
Keith Thompson wrote:
> Les Cargill <(E-Mail Removed)> writes:
>> Edward A. Falk wrote:
>>> In article <(E-Mail Removed)>,
>>> Fred K <(E-Mail Removed)> wrote:
>>>>
>>>> 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.

>>
>> 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.

--
Les Cargill

glen herrmannsfeldt
Guest
Posts: n/a

 12-15-2012
Les Cargill <(E-Mail Removed)> wrote:
> Keith Thompson wrote:

(snip, someone wrote)
>>> 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.

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
Guest
Posts: n/a

 12-15-2012
glen herrmannsfeldt wrote:
> Les Cargill <(E-Mail Removed)> wrote:
>> Keith Thompson wrote:

>
> (snip, someone wrote)
>>>> 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.

>
> 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.

--
Les Cargill

Eric Sosman
Guest
Posts: n/a

 12-15-2012
On 12/15/2012 4:33 PM, Les Cargill wrote:
> glen herrmannsfeldt wrote:
>> [...]
>> 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."

--
Eric Sosman
(E-Mail Removed)d