float numbers

[chou@mcc.com (Hong-Tai Chou)]

I assure you the log is real.
	
	-------------------------------------------------------
	>(defun foo () 2.0S0)FOO
	>
	(type-of (foo))SHORT-FLOAT
	>
	(compile 'foo)End of Pass 1.  
	End of Pass 2.  
	OPTIMIZE levels: Safety=2, Space=2, Speed=3
	FOO
	>
	>
	(type-of (foo))LONG-FLOAT
	-------------------------------------------------------

	>I wonder if this is a real log.  I agree there is a problem, but
	>as far as I know, the problem occurs only if
	>
  	>1. the float you used is of the sort specified by *read-default-
     	>float-format* at compile time, and
  	>2. you changed the value of *read-default-float-format* before
     	>loading the compiled code.
	>
	>Thus, as long as you always set a same value to *read-default-
	>float-format*, I think you do not need worry about the problem.


The problem is that the KCL compiler always transforms a short float
to a float number with no exponent specifier.
(For example, 2.0S0 is recorded as 2.0 in the data file regardless
of the value *read-default-float-format*.)
At load time, a float number with no exponent specifier is always loaded
as a sinlge float (and hence long float).
Both actions are independent of *read-default-float-format* in the
current implementation of KCL.

To fix the "bug", a float number in the data file generated by 
the compiler should contain the exponent specifier as specified in the 
program. (Using our example, 2.0S0, not 2.0, should be generated in the
data file.) Otherwise, the specifier information is lost after compilation!

To help solve our problem, it would be nice if the loader could consult
*read-default-float-format* instead of always using 'F' as default.
	

Thank you vey much for your attention and efforts.


Hong-Tai Chou, MCC