This page is part of the web mail archives of SRFI 25 from before July 7th, 2015. The new archives for SRFI 25 contain all messages, not just those from before July 7th, 2015.
Jussi Piitulainen <jpiitula@xxxxxxxxxxxxxxxx> 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)