Hi Steven,

> > Hello marmorine,
> Ummm... Steven. ;)

Oops! Sorry :)


> Tried all sorts of size combinations, found one that is more compact, to
> use (0 +Wrds) instead of the block size 1 for it. But then I guess you
> should take a look with "size" to make sure you are not cutting things
> to close? 

No reason to worry. If space conservation is important, I would go with
dbs 0, meaning a block size of 64 bytes. Each block has a 6-byte link
field in the beginning, so that you have a net capacity of 58 bytes per
block.

If a word list gets longer than that, the DB simply allocates one or
more additional blocks for that object, so you will never hit a limit.
Just access times will slow down a little.


> What I am doing is to translate more or less 1:1 a little Python
> program of mine into picolisp, because it uses scheduled learning, and
> then set up an index in my database only for those data fields where I
> had presets for queries, and this is what comes out (and then
> add updates and a gui to it in due time):
> 
>    (class +Wrds +Entity)
>    (rel wrd (+Key +List +String))
> ...
> I had (rel wrd (+Ref +List +String)) before and that didn't work,

In fact, I never used (+Ref +List +String), always found it not useful.
I would expect the same for (+Key +List +String). Because you can always
store the whole string instead - without splitting it into a list - in a
(+Key +String) or (+Ref +String), right?

What turned out more useful is (+List +Ref +String), i.e. indexing the
individual words, or, more typical, (+List +Fold +Ref +String).

In all (+List +String) cases it is a bit tedious to handle these data in
the GUI. Note that you can use +ListTextField to map a single text field
to a list of strings.


> Do I have to initialize data by the way, or will things default to
> standard values, or just "not be there" until used?

Right. Search and access functions return NIL if no data are found.

> And I take it you
> only list the indexes you are pushing off into another file, otherwise
> they default to being in the first file?

Exactly. But this may not be a good idea if the first file has a rather
small block size, because the B-Tree nodes are only happy if they have
enough space to store several key-value pairs. As opposed to entity
objects (which may occupy more than one block, see above), a node splits
into two if it needs more space. So you end up with many (perhaps too
small) nodes.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to