SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Thu, 20 Jan 2005 11:32:01 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Ongoing

Content Type: text/plain

Greg,

It may come as a surprise to you, but I have never owned a
PC that didn't support fixed decimal arithmetic, although
originally the only compiler that supported it was the PL/I
compiler from Digital Research, the authors of CP/M. Quite
frankly I had a LISP (IQLISP) interpreter that implemented it in
software, supporting up to 255 digits.

The purpose of a HLL, one step up from symbolic assembly,
lay in freeing programming (and programmers) from machine
architectures: to provide portability. If that meant providing
something through software not available in the underlying
machine instruction set, so be it.

However, that goes beyond my point. I should restate it. A
symbolic decimal number with or without a decimal point (a
fractional portion) yesterday, today, and tomorrow will never
be binary or float. It's sheer arrogance, if not an admission of
laziness or incompetence, that a "5" or a "3.1" are respectfully
anything except decimal integer and real numbers.

I should look in a C reference manual to set if it allows a
0101b as a binary constant. I will guarantee you that it does
not allow for a binary real, a binary number with a fractional
part, as does PL/I. That requires software in addition to the
hardware support.

My point wasn't to show the deficiencies of some computer
instruction sets, but that not all people translate "2/3.1" the
same. In Python you have to relax the typing rules to
conveniently allow a very common occurrence in an
expression, whereas in PL/I you do not. In PL/I you could
interchange each as decimal or binary integer or real as well
as float without any change to the typing rules.

That in itself doesn't make PL/I "better" than Python. I have
no interest in pursuing that argument. I only had a interest in
pointing out that a "2" is a decimal integer. It's entitled to
consideration as such, not simply limited to some binary form.
In the same manner "3.1" is a decimal real and will never, ever
in this symbolic form be a floating point number. We have a
separate symbolic form for designating floating point numbers
as well as binary integers and reals.

Both you and Steven are correct that you can get
incompatible results doing decimal arithmetic using different
algorithms. That's a separate discussion. I only wanted to
point out that I saw "2/3.1" somewhat more broadly as you
saw it more narrowly.

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

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

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

Return to [ 20 | January | 2005 ]

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.