RFC: naming for FrontTransversal and Transversal ranges

Bill Baxter wbaxter at gmail.com
Fri May 1 17:09:25 PDT 2009


On Fri, May 1, 2009 at 4:23 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Rainer Deyke wrote:
>>
>> Robert Jacques wrote:
>>>
>>> Precisely, so it's always passed by reference and doesn't need to
>>> support copying.
>>
>> All containers need to support copying.
>
> Speaking of which, I'm thinking of a field like scientific computing (even
> of the simplest, most basic kind that we all dabble into) or applied math.
> People who use for example matrices would NOT expect them to have reference
> semantics. They'd find it very confusing if a = b would not make matrix "a"
> a copy of matrix "b" and so on. (That + no operator overloading = R.I.P. my
> excitement for doing numeric work in Java.)
>
> It would work to ask people who actually use Matrix!double to wrap it in a
> Value!(Matrix!double). But say someone asks, whatever, but if
> Value!(Matrix!double) is a matrix, then what is Matrix? Well, I'd reply,
> Matrix is actually a reference to a matrix. Then, they'll ask, why don't you
> call what you call today "Matrix", RefMatrix or Ref!Matrix or whatever, and
> call a Matrix a matrix? Um, I don't know. That's what the buzz was on the
> newsgroup when we were thinking of it. Some said that's what people coming
> from Java expect.
>
> I guess at that point the would-be D user would be entitled to make me a
> lavaliere out of my Matrix library and move on.

Python, and therefore NumPy, are reference based.
So far I haven't seen any scientists posting on the list about how
having their arrays and matrices be references is driving them crazy.
It may be surprising to some of them at first, but even non-hard-core
coders seem to be able to handle it.   It helps that dummy assignments
like a = b are rare.   More often you have things like a = b + c, and
that creates a new matrix.  Or  a += b, which pretty clearly mutates
a.

Much more often the discussion on the numpy list takes the form of
"how do I make this loop faster" becuase loops are slow in Python so
you have to come up with clever transformations to turn your loop into
array ops.  This is thankfully a problem that D array libs do not
have.  If you think of it as a loop, go ahead and implement it as a
loop.  That's why I prefer to do numerical work in D rather than NumPy
these days.

--bb



More information about the Digitalmars-d mailing list