SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 20 | January | 2005 ]

>> Next Message >>


Date: Thu, 20 Jan 2005 10:05:58 PST8
From: "Gregory W. Smith" <gsmith@well.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: Ongoing

Content Type: text/plain

Lynn H. Maxson wrote:
> I can't let 2/3.1 pass without comment. It's the 'int' disease.
> That says that only binary integers exist in the universe.
> Whereas in the real world binary and decimal integers exist.
> It also says that the only "real" numbers allowed are floating
> point. Whereas in the "real" world decimals reals, decimal
> numbers with fractional components, exist. I dislike belaboring
> the point that the "real" world represents the "problem
> set";our software world, the "solution set".

And what about the third set that you seem to forget: the
"implementation set". For a long time, very few people bought
machines that did decimal arithmetic. I know that my fist OS/2
machine did not have decimal arithmetic--binary only. Of course
features have been added since the 386; one of those features
happens to be limited decimal arithmetic on current Pentium
processors. Anyway, I doubt that many of those who bought PC's
in the eighties really cared if the processor did BCD arithmetic.
If you needed decimal arithmetic and you knew you needed it, then
you rolled your own or used BCD routines in some library. In the
same way, geeks that wanted floating point were free to roll their
own or find a floating point library.

> It makes a difference if 2/3.1 is a /
> or a /. In the first instances
> you have two different types with different precision where
> you compromise "strong" typing by implementing an implicit
> conversion without even bothering with the type of the result
> and its assignment. In the second you have a single type
> (fixed point decimal) with different precisions and no type
> conversion (only that of precision) occurs.

True. But you still have a collision between your "solution set"
and the "implementation set". At least I got that impression from
a quick scan of the Pentium documentation. The default BCD format
and instructions for the processor are integers. If you want to
have , then your compiler is going to have to
generate the code for normalization and tracking the decimal point.

> If you write business applications using binary and floating
> point variables, you will not get the same results which occur
> with using using fixed point decimal arithmetic. I've seen this
> happen so many times in a C environment. The most recent
> damning instance was that between the ISO and the PX (when
> it still existed) which couldn't have their energy costs
> calculations match between the two companies.

You can still get different results even if you use decimal
arithmetic. The ISO and PX won't match on energy costs unless
they invoke the same rounding rules on the same intermediate
values. The expression
result = a*b/c
is not necessarily the same as
temporary = a*b
result = temporary/c
Rounding and truncation of intermediate values can propagate
through millions of calculations and affect the final result.
In the example 2/3.1, the answer is 0.6 when the result is
stored as . A difference occurs, however,
with the expression 2/3.1*1.00 where the last term is
. Does the guard digit in the division
carry through giving the answer 0.64, or should it get
dropped giving the answer 0.60? And if we carry guard digits
through, do we round or truncate? Is it 0.64 or 0.65? It
might be a minor implementation detail to some, or it could
be a major detail to others.

--
Gregory W. Smith (WD9GAY) gsmith@well.com

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


>> Next Message >>

Return to [ 20 | January | 2005 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.