[Top][All Lists]
[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
Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model,
Stephen Wilson <=
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/11
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/12
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/12
- Re: [Axiom-developer] Spad and its object model, Gabriel Dos Reis, 2007/06/12
- Re: [Axiom-developer] Spad and its object model, Stephen Wilson, 2007/06/12
Re: [Axiom-developer] Spad and its object model, Waldek Hebisch, 2007/06/11