axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Spad and its object model


From: Stephen Wilson
Subject: Re: [Axiom-developer] Spad and its object model
Date: 11 Jun 2007 17:12:15 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Gabriel Dos Reis <address@hidden> 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





reply via email to

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