[comp.arch] Numbers

chris@mimsy.UUCP (Chris Torek) (05/16/88)

>In article <11618@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>>Unfortunatly I have found no simple way to get the star to cooperate with
>>respect to counting rates.  Sometimes 16 bits are enough, sometimes 32
>>aren't, depending on the the star's brightness and the rapidity with which
>>it varies.

In article <493@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O) writes:
>This is a perfect example of why we need higher-level languages
>like lisp.  ... [On] overflow ... lisp just converts the representation
>to Bignum, and works with it instead -- you may never even be aware
>that the conversion has occurred.

Lisp is not the only such language, but it does illustrate a certain
point.  (This point is perhaps stronger with Jack Bonn's glass-slinging
machine than with Ed Nather's photon counter.)  Imagine the lisp
system, counting away:

	4 294 967 294
	4 294 967 925
	Entering GC; please wait.  Estimated delay: 7.24s
	<numerous photons missed>

One problem with higher-level langauges is that they may wrest too
much control.  While there are those with incremental GC, and even
some with no GC (although some say `those don't count' :-) ), many
of them are not suited for real-time applications.

>Yes, we need languages that are close to hardware ...
[this left in for balance]

>(NOTE: in lisp you actually get the best of both worlds. You can
>fully specify types if you choose, to get faster-running code.)

But if you specify the type as `integer' you are back to the problem
you had with C.  You get to decide to which error to commit, but you
do not get to overcome both.  It may, of course, not be possible to
overcome both with a given machine....
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

billo@cmx.npac.syr.edu (Bill O) (05/18/88)

In article <11512@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <11618@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>>>Unfortunately I have found no simple way to get the star to cooperate with
>In article <493@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O) writes:
>>This is a perfect example of why we need higher-level languages
>>like lisp.  ... [On] overflow ... lisp just converts the representation
>	4 294 967 294
>	4 294 967 925
>	Entering GC; please wait.  Estimated delay: 7.24s
>	<numerous photons missed>
>One problem with higher-level languages is that they...
>...are not suited for real-time applications.

OK, I wasn't thinking of real-time control, and I should
have been because the photon counter was probably a
real-time application.  However, my comments do apply to
any application which is not real-time (dare I say, the
majority of applications :-)). As I said before, we still
need languages that are close to the machine, and
real-time control is one reason. But surely that
shouldn't saddle the rest of us.  And please, no GC
bashing. Non incremental GC was invented when Lisp was
done in batch. Now-a-days we have ephemeral and
incremental GC for interactive applications (but NOT
real-time).

Bill O'Farrell, Northeast Parallel Architectures Center at Syracuse University
(billo@cmx.npac.syr.edu)Newsgroups: comp.arch

lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) (09/24/89)

>In article <136@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>..some of us need to have 100 pennies == 1 dollar.  Interest calculations
>carried out to 3 or 4 decimal places need to round correctly.

Well, it is possible to have decimal floating point. I myself
perpetrated a BCD floating-point package, back in the eight-bit days.

The military world has always been fond of putting decimal points in
the middle of binary integers, and calling it "fixed point". The
worst language I have ever used, the navy's CMS-2M, featured this
data type. The spec for Ada required it, so now Ada allows you to say

	type VOLT is delta 0.125;

This actually runs fine on normal machines, because it is the
compiler that maintains the scaling (in this case, by three bits).
The real problem is that the roundoff will be in eighths of a volt
(or 256ths of a penny, or 1024ths of a nautical mile, or whatever).
Also, the conversions are bad:

	voltage := 0.3;		-- choice is ,,0.25, 0.375,,,

In general, people would be better off if they could say something
like
	type MILLVOLT is integer;
	type VOLT is MILLIVOLT * 1000;

Normal floating point has a dynamic range of 10**76 (or whatever).  A
32 bit integer only has a range of 10**9, but IBM takes in more than
10**13 pennies per year. So, a 64 bit integer (10**19) is about right
when you want to compute in millicents, and this is what I recommend.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science

pardo@cs.washington.edu (David Keppel) (09/24/89)

lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
>[Ada lets you say "type VOLT is delta 0.125"]
>[The problem is roundoff will be eighths of a volt.]
>[Conversions are bad: "volatage := 0.3" -- choose: 0.2 or 0.375]

I AMP SHOCKED by your REVOLTING example :-)

I believe that the Ada spec requires that the increments be at least
as fine as `delta', but that they can be finer if the compiler wants.
(If I'm wrong, assume that I have a language `adA' that does allow the
compiler to choose finer deltas.) Thus, if you have Ada on a machine
which does only decimal arithmetic operations (your average pocket
caluculator :-), then the implementation delta can be 0.1 units.
Given floats with sufficient range, it could even use floats.

This example points in a mostly uncharted direction for programming
languages: an assertion that something must be minimally true vs. an
assertion that something must be exactly true.

The `semantics' of Ada's delta are approximately

	type VOLT is delta 0.125;
	-- pragma require VOLT.delta <= 0.125

If you actually need a delta of 0.125, then you need to make a
stronger assertion.

	type VOLT is delta 0.125;
	-- pragma require VOLT.delta = 0.125

If I'm writing joe code that I want to run fast and some margin for
error is acceptable, then I'll probably write the above, even if all
that I want is resolution of 0.2 units.  Ideally, I should be able to
tell the compiler ``this is what I need, and here's a hint on how to
do it.''

	type VOLT is delta 0.2;
	-- pragma hint VOLT.delta = 0.125

Similarly, if you are troubled by conversions, you could hint that the
compiler should choose a finer delta

	type VOLT is delta 0.125;
	-- pragma hint VOLT.delta <= 1.0

No, no Ada compiler is required to let you do any of this.

Followups to comp.lang.misc.

	;-D on  ( Fixed pointless arithmetic )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo

malcolm@Apple.COM (Malcolm Slaney) (09/25/89)

Donald Lindsay writes:
>The military world has always been fond of putting decimal points in
>the middle of binary integers, and calling it "fixed point". 
There is a good reason for doing this....in many signal processing algorithms 
it makes much better use of the available silicon.  It's just that the military
has lots of money for optimizing performance this way.

Military machines aren't the only users of this "hack."  The MSSP machine
designed by Richard Lyon while he was a Schlumberger is a SIMD bit-serial 
signal processing machine that was designed to do lots of arithmetic in a 
hurry.  The only arithmetic format supported on the machine was a 32 bit 
fixed point number that had three binary bits to the left of the decimal point 
(maximum range +/- 8.)  Most signal processing algorithms normalize their 
numbers so they use all the bits.  Then filters are designed to keep the 
numbers at about the same magnitude so that overflow isn't a problem.

>In general, people would be better off if they could say something
>like
>	type MILLVOLT is integer;
>	type VOLT is MILLIVOLT * 1000;
(Don't you mean MILLIVOLT/1000?)
The solution isn't this simple.  Most people don't multiply millivolts but
if you simply treated them as integers, as in this case, the decimal point
would be in the wrong place.  The advantage of doing this in hardware is that
the shift comes for free.

I would never dream of trying to convince somebody like MIPs to incorporate
fixed point arithmetic into their general purpose machines, but for many
dedicated signal processing processors this is the best way to go.  I don't
know how to incorporate this type of number into a programming language but I 
have to give the ADA designers at least credit for trying.

					Malcolm 
					Apple Speach and Hearing Project
P.S.  Neural modelling is another good application area for fixed point
arithmetic.  Most studies I've seen only show 8 bits of dynamic range in
the average firing rate of a neuron.  If you, instead, consider a simulation
at a lower level then all you need is a one bit variable since the information
is carried in the timing.

vestal@SRC.Honeywell.COM (Steve Vestal) (09/25/89)

>            type MILLVOLT is integer;
>            type VOLT is MILLIVOLT * 1000;
Perhaps
             type VOLT is delta 0.001 range {whatever};
             for VOLT'SMALL use 0.001;
will do what you want (MIL-STD-1815A 3.5.9 para 5, 13.2 (d)).

cik@l.cc.purdue.edu (Herman Rubin) (09/25/89)

In article <34993@apple.Apple.COM>, malcolm@Apple.COM (Malcolm Slaney) writes:
> Donald Lindsay writes:
> >The military world has always been fond of putting decimal points in
> >the middle of binary integers, and calling it "fixed point". 

			..............................

> I would never dream of trying to convince somebody like MIPs to incorporate
> fixed point arithmetic into their general purpose machines, but for many
> dedicated signal processing processors this is the best way to go.  I don't
> know how to incorporate this type of number into a programming language but I 
> have to give the ADA designers at least credit for trying.

There are a very large number of situations in which it is necessary to
use fixed point, including multiple-precision floating point beyond what
is explicitly provided for.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)

roy@phri.UUCP (Roy Smith) (09/26/89)

Donald Lindsay writes:
> The military world has always been fond of putting decimal points in
> the middle of binary integers, and calling it "fixed point". 

	Not just the military world.  On the the biggest consumers of CPU
cycles around here is a program which calculates rna secondary structures
by an energy minimization process.  All in integer math, using as the base
unit 0.1Kcal.  Virtually the only floating point in the program is a
floating divide by 10.0 at the end to print the result in a form more
familiar to human readers.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"