[swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

Dave Abrahams dabrahams at apple.com
Mon Nov 7 13:27:09 CST 2016

on Sun Nov 06 2016, Hooman Mehr <swift-evolution at swift.org> wrote:

>> On Nov 6, 2016, at 8:03 PM, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>>> I had a brush with Julia <http://julialang.org/ <http://julialang.org/>> as well. Have you
>>> looked at their work 
>> It's been a while, to be honest.
>>> and the recent reworking of their similar data structures?
>> Links would be appreciated.
> Start with this blog post, if you haven’t already seen it:
> http://julialang.org/blog/2016/03/arrays-iteration


* It's interesting that they seem to consider every important data
  structure to be some variety of array.

* “I in eachindex(A)” sounds like “for i in A.indices.”  But, as I
  presume they are traversing integer indices (or tuples thereof)
  that's really inadequate to deal with sparse arrays if you want
  optimal efficiency, since you end up needing to do (at minimum) a
  binary search to access the array elements.

  IMO, the MTL (https://en.wikipedia.org/wiki/Matrix_Template_Library)
  approach is better: use enhanced iterators that only traverse the
  non-zeroes and can report their coordinates in the underlying matrix.

I don't understand everything written in that post as I lack context
from that community, but my overall impression is that the problems
they're dealing with have well-known solutions and they're somewhat
hamstrung by the idea that indices are fundamentally integers (despite
the fact that they do mention the existence of arrays indexed by

I think one of the most interesting related areas that they don't cover
at all is explored in http://lafstern.org/matt/segmented.pdf (related
video: https://meetingcpp.com/index.php/tv15/items/20.html) which among
other things is applicable to ATLAS-style blocking techniques.


More information about the swift-evolution mailing list