Re: small integers

[dyer@eagle.sharebase.com (Scot Dyer)]

jim@fpr.com (James E. O'Dell), Re: small integers:
/// On Wed, 14 Oct 92, moon@cambridge.apple.com (David A. Moon) wrote:
/// >> Date: Tue, 13 Oct 1992 22:33:27 -4
/// >> From: jim@fpr.com (James E. O'Dell)
/// >>
/// >> ...garbled line-wrapped message elided...
/// >
/// >When I said "often" I meant that the compiler can often optimize the code,
/// not
/// >that the code would often return the correct answer.  The infrequent case
/// >would be slightly slower code that has to do an overflow check, not code
/// that
/// >returns the wrong answer!

Narrowing the concern for notification of corruption of data to numerics may
be creating tunnel-vision, here.  Many different types (classes) can be
verified at run-time, to the great benefit of the developer.

I would like to see some form of contractual programming implemented in Dylan.
This way, when I declare my <SSN> class, I can state that it will contain
ten digits, etc., and at least during prototyping I can compile programs that
automagically check this assertion about what data should be placed in these
structures.

If this were the case, only one additional built-in class would be required
for this numeric problem: <fixnum-only> -- which has a contract specifying it
may never contain a <bignum>...

/// Yeah, thats what I thought you meant. I still think you need a mode
/// that compiles arithmetic with complete disregard for correctness. Real
/// numerical types never trust a single calculation anyway. There are too
/// many other ways to get numerical instabilities in a complicated
/// numerical program. To check a single op for corrrectness in a large
/// code may be seen by many as penny wise and pound foolish.

Having some kind of pragma to toggle run-time value verification is probably
a good idea, at least for production versions of your executable.  This
"contract checking" should be able to be turned off easily, and best if this
is do-able in the invocation of the compiler -- but that might suggest some
need for a notation for conditional compilation, a mechanism which Dylan lacks.

Don't get me wrong on that, though.  Conditional compilation is dangerous to
include in a language.  Not only will it be used to write unreadable (ergo:
unmaintainable) code, but it will permit destandardization of the core
language.

What I'm suggesting is some very limited types of conditional compilation, like
with 'contract checking enabled' and 'contract checking disabled'.

/// Many complicated codes are checked for correctness by varying input
/// values
/// slightly to see if the results are stable. Another method of doing a
/// sensitivity analysis is performing the same calculation in both single
/// and double precision and checking the results for stability.

For a language like FORTRAN, whose compiler writers live to optimize floating
point operations, this is feasible.  For Dylan, it probably isn't.  No
[mainstream] language is as fast as FORTRAN when it comes to number-crunching,
because FORTRAN compilers have always had _very_ good optimizers.  This is
good for a number-crunching language like FORTRAN, but would remove the focus
of Dylan (OOD Programming) from the compiler.

/// I don't believe Seymour Cray built his machines the way he did because
/// he liked getting incorrect answers.

I don't either.  On the other hand, debugging wrong algorithms may not have
been as important in design as getting answers from already working ones.  When
machine-time is more expensive than programmer-time this is an option one has.

/// Jim

	-- Scot

+------------------------+-----------------------------------------------+
|Scot Dyer_Rivenburgh    | "Land of song," said the warrior bard,	 |
|dyer@eagle.sharebase.com| "Though all the world betrays thee,		 |
+------------------------+  One sword, at least, thy rights shall guard, |
|(He's right, you know.) |  One faithful harp shall praise thee."	 |
+------------------------+-----------------------------------------------+

P.S.:

	Contract checking suggestions:
	1. Contract method on some class called for class modification.
	   Contract should be included in class (this is great documentation)
	   declaration.  Toggle by class when compiling production images.
	2. Contract clause in methods for result.  Also great documentation.
	3. Explicit in-line contracts are important, too.  Such as
		(must-be <fix-num> (* x y (+ z a)))
		;;; (contract (method (x) (type? x <fix-num>))
		;;;	(* x y (+ z a)))