> On Aug 1, 2017, at 10:03 AM, Tino Heth via swift-evolution > <swift-evolution@swift.org> wrote: > >> But linear access isn’t an inherent canonical property of multi-dimensional >> arrays, it’s just a consequence of arrays taking a contiguous block of >> memory (which is generally treated as linear in computers). > Do you know about any attempts to change this? I've seen setups of > two-dimensional memory — but only on bit level, and this was mapped into one > dimension... > Todays computers rely heavily on memory being organised in linear fashion, > and I don't think this will change in the near future. > But anyways, that wasn't the canonical order in an array I ways writing about: > Even if we had n-dimensional hardware, there would be little doubt that (0, > 0, 0, 0, 0) is the first element, (0, 0, 0, 0, 1) the second, and that (0, 1, > 0, 0, 0) comes after (0, 0, 1, 0, 0) (endianness left aside ;-) >
It is important to separate the concept of linearity of indices from linearity of physical memory addresses. I think the latter is what Daryle might be alluding to, where there are many physical layout techniques such as tiling which have dramatic performance impact depending on the access pattern. For example, these techniques are extremely important to graphics and image processing (see http://halide-lang.org and http://people.csail.mit.edu/jrk/jrkthesis.pdf). Obviously tuples of natural numbers can be mapped to the natural numbers, the real design decision here is how to expose multi-dimensional indices as a programming model. >> Sequence/Collection have other problems fitting with fixed-size arrays. >> There needs to be a new set of more basic protocols that both arrays and >> Sequence or Collection can conform to. > What exactly is the problem with Sequence that makes you believe there is > need for a more basic protocol? > >> Or to flip it, just use multi-dimensional arrays with one bound. >> Multi-dimensionality does not impose an implementation penalty > I'd call the (imho extremely) increased complexity and loosing conformance to > Collection a heave penalty… actually, it would strip arrays of their biggest > unique feature compared to tuples. > And after all, all arrays have to be mapped to a single dimension, so I don't > see the ability to define an array with ten dimensions on the fly as a big > win (because it's rather easy to derive such a type from a one-dimensional > array). > >> Wrapping multi-dimensionality in a type would forfeit it being a compound >> type, which would forfeit piecemeal initialization. > [Basic question: What definition of compound type are you referring to?] > Why would there be a fundamental difference in initialisation between an > array, and an object that holds an array and maps to its contents? > [ah, I think I got that point: It's not about leaving parts uninitialised and > taking care of them later, but the ability to use literals like > [[[0, 0, 1], [0, 1, 0]], [0, 0, 2], [0, 2, 0]]] > right?] > > - Tino > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
