SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sat, 12 Feb 2005 23:34:21 PST8
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Open Source Object Rexx

Content Type: text/plain

It took me a while to get around to this, but....

On Thu, 10 Feb 2005, Lynn Maxson wrote:
> Greg,
>
> I've fallen asleep during a "Law and Order" segment. My
> significant other wakes me to suggest it's time for bed. I go to
> make my last pass through my messages before blanking my
> screen. Through blurred vision and with considerable effort I
> try to digest your message.
>
> My gosh have I joined the opposition, conveniently reducing
> the ten commandments to nine in eliminating the admonition
> about bearing false witness? Have I overstated the case,
> made excessive claims? Do I now find myself among the
> ranks of this administration, the neo-cons, and the Republican
> Party? How do I do penance? How do I return to moral
> behavior?
>
> Rational and transcendental. However defined they fall into
> the real of "real" or "imaginary" numbers somehow
> expressible as variable precision, fixed decimal form.

No, they don't. I stated in my earlier post that I could live
with variable precision as an approximation for trancendental
numbers. But rational numbers have an EXACT representation that
cannot be expressed by the FLOAT or FIXED attributes in PL/I.
And the arithmetic on rational numbers is exact and constitutes
a field.

> I have
> not offered the incomplete world of "int" and "float", but that
> of fully expressible decimal and binary arithmetic, of "real"
> numbers. Due to the convenience of the APL operator set I
> offer them in any base-x numbering system, allowing "mixed"
> expressions of unlimited variety.

Your world of "dcl f float decimal(247);" and "dcl i fixed binary(142)"
is just as incomplete as the world of "int" and "float". In fact,
I would argue that it is worse in that it leads to the incorrect
impression that it covers the world of "real" numbers. Just because you
have the choice of decimal(some_number) vs. binary(some_other_number)
does not mean that you have captured the essence of approximate
computer arithmetic.

> If you find yourself bound by implementation limits, that's the
> beauty of a self-defining specification language: you can set
> your own limits and extend them at will: self-defining means
> self-extensible. One language. One source. All applications.
> One tool.
>
> So I don't see where any portion of your problem set gets
> excluded. If it is expressible as a "real" number with or
> without a fractional portion, it's included. If a particular
> implementation doesn't satisfy the theory, then you know why
> "int" isn't. But then you're only limited by "your"
> implementation. When you have the power it's kind of hard to
> point elsewhere.

Once upon a time (long, long ago) I took some upper division
abstract algebra courses. I did program a few rational math
routines just for fun while learning about groups, rings, and
fields. But my rational math routines would hardly pass as a
suitable implementation of rational numbers. My preference is
to let better programmers do the job of making a robust library
that I can apply to my problem.

But in this wonderful new world of self-defining specification
languages, we have no need for external libraries. No need to
study any API documents. No need to build on the work of sharp
graduate students and professors developing programming libraries
as part of government funded research.

Now all I have to do is re-program the compiler. So much easier.
So much better. Now where is my dragon book....

Wait a minute. Government funded research is still paying those
graduate students and professors. If I can get a hold of their
modifications to the compiler, then that is just as good as a
library....

"One language. One source. All applications."

OOPS. Make that two languages until the changes to the compiler
made by the graduate students and professors gets merged back into
the open source repository.

OOPS again. What happens when a bunch of other programmers
want something that used to be provided in external libraries?
Now we have N different extended specificaiton languages.
Anyone for an N-way merge? Should we ask Bill Ritcher to give
his next talk about the 3-way merge and how it can be extended
to N-way merges?

> I hope I've gotten the commandments back up to ten.

How about seventeen. We can invent some rational to declare
seventeen a holy number.
--
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".

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

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