SCOUG-Programming Mailing List Archives

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

Date:	Tue, 15 Feb 2005 07:00:36 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: Open Source Object Rexx

Content Type: text/plain

Peter, Greg,

Unfortunately my manual spam filtering method wiped out
Greg's last "Balderdash" response. I think I have a handle on
our communications. Peter in his quest or role as devil's
advocate has bounced off more walls than I can reasonable
paint.

You have two branches of mathematics, pure and applied.
The first deals with how people can deal with its theory and
the second with the application of that theory in practice.
Both have a representation in computer software. Some
software, like Mathematica, allows symbol manipulation.

At some point back this began as an issue on data types.
However, even in "pure" or "symbolic" mathematics 14/3 is the
"expression" of a rational number. It is not a data type.

In 14/3 the data type is 14 and 3. The operator type is /. The
combination is an expression. It's an expression in pure
mathematics. It's an expression in applied mathematics. It's
an expression in Mathematica. It's an expression in J.
Nowhere does it ever represent more than the "ratio" with its
implied division of two of two numbers: an expression.

In applied mathematics when you get to actual arithmetic you
have to evaluate an expression in some positional notation
based on some base-N value. By and large only two base-N
notations have been implemented in computer hardware:
binary and decimal.

In both binary and decimal evaluations 14/3, the division of
two integers, produces an integer result of 4. That's the way
it looks in decimal. In binary it looks like ...0100. In binary the
14 looks like ...01110 and 3 like ...00011. In short there's
nothing in binary that looks like 14 or 3. They are
symbolically inexpressible in binary.

If you don't want an integer result, then you must express it
as a "real". In this instance as 14.0 and 3.0. In C and all
programming languages based on 'int' and 'float' the
evaluation occurs in floating point in a implementation-defined
precision. PL/I does it differently. That difference points out
why I prefer PL/I as my base.

In PL/I a decimal constant like 14 is considered as 'fixed dec
(2)' and 3 is 'fixed dec (1)'. 14.0 is 'fixed dec (3,1) and 3.0 is
'fixed dec (2,1)'. In short it does not take on a "float"
attribute. Obviously the evaluation here in PL/I of 4.6 differs
from the floating point of C.

Now if the value 14 or 3 had been expressed in PL/I as
floating point constants instead of decimal the evaluation
would have produce a different result, one similar if not
identical to C.

As wonderful as it is to consider different base-N systems
other than 2 (binary) or 10 (decimal) it does not resolve the
practical matter of expression evaluation of mixed data types
in a positional. Peter may deal with grocers who will sell him
3-1/3 apples or 1-1/2 cans of pears, but basically we do not.
In theory it works. In practice it's an approximation. As such
we would like to be able to specify "how close" on our terms
and not have them dictated to us.

That among other user desires lead Fortran VI to become NPL
(New Programming Language) where a copyright dispute with
Nuclear Physics Laboratories lead to PL/I. Therein the
programmer, not the implementation, dictated the terms of
data types and precision.

Now none of this occurs in a computer without software.
That software exists as one or more programming languages.
Each of those programming languages is a specification
language. None of all this discussion thus far occurs on a
computer without specifications, without it being specified.

It's specification for Mathematica, for J, for PL/I, for Python,
and for C. So why not have a single specification language as
a programming language which is capable of specifying
anything specifiable in any other? That includes using and
evaluating 14/3 in any base-N numbering system.

I regard (and thank) those providing examples of
specifications in different programming languages in different
base-N systems of symbolic and applied forms as further
evidence of its possibilities. They may have some sort of
internal conflict, but not one with me.

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

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

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

Return to [ 15 | February | 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.