Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

> On Mon, 11 Jun 2007, Stephen Wilson wrote:
> 
> | > I guess what I trying to get at is what are the benefits of those 
> | > additional indirections over simple, hash table representation.
> | 
> | I would imagine that the vast number of lookups would suffice with an
> | integer index.  Tiny fraction would require higher level keys. 
> 
> Lookup with integer index is OK when you have all information at the
> same place and at the same time and have a way to enforce its
> semantics.  Currently, Spad is such that one needs to have all
> the information when constructing the vtable but there is no means
> to enforce consistency.  Going to a world with "extend" makes
> the problem even more accute.

If the vtable can be interrogated with a variety of keys, allowing
useful mapping of elements, I dont see how a hash is any more
flexible.  Perhaps you could provide an example?

> | 
> | > >From all I can see, the "index" key relies on order declaration which is 
> a
> | > non-started.  The scheme "name" key is essentiablly equivalent to using a 
> hash
> | > table.  If an extrat indirection is required to get the type, what is he
> | > point?  
> | 
> | This indirection could certainly be made fast, probably on par with a
> | hash.
> 
> How would that be faster than the scheme that uses only one lookup?

I didnt say faster, I said on par.  Either scheme is O(1), and the
constant difference would be small.

I suspect the difference in lookup time would become noticable only
when everything that can be accomplished using a simple integer index
is replaced by a hash lookup.
 
> | I dont think of the integer index as having anything to do with the
> | order of declarations.
> 
> Please elaborate on its semantics then.

Nothing fancy. Its just a key, no more, no less.

[...]

I belive for this dicussion to be productive some prototype
implementation would be useful as the focus now seems to be
on efficiency.

Unless you have already explored this alternative, I can write a few
functions which exploit the current vtable structure to provide some
of the mappings which you require.  I hope to clarify my own rusty
comprehension of their layout in the process.  Perhaps then we could
look at the issues involved in more detail.

Thanks,
Steve



_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer

Reply via email to