Reorganization of linalg.jl in separate files

[carlobaldassi]

This follows this discussion. Everything seems to be functional (all tests pass), and I also started adding some more sparse functions, so it could be merged already if it looks fine. Of course it's very preliminary (e.g. the interface in linalg is mostly "specified" by commented function prototypes, but that's supposed to change with time, and anyway it's no worse than current situation).

(Some very minor points still need fixing/settling, I left commented XXX's as placeholders to remind where the problematic parts are.)

[ViralBShah]

Browsing through the diff, looks ok. Leaving it around for a bit longer for others to take a look, before merging.

[JeffBezanson]

Basically good. I would only make a couple changes, for the cases where code can literally be copied and pasted with just the signature changed from Matrix to BitMatrix, such as norm. Anything like that should be defined for AbstractMatrix.

I can go in and insert another type above Array. DenseArray is actually not quite right since a DArray is also dense. Maybe UniformArray?

[pao]

"Uniform" in terms of memory access? I'm not sure that's obvious (I had to think about it for a minute, and I might still be wrong.) But it's not a strong objection.

[ViralBShah]

What does Uniform mean? Not sure I like that name.

-viral

On 22-Apr-2012, at 4:12 AM, JeffBezansonreply@reply.github.com wrote:

Basically good. I would only make a couple changes, for the cases where code can literally be copied and pasted with just the signature changed from Matrix to BitMatrix, such as norm. Anything like that should be defined for AbstractMatrix.

I can go in and insert another type above Array. DenseArray is actually not quite right since a DArray is also dense. Maybe UniformArray?

---

Reply to this email directly or view it on GitHub:
#750 (comment)

[JeffBezanson]

Well there are two main issues: density, and uniformity of access time. DArray is dense, but has wildly nonuniform access time. Sparse is sparse, but has fairly uniform access time (at least compared to DArray). What we want is a type that captures "arrays that work with the definitions carlo had to copy and paste into bitarray.jl".

[ViralBShah]

How about UTArray, for Uniform time access array. We could use a better name if we come up with it later. Is this the only reason this merge request is held? Should this refactoring be done before this pull request is merged?

[JeffBezanson]

No, we don't have to do the UTArray change for this particular pull request.
Just see my previous comment about adding back the Abstract in cases where code was duplicated by this patch.

[carlobaldassi]

I have removed duplicated code. BitArrays will have those functions again when there will be the intermediate level between AbstractArray and Array, so I think this could be merged now.

Speaking of the intermediate level name: what about ContiguousArray? It seems to express both density and locality, doesn't it?

Also, while I'm at it: what about making StridedArray a part of the arrays hierarchy as well, rather than a Union?

AbstractArray
ContiguousArray <: AbstractArray  # or UTArray or whatever
StridedArray <: ContiguousArray
Array <: StridedArray
SubArray <: StridedArray
BitArray <: ContiguousArray

(At some point I was thinking about BitArray <: StridedArray but it doesn't seem to fit really.)

[ViralBShah]

Isn't even SparseMatrixCSC Contiguous? It is better than UniformArray, but still not good enough, IMO. How about UniformAccessArray?

I like the hierarchy.

-viral

On 23-Apr-2012, at 3:39 PM, Carlo Baldassi wrote:

I have removed duplicated code. BitArrays will have those functions again when there will be the intermediate level between AbstractArray and Array, so I think this could be merged now.

Speaking of the intermediate level name: what about ContiguousArray? It seems to express both density and locality, doesn't it?

Also, while I'm at it: what about making StridedArray a part of the arrays hierarchy as well, rather than a Union?

AbstractArray
ContiguousArray <: AbstractArray  # or UTArray or whatever
StridedArray <: ContiguousArray
Array <: StridedArray
SubArray <: StridedArray
BitArray <: ContiguousArray

(At some point I was thinking about BitArray <: StridedArray but it doesn't seem to fit really.)

---

Reply to this email directly or view it on GitHub:
#750 (comment)

[carlobaldassi]

I was intending "contiguous" in the sense of strides-aware-contiguous mapping from indices to memory. But yes, it seems UniformAccess may be better, and more abstract.

[StefanKarpinski]

It seems to me that the right definition of contiguous might just be "dense" — i.e. stores all values rather than having defaults where no value is actually stored.