axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] database fixes


From: Waldek Hebisch
Subject: Re: [Axiom-developer] database fixes
Date: Tue, 17 Oct 2006 06:01:55 +0200 (CEST)

CY wrote:
> 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?
>

What Axiom calls "database" is sometimes called dictionary, and performs
low level store/retrive operations.  Tim probably knows better why
current implementation was adopted, but I can offer a few speculations.
First, Axiom used to be quite large in comparison with main memories.
So Axiom developers split algebra part into small loadable modules.
Modules contained (compiled) Lisp code, but also needed extra (meta) data
(Axiom types, documentaion info, etc.).  This meta data was stored
in differnt files then Lisp code but was close to it. But meta data
was needed more frequently then code, so as a performance optimization
all meta data was just put in a few files.  To save memory and
avoid reading useless data large part of "database" was read on
demand. 

Axiom "database" is much smaller then classical "enterprise" business
databases.  Also, Axiom basically uses the most primitive queries.
OTOH of top of this "database" Axiom various "reasning" ("type checking")
routines which probably go much beyond of most databases. 

So I think that classical (or even varius experimental) databases
are bad fit for Axiom: Axiom is very demanding in aspect where
databases are likely to be weak and do not need strong parts
of a database. 

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]