Re: [Axiom-developer] database fixes

[root]

> 1.  The main purpose of the "database" is, as I understand it, to
> enable the loading of mathematical knowledge on an "as needed" basis
> into Axiom rather than carry everything at once in the image?  If i've
> got that right I'm impressed by the power of that design, but I wonder
> how much like a "true" database query-return system Axiom's mechanisms
> are.  1st question:  Would Axiom's internal "database" system be better
> replaced with a "full scale" database backend, or do we do better using
> a scaled down "just what we need" approach?

'database' is a bad name. these are basically external hash tables.
you open the file, read the first number, 'seek' to that location,
and read the key-value table. the entries in the table are not the
actual value (except in some cases) but are byte locations in the file.
when you're working in 64K of memory you have to be a tad clever.
now the design is somewhat pointless.

"back in the day" we learned how to use a DASD (direct access storage
device, now called a disc) so that the seek time, which dominates disk
access time, was minimized. you basically tried for a "bell curve"
centered around the middle of the seek range so the most frequent or
most likely item would be under the head at the center of the travel.
"bell curve hashing" is a dead artform these days. i'd bet you don't
know the DASD fetch numbers for your drives (seek, rotational delay,
head select delay, header/data/trailer delay, device buffer delay,
drive chain select delay, DMA controller delay) :-) ah, the joys of
being old :-)

if i were to do it now i'd either keep the hash tables in the image
or put them in a file and memory map the file. linux probably reads
the whole file into memory when it opens anyway.

t