From: RG on
In article <hvkl44$gg5$1(a)news.eternal-september.org>,
Tim Bradshaw <tfb(a)tfeb.org> wrote:

> On 2010-06-19 15:42:50 +0100, Tamas K Papp said:
>
> > OTOH, I don't deny the usefulness of the things you mention, I just
> > don't think that they are that useful when one is first introduced to
> > computers.
>
> I think this is a bit like teaching mathematics. If you started off
> teaching people about fields[*] you're going to have a catastrophe
> (tragically, there is quite good data about this sort of thing,
> following the "new mathematics" teaching movement in the 60s and 70s: I
> don't think they started with fields, but they did do a lot of set
> theory and group theory).

There's a lot of data from programming as well. Languages that offer
abstract maps as core constructs (e.g. Python, Javascript, PHP) seem to
get more traction with beginners more than those that don't.

rg
From: RG on
In article <hvkhqe$65o$1(a)news.eternal-september.org>,
Tim Bradshaw <tfb(a)tfeb.org> wrote:

> On 2010-06-20 02:22:56 +0100, Scott L. Burson said:
>
> > Not necessarily. I think what FSet does fits Tim's description,
> > though it may not be exactly what he had in mind. FSet uses binary
> > trees and requires an ordering of elements, but it has a notion of
> > "ordering collision"; when two or more items in the same set collide
> > in the ordering, FSet falls back to putting those items in a list
> > rather than a tree. As long as collisions are relatively rare, the
> > performance impact is small.
>
> That's the kind of thing I was thinking of. It also seems to me that
> systems can probably exploit ordering constraints that they know but
> you can't: for instance an implementation might arrange life so that
> the ordering of addresses of objects does not change, or changes only
> very rarely, thus allowing it to impose a total ordering on things.
> I'd certainly expect systems to implement "hashtables" with
> increasingly sophisticated algorithms as things like locality become
> more important.

You would? Are there any CL implementations that actually do this? Why
does the API expose hash-table parameters but not parameters for any
other kind of underlying implementation? For that matter, why are they
called hash tables if the intent is not for the underlying
implementation to be a hash table? If I want an actual hash table that
is guaranteed to respect the size, rehash-size and rehash-threshold
parameters, do I have to write my own?

rg
From: Tim Bradshaw on
On 2010-06-20 16:41:01 +0100, RG said:
> If I want an actual hash table that
> is guaranteed to respect the size, rehash-size and rehash-threshold
> parameters, do I have to write my own?

You certainly do: "The values of rehash-size and rehash-threshold do
not constrain the implementation to use any particular method for
computing when and by how much the size of hash-table should be
enlarged. Such decisions are implementation-dependent, and these values
only hints from the programmer to the implementation, and the
implementation is permitted to ignore them."

Worth reading the spec before posting, I find.

From: Tim Bradshaw on
On 2010-06-20 16:29:06 +0100, RG said:

> There's a lot of data from programming as well. Languages that offer
> abstract maps as core constructs (e.g. Python, Javascript, PHP) seem to
> get more traction with beginners more than those that don't.

Of course! Now I understand! JavaScript's popularity is due to
*abstract maps*, and nothing at all to do with it being built into
every web browser for the last 12 years. How foolish I have been!

From: Tim Bradshaw on
On 2010-06-20 19:13:04 +0100, Tim Bradshaw said:
>
> Worth reading the spec before posting, I find.

And since I now have a copy of it (sadly, Erik's copy) I'll go and read
that: arguing against Erann is like fighting porridge.