suggestions on floating point numbers and hash tables

[HEDRICK at RUTGERS (Mgr DEC-20s/Dir LCSR Comp Facility)]

We have just finished most of the code needed to support Common Lisp
numbers, and are working on hash tables.  In the process, we have
noticed a few things:

When you see 1.0, it is hard to know what the precision is. We would
like to make sure that if you write something out and read it back in,
it is EQUAL to what you started with.  Thus you should consider doing
one of the following:

  - adopt a convention where you can tell the precision based on the
	number of digits printed.  E.g. 1.00000 would be single, but
	1.000000000000000 would be double.  If you follow such a
	convention in both READ and PRINT, it should be possible to
	preserve the type.  (This would replace the
	READ-DEFAULT-FLOAT-FORMAT flag.) This has the advantage of being
	to some extent machine-independent, in that 1.0000 might be
	single-precision on the VAX and short on the DEC-20.

  - always print an exponent marker, or maybe always print it when the
	it is not the same as READ-DEFAULT-FLOAT-FORMAT.

(At the moment, we are always supplying an exponent marker when it is
different from the default.)

We do not notice any way to write out hash tables.  We suggest that you
adopt a # syntax for that.  In my opinion, it should be possible to
write out and read back in as many kinds of user data structures as is
possible.

You specify a default packing factor of .8 for hash tables. I wonder
whether you really want this number to be defined in the manual. It
seems to me that the best packing factor may well be
implementation-dependent, because it will depend upon the way the
implementors have taken certain space-time tradeoffs. For various
reasons we are looking at using a algorithm where resolving clashes will
be fairly expensive.  Thus we intend to use a much lower default packing
factor.  (The method involved would use less storage space per item, so
we could afford the larger tables implied.)  

Finally, we wonder whether having separate MAKE-xxx-HASH-TABLE functions
but the same PUT-HASH and GET-HASH for all types is the right way to go.
At least in our implementation, the structure of all hash tables is
identical.  What is different among the tables is how you compare
entries.  We think it would make more sense to have one MAKE-HASH-TABLE
and separate access functions.  Since the user supplies to hash table
type when he creates it, we just have to save it somewhere in the table,
and then use it behind his back to change the meaning of the access
functions.  Although I don't quite know how one would use it, in
principle it would make sense to put different kinds of items into the
same hash table using different functions, something that is ruled out
by your proposal.  Also, if there were only one kind of hash table, it
would be slightly easier to PRINT and READ them.

-------