title: Stealing bits from an IEEE 754 double
body: <p>What are the effects on floating-point math likely to be if the least-significant bit(s) of the significand is(/are) set to a random value?</p>
  
  <p>Explanation:</p>
  
  <p>The language <a href="http://www.software-lab.de/doc/ref.html#cell" rel="noreferrer">PicoLisp</a> allocates <em>all</em> values using one structure, the cell, which consists of two "machine words". On a 32-bit system, this means a cell is an eight-byte structure of two 32-bit pointers or integers. Cells are aligned to their size, which means that at least the lowest three bits of a word are free to be used as type and GC tag data.</p>
  
  <p>PicoLisp is very minimalist. One of the (many) things the language lacks is any support whatsoever for floating-point numbers, instead relying entirely on what the documentation calls "scaled fixpoint" representation. I thought it would be fun to try to add floating point support.</p>
  
  <p>On 32-bit systems a 64-bit float will fit neatly inside one cell, conveniently meaning the allocation system can be pretty much the same, except for one minor problem: all 64 bits will be used by the double. But the GC expects to use bit 0 as a GC mark bit. Proceeding naively, bit 0 will be set to zero after every collection cycle regardless of what value was actually stored in the double.</p>
  
  <p>(This is assuming the sizes and endianness all line up correctly. Assume for the purposes of this that they do; if they don't then the entire question is completely irrelevant and a different strategy necessarily has to be used.)</p>
  
  <p>So: how much of a problem is this for general-purpose math, using the hardware float operations?</p>
  
  <p>If all it does is reduce the precision of the double a tiny amount, then I figure that's not actually a problem: <em>as long as</em> it is documented that floating-point math in the interpreter isn't as precise as the user expects and they should fall back to fixpoint or a library or something if they need strictly accurate behaviour. My intuitive understanding of it is that this ought to be the case, since it's the least significant bit (doesn't even show up when you convert to a string..?).</p>
  
  <p>On the other hand, floating point is, uh, witchcraft. Could this sort of bit-fiddling actually severely affect the usefulness of math or the ability to produce <em>any</em> kind of consistent results?</p>
  
  <p>(I have considered several other implementation possibilities for the allocator. I'm specifically interested in whether <em>this</em> strategy is monumentally stupid or not, because it's the easiest and I am lazy.)</p>