Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uunet!swlabs!jack
From: jack@swlabs.UUCP (Jack Bonn)
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <259@swlabs.UUCP>
Date: Fri, 26-Jun-87 07:50:24 EDT
Article-I.D.: swlabs.259
Posted: Fri Jun 26 07:50:24 1987
Date-Received: Sat, 27-Jun-87 10:44:53 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>, <293@osupyr.UUCP> <820@mcgill-vision.UUCP>
Organization: Software Labs, Ltd. Easton CT USA
Lines: 25
Summary: Arbitrary base floating point.

In article <820@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes:
> >>> 4.  Allow floating point numbers to be given in hex.  Try putting
> >>> in 2^-32 as a floating point or double constant.  Why should one
> >>> have to risk computer roundoff when it is totally unnecessary?
> 
> There is a problem with both of those: suppose floating-point is not
> stored in a binary format - say it uses floating-point ternary?
> Suppose the machine uses packed decimal?  Suppose you figure out your
> hex constant for your VAX and then have to port to your Sun?  Then to
> your 80x86?  Then to your IBM mainframe?  Then to that packed decimal
> machine I mentioned?  Yech.  Just write 1/65536.0/65536.0 and let the
> compiler figure it out.

Why not just allow 0x0.00000001?  I don't think the suggestion is to 
encode the hexadecimal in the _internal_ format for the machine, just 
to be able to express the constant in a base other that 10.  Certainly,
if the machine was a decimal machine, round-off would still occur.  But
the majority of implementations (are there any decimal-only c's?) would
not encounter it.

But the pressing question is: Must the dot then be referred to as the 
"hexa-decimal point"?  :-)
-- 
Jack Bonn, <> Software Labs, Ltd, Box 451, Easton CT  06612
seismo!uunet!swlabs!jack