Not quite enough abstraction Brad Lucier (26 Jan 2002 08:10 UTC)
Re: Not quite enough abstraction Jussi Piitulainen (28 Jan 2002 12:21 UTC)
Re: Not quite enough abstraction David Rush (28 Jan 2002 12:39 UTC)
Re: Not quite enough abstraction Jussi Piitulainen (28 Jan 2002 16:01 UTC)
Re: Not quite enough abstraction David Rush (28 Jan 2002 16:51 UTC)
Re: Not quite enough abstraction Jussi Piitulainen (29 Jan 2002 09:05 UTC)
Re: Not quite enough abstraction Noel Welsh (29 Jan 2002 12:31 UTC)

Re: Not quite enough abstraction David Rush 28 Jan 2002 16:49 UTC

Jussi Piitulainen <xxxxxx@ling.helsinki.fi> writes:
> David Rush writes:
> > Jussi Piitulainen writes:
> >> Brad Lucier writes:
> >>> Both assume that there are underlying arrays that are mutable, you
> >>> can set! elements of the arrays, the underlying arrays are generic
> >>> containers (vectors, not f64vectors or f32vectors, ...), etc.
> >
> > I don't see this depth of assumptions. Brad seems to be bringing up
> > two orthogonal issues:
> >
> >         1) mutability
> >         2) type-safety
>
> I thought people want restricted vector types for space efficiency,
> rather than type safety.

Well, it turns out to be the same thing at the end of the
implementation.

> > categorically-standard spec. Err...internal jargon that: I'm looking
> > for a spec that I can plug-n-play alternate implementations for
> > specific problems. e.g. I'm working (low prio) on some large, sparse
> > matrix code for doing latent semantic indexing tricks. My arrays are
> > *not* going to be writable, but I don't care much because I won't be
> > writing to them.
>
> This is definitely interesting. Perhaps it would be better to separate
> index arithmetic from backing vectors entirely? The nature of the
> package would change rather a lot - quite possibly to the better.

I had the impression that we were mostly there right now. Or have you
not added the index-object interfaces in the new revision? I could be
seriously confused at this point.

> Where do your sparse matrices come from if not from something like
> make-array?

Well that's the point: they come from something *like* make-arry, but
not make-array itself. Specifically, in emulating the behaviour of the
SVDPACK library, the array data comes in from a specific file
format. I'll store that in some tree-structure and implement a version
of array-ref which knows how to walk that structure, returning 0 for
empty entries.

The point is that there should be no explicit dependence in the API on
a particular implementation strategy. I don't think that any exists
right now (except possibly using arrays themselves as the index
objects to arrrays).

david rush
--
In no other country in the world is the love of property keener or
more alert than in the United States, and nowhere else does the
majority display less inclination toward doctrines which in any way
threaten the way property is owned.
	-- Democracy in America (Alexis de Tocqueville)