> 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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
