On 12/29/21 1:31 PM, Terje Mathisen wrote:
> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> memory was more or less the same speed as CPU, and multiplications were
> much more expensive.
>
> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]

Exactly! This is why "industrial strength" languages should
support them and they don't have to turn into an APL!

Though the descriptor would need to be somewhat more general
as you may pass a subsrray A[x1..x2; y1..y2] to a function
etc.

On Wednesday, December 29, 2021 at 7:32:30 PM UTC-6, Bakul Shah wrote:
> On 12/29/21 1:36 AM, David Brown wrote:
> > On 29/12/2021 10:02, Bakul Shah wrote:
> >> On 12/29/21 12:39 AM, David Brown wrote:
> >>> Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
> >>> That's the way it works in many languages that support them well.
> >>> Unfortunately, C (and therefore C++) have the "comma operator", so that
> >>> expression already has a meaning - evaluate "x" for its side-effects
> >>> then throw it away, evaluate "y" for its side-effects, then you are left
> >>> with "A[z]".
> >>
> >> This could've been trivially fixed by using ';' instead of
> >> ','. Since ';' is illegal in the [] context, this would
> >> have not been a breaking change.
> >>
> >
> > I think that would have been /far/ from trivial. Suddenly you now have
> > two different ways of separating parameters in the language, which would
> Array indices are not the same as function parameters.
> Given that C screwed up by misusing , as an operator,
> and given that C has no generics, there is no other
> choice but to use a different symbol *if* one wanted
> to add multi dim. arrays to C. The syntax part is indeed
> trivially solved but to make multi dim arrays fully
> useful you need the ability to create arrays, reference
> subarrays and pass them as args. etc and that is not
> trivial.
<
Sure it is, you (the programmer) create dope vectors containing
the pointer, the lower and upper index, and the stride between
containers. Compilers in languages that actually support arrays
do this easily, and in C it is straightforward for the programmer
to create these Dope Vectors.
<
> I believe it is indeed possible to add
> full fledged multi-dim. array support to C in a fully
> backward compatible way. Though am not holding my breath.
> (and I have close to 0 interest in what C++ does. I used
> it for 20+ years. That was a long enough sentence!]
<
Congratulations on your release. Did you get a commutation or
a pardon ?

On Wednesday, December 29, 2021 at 7:42:07 PM UTC-6, Bakul Shah wrote:
> On 12/29/21 1:31 PM, Terje Mathisen wrote:
> > Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> > memory was more or less the same speed as CPU, and multiplications were
> > much more expensive.
> >
> > Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
> Exactly! This is why "industrial strength" languages should
> support them and they don't have to turn into an APL!
>
> Though the descriptor would need to be somewhat more general
> as you may pass a subsrray A[x1..x2; y1..y2] to a function
> etc.
<
I remember MARY 2 (circa 1981) where one could create triangular
multidimensional arrays using the <ahem> macro facility. This far
surpasses the multidimensional arrays or FORTRAN and like languages.

On 12/29/21 7:22 PM, MitchAlsup wrote:
> On Wednesday, December 29, 2021 at 7:42:07 PM UTC-6, Bakul Shah wrote:
>> On 12/29/21 1:31 PM, Terje Mathisen wrote:
>>> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
>>> memory was more or less the same speed as CPU, and multiplications were
>>> much more expensive.
>>>
>>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>> Exactly! This is why "industrial strength" languages should
>> support them and they don't have to turn into an APL!
>>
>> Though the descriptor would need to be somewhat more general
>> as you may pass a subsrray A[x1..x2; y1..y2] to a function
>> etc.
> <
> I remember MARY 2 (circa 1981) where one could create triangular
> multidimensional arrays using the <ahem> macro facility. This far
> surpasses the multidimensional arrays or FORTRAN and like languages.

Perhaps Ivan can expand on that. I knew of Mary1 and Mary2 but
never used them.

The macro facility would be useful for creating an array with a
compact lexical expression, but what was its representation at
run time?

Even Fortran style arrays would be quite useful.

Bakul Shah <bakul@iitbombay.org> schrieb:
> On 12/29/21 1:31 PM, Terje Mathisen wrote:
>> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
>> memory was more or less the same speed as CPU, and multiplications were
>> much more expensive.
>>
>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>
> Exactly! This is why "industrial strength" languages should
> support them and they don't have to turn into an APL!
>
> Though the descriptor would need to be somewhat more general
> as you may pass a subsrray A[x1..x2; y1..y2] to a function
> etc.

https://j3-fortran.org/doc/year/18/18-007r1.pdf contains a
specification in section 18.5 in C of such a facility.

Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Wednesday, December 29, 2021 at 3:31:16 PM UTC-6, Terje Mathisen wrote:
>>> David Brown wrote:
>>>> On 29/12/2021 11:46, robf...@gmail.com wrote:
>>>>> Huh? C does not support multi-dimensional arrays? I did not realize that. Not realizing
>>>>> that, it is supported in my cc64 language. I do not see why [ ][ ][ ] cannot be used in
>>>>> place of commas.
>>>>> In cc64 multi-dimensional arrays are supported with the indexing operator[].
>>>>> Accessing a multi-dimensional array is just A[x][y][z] which is the same as A[x,y,z].
>>>>>
>>>>
>>>> Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
>>>> arrays. But that is not /quite/ the same as a multi-dimensional array.
>>>> And C arrays have slightly unusual semantics - array expressions decay
>>>> into pointer expressions in most circumstances. Often, you can write
>>>> simple and clear code with multi-dimensional arrays. But for some
>>>> use-cases, you need quite complicated expressions and a lot of care to
>>>> get the sizes write.
>>>>
>>> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
>>> memory was more or less the same speed as CPU, and multiplications were
>>> much more expensive.
>>>
>>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>>> than to effectively do
>>>
>>> t1 = arr[z]
>>> t2 = t1[y]
>>> w = t2[x]
>>>
>>> where t1[] is an array of pointers to pointers to arrays, and t2[] is
>>> an array of pointers to arrays.
>>>
>>> Lifting stuff out of the inner loops can often alleviate the costs of
>>> both of these, but integer mul is far to be preferred to random memory
>>> access.
>> <
>> Then strength-reduction converts MULs within a loop back into ADDs.
>
> ... which was a feature of the very first FORTRAN compiler, already.
>
Yeah, we all know that.

What I tried to say, having learned this from Andy Glew, is that even in
the case where arr[x,y,z] is a single, effectively random, access, it is
now better to use MUL than double or triple indirect memory lookups.

Pipelining allows all of those MULs to overlap, so the cost for doing
3D/4D/etc access rises very slowly.

Andy's advice was to "consider all internal cpu opcodes to be free, you
only need to care about the cost of the load/store ops". This was in the
PPro time frame, so ~25 years ago.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 12/29/2021 7:22 PM, MitchAlsup wrote:
> On Wednesday, December 29, 2021 at 7:42:07 PM UTC-6, Bakul Shah wrote:
>> On 12/29/21 1:31 PM, Terje Mathisen wrote:
>>> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
>>> memory was more or less the same speed as CPU, and multiplications were
>>> much more expensive.
>>>
>>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>> Exactly! This is why "industrial strength" languages should
>> support them and they don't have to turn into an APL!
>>
>> Though the descriptor would need to be somewhat more general
>> as you may pass a subsrray A[x1..x2; y1..y2] to a function
>> etc.
> <
> I remember MARY 2 (circa 1981) where one could create triangular
> multidimensional arrays using the <ahem> macro facility. This far
> surpasses the multidimensional arrays or FORTRAN and like languages.

Predated by (revised) Algol68. Referty rowsety rowwsety rowslice!

Bakul Shah wrote:
> On 12/29/21 1:31 PM, Terje Mathisen wrote:
>> Multi-dim arrays using Iliffe vectors used to be a good idea, back
>> when memory was more or less the same speed as CPU, and
>> multiplications were much more expensive.
>>
>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>
> Exactly! This is why "industrial strength" languages should
> support them and they don't have to turn into an APL!
>
> Though the descriptor would need to be somewhat more general
> as you may pass a subsrray A[x1..x2; y1..y2] to a function
> etc.

Sure, which is why I suggested an array descriptor to consist of (at
least) base_address, (allocated) size, dimensions, [for each dimension:
length, stride].

This way I can trivially construct a new descriptor for any subset/slice
out of the original, and for most uses, said construction would only
take a handful of clock cycles.

We still need to care about performance, so even if this setup makes it
easy to define a transposed access pattern, you probably want to instead
create a transposed copy if you are going to do significant work in that
format, but for a single/partial pass it could be ok.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 12/29/2021 8:43 PM, Bakul Shah wrote:
> On 12/29/21 7:22 PM, MitchAlsup wrote:
>> On Wednesday, December 29, 2021 at 7:42:07 PM UTC-6, Bakul Shah wrote:
>>> On 12/29/21 1:31 PM, Terje Mathisen wrote:
>>>> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
>>>> memory was more or less the same speed as CPU, and multiplications were
>>>> much more expensive.
>>>>
>>>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>>> Exactly! This is why "industrial strength" languages should
>>> support them and they don't have to turn into an APL!
>>>
>>> Though the descriptor would need to be somewhat more general
>>> as you may pass a subsrray A[x1..x2; y1..y2] to a function
>>> etc.
>> <
>> I remember MARY 2 (circa 1981) where one could create triangular
>> multidimensional arrays using the <ahem> macro facility. This far
>> surpasses the multidimensional arrays or FORTRAN and like languages.
>
> Perhaps Ivan can expand on that. I knew of Mary1 and Mary2 but
> never used them.
>
> The macro facility would be useful for creating an array with a
> compact lexical expression, but what was its representation at
> run time?
>
> Even Fortran style arrays would be quite useful.

It's a misnomer to call it a macro. "Macro" implies invocation by text
substitution. Mary used lexical substitution, and syntactic substitution
in Mary2. Overloaded, of course.

On 29/12/2021 22:31, Terje Mathisen wrote:
> David Brown wrote:
>> On 29/12/2021 11:46, robf...@gmail.com wrote:
>>> Huh? C does not support multi-dimensional arrays? I did not realize
>>> that. Not realizing
>>> that, it is supported in my cc64 language. I do not see why [ ][ ][ ]
>>> cannot be used in
>>> place of commas.
>>> In cc64 multi-dimensional arrays are supported with the indexing
>>> operator[].
>>> Accessing a multi-dimensional array is just A[x][y][z] which is the
>>> same as A[x,y,z].
>>>
>>
>> Yes, C (and therefore C++) support A[x][y][z] for arrays of arrays of
>> arrays.  But that is not /quite/ the same as a multi-dimensional array.
>>   And C arrays have slightly unusual semantics - array expressions decay
>> into pointer expressions in most circumstances.  Often, you can write
>> simple and clear code with multi-dimensional arrays.  But for some
>> use-cases, you need quite complicated expressions and a lot of care to
>> get the sizes write.
>>
> Multi-dim arrays using Iliffe vectors used to be a good idea, back when
> memory was more or less the same speed as CPU, and multiplications were
> much more expensive.
>
> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
> than to effectively do
>
>   t1 = arr[z]
>   t2 = t1[y]
>   w = t2[x]
>
> where t1[] is an array of pointers to pointers to arrays, and  t2[] is
> an array of pointers to arrays.
>
> Lifting stuff out of the inner loops can often alleviate the costs of
> both of these, but integer mul is far to be preferred to random memory
> access.
>

Sure - but that's why you have an optimising compiler. Write code
clearly, using the array notation of the language you have.

It is not uncommon for a good compiler to be able to optimise array
access code better than manual pointer code, because it has specific
pattern-matching optimisations for such expressions. And it is better
to have clear, human-readable code that optimises imperfectly than
impenetrable and unmaintainable pointer-based code that optimises worse.
You certainly have a better chance of static warnings about accesses
outside array bounds when using arrays.

Details will, of course, vary according to how the arrays are used, what
the compiler can do with them, what processor you are using, and all
kinds of other aspects.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, December 29, 2021 at 4:03:06 PM UTC-6, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:

>> > Then strength-reduction converts MULs within a loop back into ADDs.
>> ... which was a feature of the very first FORTRAN compiler, already.
><
> Something like 1955 ?

It was introduced in 1957.

On 30/12/2021 02:32, Bakul Shah wrote:
> On 12/29/21 1:36 AM, David Brown wrote:
>> On 29/12/2021 10:02, Bakul Shah wrote:
>>> On 12/29/21 12:39 AM, David Brown wrote:
>>>> Ideally, a multi-dimensional array A should be indexed by "A[x, y, z]".
>>>>    That's the way it works in many languages that support them well.
>>>> Unfortunately, C (and therefore C++) have the "comma operator", so that
>>>> expression already has a meaning - evaluate "x" for its side-effects
>>>> then throw it away, evaluate "y" for its side-effects, then you are
>>>> left
>>>> with "A[z]".
>>>
>>> This could've been trivially fixed by using ';' instead of
>>> ','. Since ';' is illegal in the [] context, this would
>>> have not been a breaking change.
>>>
>>
>> I think that would have been /far/ from trivial.  Suddenly you now have
>> two different ways of separating parameters in the language, which would
>
> Array indices are not the same as function parameters.

True...

> Given that C screwed up by misusing , as an operator,

Opinions differ on that one, but I am not personally a big fan of the
comma operator.

> and given that C has no generics,

It does - C11 has _Generic. But it is a different kind of "generic"
than, say, C++ templates.

> there is no other
> choice but to use a different symbol *if* one wanted
> to add multi dim. arrays to C. The syntax part is indeed
> trivially solved but to make multi dim arrays fully
> useful you need the ability to create arrays, reference
> subarrays and pass them as args. etc and that is not
> trivial.  I believe it is indeed possible to add
> full fledged multi-dim. array support to C in a fully
> backward compatible way. Though  am not holding my breath.
> (and I have close to 0 interest in what C++ does. I used
> it for 20+ years. That was a long enough sentence!]

The thread branch was about adding them to C++, not C, since in C++ it
could be done using a class (or more accurately, a class template).

No one is ever going to add a new multi-dimensional array syntax to C.
It won't happen. A suggestion to change the syntax of C so that you can
write "A[x; y; z;]" instead of "A[x][y][z]" would be laughed out of any
standards committee meeting. You don't make such a significant change
to a language syntax for something that trivial.

In C, arrays are an odd beast - they form special types with quite
limited usage. The only operators that can be applied to them are
sizeof and unary & (the "address-of" operator). You can't pass them
into or out of functions.

The subscript operator [] in C is /defined/ as having "A[x]" mean "*(A +
x)". This means "A[x]" and "x[A]" are the same thing in C. You can't
start adding multiple arguments here and turn subscript into a
multi-argument function and call it "trivial" !

In C++, however, there /is/ a way forward. "A[x]" means the same as in
C when "A" is a pointer. But if "A" is a user-defined class with an
overload, it means "A.operator[](x)". Now it is a function call, and
functions can have multiple arguments. In C++, you can make classes
that provide an interface and semantics - you can have array classes
that act as normal "value" objects with array-specific operations,
rather than acting as pointers in expressions. You could make
multi-dimensional array classes that can do new and useful things beyond
simple access - such as operators and methods for manipulating the array
as a whole, or taking sub-arrays. That is inconceivable in C.

All it takes is to change "A[x, y]" to mean "A.operator[](x, y)" instead
of today's "A.operator[]((x, y))". /That/ is an almost trivial change -
but it is still a breaking change to the language.

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Bakul Shah wrote:
>> On 12/29/21 1:31 PM, Terje Mathisen wrote:
>>> Multi-dim arrays using Iliffe vectors used to be a good idea, back
>>> when memory was more or less the same speed as CPU, and
>>> multiplications were much more expensive.
>>>
>>> Today, it is normally far better to do w = arr[z*ZSTRIDE+y*YSTRIDE+x]
>>
>> Exactly! This is why "industrial strength" languages should
>> support them and they don't have to turn into an APL!
>>
>> Though the descriptor would need to be somewhat more general
>> as you may pass a subsrray A[x1..x2; y1..y2] to a function
>> etc.
>
> Sure, which is why I suggested an array descriptor to consist of (at
> least) base_address, (allocated) size, dimensions, [for each dimension:
> length, stride].
>
> This way I can trivially construct a new descriptor for any subset/slice
> out of the original, and for most uses, said construction would only
> take a handful of clock cycles.

You are describing Fortran to a T :-)

> We still need to care about performance, so even if this setup makes it
> easy to define a transposed access pattern, you probably want to instead
> create a transposed copy if you are going to do significant work in that
> format, but for a single/partial pass it could be ok.

This is why Fortran 2008 introduced the "congiguous" attribute,
to give the user a choice. Since then, you can write

subroutine foo(a)
integer, dimension(:,:), contiguous, intent(inout) :: a

and the compiler will conditionally insert code to pack/unpack
(i.e. make a temporary contiguous copyo of) the array if it is
not contiguous already.

This is a reason why specifying the intent is so importrant for
performance. If intent(in) is specified, for example, there is
no need to unpack on exit.

On 12/30/2021 3:01 AM, David Brown wrote:

snip

> No one is ever going to add a new multi-dimensional array syntax to C.
> It won't happen.

I absolutely agree. I do think that it was a mistake not to include
full multidimensional array support early on, given the intended use, I
understand the decision. And backward compatibility makes it hard to
add now.

However, what surprises me is that the newer languages such as Rust,
Zip, Go, etc. appear not to support multi-dimensional arrays. (Of
course, Julia is an exception to that).

I can think of two reasons for this. One is that they were desirable,
but just didn't make the cut for feature inclusion. Given that,
contrary to its designers expectations, C has been fairly widely used
for scientific programming, where multi-dimensional arrays are
important, and the cost to include them isn't that great, I think this
is a mistake. The other reason is perhaps some "evangelists" think it
is a "really bad thing" to include, and their view won out. Perhaps
there are other reasons. But needless to say, I disagree. Of course YMMV.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

> However, what surprises me is that the newer languages such as Rust, Zip,
> Go, etc. appear not to support multi-dimensional arrays. (Of course, Julia
> is an exception to that).
>
> I can think of two reasons for this. One is that they were desirable, but
> just didn't make the cut for feature inclusion. Given that, contrary to its
> designers expectations, C has been fairly widely used for scientific
> programming, where multi-dimensional arrays are important, and the cost to
> include them isn't that great, I think this is a mistake. The other reason
> is perhaps some "evangelists" think it is a "really bad thing" to include,
> and their view won out. Perhaps there are other reasons. But needless to
> say, I disagree. Of course YMMV.

I'd put my money on "designers not familiar enough with scientific computing".

Stefan

On 12/30/2021 10:56 AM, Stefan Monnier wrote:
>> However, what surprises me is that the newer languages such as Rust, Zip,
>> Go, etc. appear not to support multi-dimensional arrays. (Of course, Julia
>> is an exception to that).
>>
>> I can think of two reasons for this. One is that they were desirable, but
>> just didn't make the cut for feature inclusion. Given that, contrary to its
>> designers expectations, C has been fairly widely used for scientific
>> programming, where multi-dimensional arrays are important, and the cost to
>> include them isn't that great, I think this is a mistake. The other reason
>> is perhaps some "evangelists" think it is a "really bad thing" to include,
>> and their view won out. Perhaps there are other reasons. But needless to
>> say, I disagree. Of course YMMV.
>
> I'd put my money on "designers not familiar enough with scientific computing".

Probably a good bet! :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 30/12/2021 18:32, Stephen Fuld wrote:
> On 12/30/2021 3:01 AM, David Brown wrote:
>
> snip
>
>> No one is ever going to add a new multi-dimensional array syntax to C.
>> It won't happen. 
>
> I absolutely agree.  I do think that it was a mistake not to include
> full multidimensional array support early on, given the intended use, I
> understand the decision.  And backward compatibility makes it hard to
> add now.
>
> However, what surprises me is that the newer languages such as Rust,
> Zip, Go, etc. appear not to support multi-dimensional arrays. (Of
> course, Julia is an exception to that).
>
> I can think of two reasons for this.  One is that they were desirable,
> but just didn't make the cut for feature inclusion.  Given that,
> contrary to its designers expectations, C has been fairly widely used
> for scientific programming, where multi-dimensional arrays are
> important, and the cost to include them isn't that great, I think this
> is a mistake.  The other reason is perhaps some "evangelists" think it
> is a "really bad thing" to include, and their view won out.  Perhaps
> there are other reasons.  But needless to say, I disagree.  Of course YMMV.
>
>

I suspect that good native (i.e., part of the core language rather than
libraries or classes) multi-dimensional array support is not as much
needed as it would appear. It is not hard to think of features that
seem obviously essential in a language, and yet are missing in many
languages.

A challenge with multi-dimensional array support beyond the simple and
limited version in C is that people want different things from it. And
that makes it hard to put in the language core. It is arguably better
to make it easy to make user types and let people make the array classes
they want for their own use. C++ provides that, though I think they
might have made a simple multi-dimensional class in the standard
library. I don't know how Rust, Go, etc., fare in this aspect.

On 12/30/2021 11:11 AM, David Brown wrote:
> On 30/12/2021 18:32, Stephen Fuld wrote:
>> On 12/30/2021 3:01 AM, David Brown wrote:
>>
>> snip
>>
>>> No one is ever going to add a new multi-dimensional array syntax to C.
>>> It won't happen.
>>
>> I absolutely agree.  I do think that it was a mistake not to include
>> full multidimensional array support early on, given the intended use, I
>> understand the decision.  And backward compatibility makes it hard to
>> add now.
>>
>> However, what surprises me is that the newer languages such as Rust,
>> Zip, Go, etc. appear not to support multi-dimensional arrays. (Of
>> course, Julia is an exception to that).
>>
>> I can think of two reasons for this.  One is that they were desirable,
>> but just didn't make the cut for feature inclusion.  Given that,
>> contrary to its designers expectations, C has been fairly widely used
>> for scientific programming, where multi-dimensional arrays are
>> important, and the cost to include them isn't that great, I think this
>> is a mistake.  The other reason is perhaps some "evangelists" think it
>> is a "really bad thing" to include, and their view won out.  Perhaps
>> there are other reasons.  But needless to say, I disagree.  Of course YMMV.
>>
>>
>
> I suspect that good native (i.e., part of the core language rather than
> libraries or classes) multi-dimensional array support is not as much
> needed as it would appear. It is not hard to think of features that
> seem obviously essential in a language, and yet are missing in many
> languages.

Probably itself a good topic for discussion, though perhaps off topic
for comp.arch. But I am willing if others are. So can you provide some
examples?

> A challenge with multi-dimensional array support beyond the simple and
> limited version in C is that people want different things from it.

Can you elaborate on this? Are there features that some want that are
hard to provide, or where different people want conflicting features?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Thursday, December 30, 2021 at 1:47:23 PM UTC-6, Stephen Fuld wrote:
> On 12/30/2021 11:11 AM, David Brown wrote:
> > On 30/12/2021 18:32, Stephen Fuld wrote:
> >> On 12/30/2021 3:01 AM, David Brown wrote:
> >>
> >> snip
> >>
> >>> No one is ever going to add a new multi-dimensional array syntax to C.
> >>> It won't happen.
> >>
> >> I absolutely agree. I do think that it was a mistake not to include
> >> full multidimensional array support early on, given the intended use, I
> >> understand the decision. And backward compatibility makes it hard to
> >> add now.
> >>
> >> However, what surprises me is that the newer languages such as Rust,
> >> Zip, Go, etc. appear not to support multi-dimensional arrays. (Of
> >> course, Julia is an exception to that).
> >>
> >> I can think of two reasons for this. One is that they were desirable,
> >> but just didn't make the cut for feature inclusion. Given that,
> >> contrary to its designers expectations, C has been fairly widely used
> >> for scientific programming, where multi-dimensional arrays are
> >> important, and the cost to include them isn't that great, I think this
> >> is a mistake. The other reason is perhaps some "evangelists" think it
> >> is a "really bad thing" to include, and their view won out. Perhaps
> >> there are other reasons. But needless to say, I disagree. Of course YMMV.
> >>
> >>
> >
> > I suspect that good native (i.e., part of the core language rather than
> > libraries or classes) multi-dimensional array support is not as much
> > needed as it would appear. It is not hard to think of features that
> > seem obviously essential in a language, and yet are missing in many
> > languages.
> Probably itself a good topic for discussion, though perhaps off topic
> for comp.arch. But I am willing if others are. So can you provide some
> examples?
<
comp.lang ?
<
> > A challenge with multi-dimensional array support beyond the simple and
> > limited version in C is that people want different things from it.
<
> Can you elaborate on this? Are there features that some want that are
> hard to provide, or where different people want conflicting features?
<
People want to be able to pass rows, columns, diagonals, sub-arrays of
an array or matrix. If you have a dope vector as the underlying access means,
all of this is straightforward.
<
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

David Brown <david.brown@hesbynett.no> schrieb:
> On 30/12/2021 18:32, Stephen Fuld wrote:
>> On 12/30/2021 3:01 AM, David Brown wrote:
>>
>> snip
>>
>>> No one is ever going to add a new multi-dimensional array syntax to C.
>>> It won't happen. 
>>
>> I absolutely agree.  I do think that it was a mistake not to include
>> full multidimensional array support early on, given the intended use, I
>> understand the decision.  And backward compatibility makes it hard to
>> add now.
>>
>> However, what surprises me is that the newer languages such as Rust,
>> Zip, Go, etc. appear not to support multi-dimensional arrays. (Of
>> course, Julia is an exception to that).
>>
>> I can think of two reasons for this.  One is that they were desirable,
>> but just didn't make the cut for feature inclusion.  Given that,
>> contrary to its designers expectations, C has been fairly widely used
>> for scientific programming, where multi-dimensional arrays are
>> important, and the cost to include them isn't that great, I think this
>> is a mistake.  The other reason is perhaps some "evangelists" think it
>> is a "really bad thing" to include, and their view won out.  Perhaps
>> there are other reasons.  But needless to say, I disagree.  Of course YMMV.
>>
>>
>
> I suspect that good native (i.e., part of the core language rather than
> libraries or classes) multi-dimensional array support is not as much
> needed as it would appear. It is not hard to think of features that
> seem obviously essential in a language, and yet are missing in many
> languages.
>
> A challenge with multi-dimensional array support beyond the simple and
> limited version in C is that people want different things from it. And
> that makes it hard to put in the language core. It is arguably better
> to make it easy to make user types and let people make the array classes
> they want for their own use.

I beg to differ there.

Hand-crafted array classes will be buggy, they will be slow (my guess
will be that at least half of them would be based on the "pointer
to pointer" concept) and they will have different features.

Even more worrisome: They will be incompatible, so it will not
be possible to combine software from different packages.

George Neuner <gneuner2@comcast.net> writes:
>E.g., suppose you define 'int arr[2][10]'.
>
>In C you will get a block of memory that can hold 20 contiguous ints
>... but that block has no internal structure:

It's 2 contiguous blocks with 10 contiguous ints each.

>nothing but compiler
>warnings prevent you from referencing arr[1][2] as arr[-1][22], or
>as arr[0][12], or as arr[2][-8], etc.

Yes, and? It's C. If you want a language with array bounds checking,
there are plenty to choose from.

>And those warnings are possible only in scope of the array definition.
>If you pass your '2D' array to a separately compiled function defined
>to take an int* or int[] argument, then all bets are off: that
>function will see a ONE dimensional array with no size limit.

If you don't want that, heed the warnings:

[~/tmp:127444] cat xxx.c
void bar1(int *);
void bar2(int []);
void bar3(int [][10]);

void foo()
{ int arr[2][10];
bar1(arr);
bar2(arr);
bar3(arr);
} [~/tmp:127445] gcc -c xxx.c
xxx.c: In function ‘foo’:
xxx.c:8:8: warning: passing argument 1 of ‘bar1’ from incompatible pointer type [-Wincompatible-pointer-types]
8 | bar1(arr);
| ^~~
| |
| int (*)[10]
xxx.c:1:11: note: expected ‘int *’ but argument is of type ‘int (*)[10]’
1 | void bar1(int *);
| ^~~~~
xxx.c:9:8: warning: passing argument 1 of ‘bar2’ from incompatible pointer type [-Wincompatible-pointer-types]
9 | bar2(arr);
| ^~~
| |
| int (*)[10]
xxx.c:2:11: note: expected ‘int *’ but argument is of type ‘int (*)[10]’
2 | void bar2(int []);
| ^~~~~~

>In a language with true arrays, references that violate the defined
>structure of the array would be errors: the dimensions and limits
>follow the array as it is passed around.

That's a different language style.

What C does is to implement the access to arr[1][2] correctly, which
sounds pretty two-dimensional to me. If you prefer bounds checking, C
is not the language for you.

The more practically relevant problem of multi-dimensional arrays in C
is that all but the leftmost dimension must be a compile-time
constants. I recently wrote a C program where that constraint could
not be satisfied, so I had to implement the access by using a
one-dimensional access and computing the one-dimensional index
manually from the indices of the two-dimensional access and the size
of one dimension.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 30/12/2021 21:57, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:

>>
>> I suspect that good native (i.e., part of the core language rather than
>> libraries or classes) multi-dimensional array support is not as much
>> needed as it would appear. It is not hard to think of features that
>> seem obviously essential in a language, and yet are missing in many
>> languages.
>>
>> A challenge with multi-dimensional array support beyond the simple and
>> limited version in C is that people want different things from it. And
>> that makes it hard to put in the language core. It is arguably better
>> to make it easy to make user types and let people make the array classes
>> they want for their own use.
>
> I beg to differ there.
>
> Hand-crafted array classes will be buggy, they will be slow (my guess
> will be that at least half of them would be based on the "pointer
> to pointer" concept) and they will have different features.
>
> Even more worrisome: They will be incompatible, so it will not
> be possible to combine software from different packages.
>

These are all good points. IMHO, the best solution in situations like
this is for the language to support user-defined types but provide good
general-purpose classes as part of the standard library. Then those
that have special requirements can make their own, while most people can
use the standard library types (minimising the risk of all the problems
you mention). But it is better for the core language to concentrate on
being able to create such types in an efficient, low-risk manner with
convenient user interfaces, than to add more features to the core language.

For most C++ users, a std::array of std::array or a std::vector of
std::vector (or a mix of the two) works well enough, if a bit cumbersome
when defining it. Once it is possible to write "A[x, y]", a better
multi-dimensional array can be made (and hopefully /will/ be made and
added to the standard library).

On 30/12/2021 20:47, Stephen Fuld wrote:
> On 12/30/2021 11:11 AM, David Brown wrote:

>> I suspect that good native (i.e., part of the core language rather than
>> libraries or classes) multi-dimensional array support is not as much
>> needed as it would appear.  It is not hard to think of features that
>> seem obviously essential in a language, and yet are missing in many
>> languages.
>
> Probably itself a good topic for discussion, though perhaps off topic
> for comp.arch.  But I am willing if others are.  So can you provide some
> examples?
>

One example that comes to mind is that neither C nor C++ has a "power"
operator. But usually you think of things that you use regularly in one
language, but are missing when you move to another language. Good
string support, sized integer types, strong enumerators, classes,
multi-threading and atomics - there are all kinds of things that are
heavily used in some languages yet missing entirely in others.

>
>> A challenge with multi-dimensional array support beyond the simple and
>> limited version in C is that people want different things from it.
>
> Can you elaborate on this?  Are there features that some want that are
> hard to provide, or where different people want conflicting features?
>

If you implement a two-dimensional array as an array of arrays, then
it's easy to get sub-arrays in one direction, but difficult in the other
direction. If you want to support that efficiently, you need your
one-dimensional arrays to be characterised by stride size as well as
element count and element size/type. That makes your one-dimensional
arrays less efficient.

Sometimes you want sparse arrays, or arrays with flexible sizes in one
or more dimensions. Maybe you want range checking on access. That's
all possible, but comes at a cost (sometimes a significant cost)
compared to a simpler fixed-size array.

Perhaps you want mixed array/scaler operations - such as making "A = x;"
initialise every element of array "A" with the value "x". That does not
cause additional run-time costs for those that don't want the operation,
but it reduces the compile-time error checking and safety of the type
for those that would prefer it to be an error.

On Friday, December 31, 2021 at 8:44:43 AM UTC-6, David Brown wrote:
> On 30/12/2021 20:47, Stephen Fuld wrote:
> > On 12/30/2021 11:11 AM, David Brown wrote:
>
> >> I suspect that good native (i.e., part of the core language rather than
> >> libraries or classes) multi-dimensional array support is not as much
> >> needed as it would appear. It is not hard to think of features that
> >> seem obviously essential in a language, and yet are missing in many
> >> languages.
> >
> > Probably itself a good topic for discussion, though perhaps off topic
> > for comp.arch. But I am willing if others are. So can you provide some
> > examples?
> >
> One example that comes to mind is that neither C nor C++ has a "power"
> operator. But usually you think of things that you use regularly in one
> language, but are missing when you move to another language. Good
> string support, sized integer types, strong enumerators, classes,
> multi-threading and atomics - there are all kinds of things that are
> heavily used in some languages yet missing entirely in others.
> >
> >> A challenge with multi-dimensional array support beyond the simple and
> >> limited version in C is that people want different things from it.
> >
> > Can you elaborate on this? Are there features that some want that are
> > hard to provide, or where different people want conflicting features?
> >
> If you implement a two-dimensional array as an array of arrays, then
> it's easy to get sub-arrays in one direction, but difficult in the other
> direction. If you want to support that efficiently, you need your
> one-dimensional arrays to be characterised by stride size as well as
> element count and element size/type. That makes your one-dimensional
> arrays less efficient.
>
> Sometimes you want sparse arrays, or arrays with flexible sizes in one
> or more dimensions. Maybe you want range checking on access. That's
> all possible, but comes at a cost (sometimes a significant cost)
> compared to a simpler fixed-size array.
>
> Perhaps you want mixed array/scaler operations - such as making "A = x;"
> initialise every element of array "A" with the value "x". That does not
> cause additional run-time costs for those that don't want the operation,
> but it reduces the compile-time error checking and safety of the type
> for those that would prefer it to be an error.

IIRC the array languages (Numpy, IDL, PV-wave & Matlab?) generate optimized code
dynamically for each occurrence, say as an array assignment expression is evaluated.
Basically JIT compilation. The data structure at the bottom is an up to eight
dimension array descriptor with count and stride in each dimension. Sparse arrays
are accessed through a vector of index values.

On 12/31/2021 6:44 AM, David Brown wrote:
> On 30/12/2021 20:47, Stephen Fuld wrote:
>> On 12/30/2021 11:11 AM, David Brown wrote:
>
>>> I suspect that good native (i.e., part of the core language rather than
>>> libraries or classes) multi-dimensional array support is not as much
>>> needed as it would appear.  It is not hard to think of features that
>>> seem obviously essential in a language, and yet are missing in many
>>> languages.
>>
>> Probably itself a good topic for discussion, though perhaps off topic
>> for comp.arch.  But I am willing if others are.  So can you provide some
>> examples?
>>
>
> One example that comes to mind is that neither C nor C++ has a "power"
> operator. But usually you think of things that you use regularly in one
> language, but are missing when you move to another language. Good
> string support, sized integer types, strong enumerators, classes,
> multi-threading and atomics - there are all kinds of things that are
> heavily used in some languages yet missing entirely in others.

Thank you. Some of these are missing in some languages due to the long
language history and lots of existing code, and the difficulty of adding
a useful feature without breaking compatibility. I totally understand
that. I think most of these are included in most new languages (Is that
enough weasel words????).

I also do like, what apparently others don't, is a spec that says
essentially, this is an optional feature, but if you implement it, it
should work like this. (This goes back at least as far as COBOL.) This
is a compromise between creeping "featureitis" and slow death by
ossification. It also gives some time to see if a feature is really
needed and find any issues with it.

What I don't like is saying a popular feature should be implemented by
the individual programmer or team, as that leads to fracturing,
increased learning and debugging time when you "switch teams", etc.

>>> A challenge with multi-dimensional array support beyond the simple and
>>> limited version in C is that people want different things from it.
>>
>> Can you elaborate on this?  Are there features that some want that are
>> hard to provide, or where different people want conflicting features?
>>
>
> If you implement a two-dimensional array as an array of arrays, then
> it's easy to get sub-arrays in one direction, but difficult in the other
> direction. If you want to support that efficiently, you need your
> one-dimensional arrays to be characterised by stride size as well as
> element count and element size/type. That makes your one-dimensional
> arrays less efficient.

I am not sure I agree that is needed, but even if it is, I think the
overhead is pretty minimal.

> Sometimes you want sparse arrays, or arrays with flexible sizes in one
> or more dimensions. Maybe you want range checking on access. That's
> all possible, but comes at a cost (sometimes a significant cost)
> compared to a simpler fixed-size array.

I may be wrong, but I think most of these are provided in, for example,
Julia. And others should provide more definitive knowledge, but I think
at least some of these are in the newer versions of Fortran.

> Perhaps you want mixed array/scaler operations - such as making "A = x;"
> initialise every element of array "A" with the value "x". That does not
> cause additional run-time costs for those that don't want the operation,
> but it reduces the compile-time error checking and safety of the type
> for those that would prefer it to be an error.

Again, I think that is allowed in Julia (though perhaps with different
syntax).

--
- Stephen Fuld
(e-mail address disguised to prevent spam)