SCOUG-Programming Mailing List Archives
Return to [ 14 |
February |
2005 ]
<< Previous Message <<
>> Next Message >>
Content Type: text/plain
Greg, Peter,
Thank you for making my point. You probably didn't intend
to. I didn't bring up the issue of rational and transcendental
numbers. While you done an interesting expose on RATIOnal,
you might do us a favor by doing the same with
transcendental. In neither case can you go to the bank and
write a check for the exact amount. You can't get it through
a cash register. Use it to pay for your insurance. Or make
sense of your medical bills.
The danger with "int" is that it doesn't represent the class of
integer numbers. It doesn't and it can't. With any
implementation choice it can do no more than a subset. The
addition of "short" and "long" only changes the size of the
subset. More importantly the programmer, the one who is
actually trying to solve the problem, has no control over the
subset.
He had no control over it in FORTRAN. That was regarded as
a limitation in that FORTRAN had been implemented by many
different vendors on many different machine architectures.
Clients had this wierd desire to have programs produce the
same result regardless of the underlying machine architecture.
Therefore in 1962 when IBM went to its scientific users group,
SHARE, and in a non-disclosure agreement let them in on its
under development S/360 architecture, it sought their input on
a replacement for FORTRAN IV to be known as FORTRAN VI. It
was there the decision was made to allow the programmer to
specify the precision instead of the implementation. This
resulted in both source and data portability instead of only
source.
Thus the programmer specified not only the base, but its
precision, i.e. the specific subset of values it defined. It was a
lesson learned by the IBM client community, but apparently
lost on K&R who reintroduced the base and precision as
implementation-defined in C and propagated it throughout the
UNIX world, while touting its portability. Unfortunately they
meant only the ease in writing a compiler, allowing source
portability without data. That ease came at the expense of
function which then necessitated the use of third-party
libraries with the incompatibilities associated with their use.
You may see 14/3 as a rational number. Unfortunately it is
data (14, 3) separated by a division operator (/). As such it is
an expression whose evaluation produces a value in some
base-N system. That value, as you have shown, depends on
which base-N system you use. However, in that base-N
system the 14/3 in decimal is not the same 14/3 in base-N. In
fact in a base-3 sytem it doesn't exist at all: it's inexpressible.
It doesn't come into existence until you get to a base-5. (0, 1,
2, 3, 4).
Now APL offers two operators, encode and decode, for
conversions from base-N system to another. The problem in
real life, the kind a programmer has to solve, most frequently
involves expressions with mixed data types. There you have
to have conversions. In an assignment statement the result
has to be expressed in terms of the left-hand side variable.
So to say that in this base-N system a given ratio has a
rational result avoids entirely what must occur when it
involves different base-N systems, fixed or float, decimal or
binary. It's not a clean world as you so carefully explain.
At its core the question becomes who is king, who gets to
make the decision, the programmer or the implementer?
PL/I's authors made a decison in favor of the programmer. C
authors didn't. Python didn't. Pascal didn't. JAVA didn't.
C++, C# didn't. FORTH didn't. LISP didn't. I could add some
1000+ other programming languages that didn't either.
PL/I did. It allows me to express integer values in binary or
decimal, not simply in binary alone. It allows me to express
real numbers, those with fractional portions, in binary and
decimal. I regard that over the last forty years as a real plus.
Greg, you did a great expose on rational numbers. Why don't
you offer the same for transcendental in different base-N
systems? I look forward to it.
=====================================================
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
"postmaster@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 14 |
February |
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.
|