5 ms·

Arrays of Arrays (2009)

kqr 6y ago
This reasoning seems to me similar to how declaring a pointer in e.g. C works: many beginners write int* a, b; And think that this constructs two pointers-to-integer. In fact, it constructs one pointer and one plain integer. A better (equivalent) way to write it is int *a, b; You're not declaring variables of type int* You're saying that b is an int and *a Is an int, where the asterisk means "the dereferenced a"!
- pwdisswordfish4 6y ago
  Beginners and also C++ programmers, expert and beginner alike. Even though it’s just as misleading in C++. This: int a = 0; int& x = a, y = a; declares x to be a reference, but y an independent variable. Similarly, a template parametrised by a variadic pack of function pointers is declared thus: template <void (*...x)(void)> It’s a good thing I don’t work in C++ too often, because my forehead would have probably sustained noticeable injury from all the facepalming each time I see ‘int& x’ instead of ‘int &x’ and ‘typename... T’ instead of ‘typename ...T’.
xeromal 6y ago
That was a fun little exercise
Animats 6y ago
Over a decade ago I was trying to get the C++ committee to support multidimensional arrays via overloading, so we could have 2D collections. In C++, you can overload "operator[]". But it can't take more than one argument. Why? Because of the C "comma operator". In C, the comma operator evaluates both operands and discards the first result. It's an ancient hack used mostly with preprocessor defines. In C and C++, foo(a,b) is a call with two arguments. But foo[a,b] invokes the comma operator and presents one value to "[]" You have to dig through the C++ specification to find this. So I asked the question, could anyone find an example of the comma operator used in C or C++ inside square brackets in any production code. I couldn't. I got someone at IBM Almaden to search IBM's code archive and they couldn't. But there was the concern that somewhere, someone had used that misfeature for something. So, no 2D array syntax for you.
- sesuximo 6y ago
  Imo foo[x][y] is better for many reasons: - compiler can break it apart so foo[x] is evaluated once for many ys just like any other function - you can make types that are unaware of their rank eg vector doesn’t know if it’s a 1D vector of int or a 2D vector of vectors - “seamlessly” handles jagged arrays
  - jiggawatts 6y ago
    Which reminds me of an insightful observation that the array indexing operator [] and the function call operator () are basically doing the same thing: evaluating a function and returning a value. So what you've just described is basically Currying, or partial function evaluation. It's a bit like defining "al(i)" as array lookup for an index 'i' instead of "[i]". Then the following are equivalent: something[i][j] something.al(i).al(j) What people also want are: something[i,j] something.al(i,j) In languages like Haskell, every function can always be evaluated argument-by-argument, with no special effort by the programmer. The compiler takes care of generating the code for the various intermediate call forms. In languages like C++, it would be a significant hassle to create all of the various partially-evaluated wrapper types.
    - deleted 6y ago
      [deleted]
    - gpderetta 6y ago
      In C++ you can create a simple generic reusable currying wrapper. Boost as a few. The reality is that the vast majority of C++ programmers don't see the need.
      - Animats 6y ago
        Trying to do this this through Currying turns a simple 2D array access into a quite complicated operation. One that a compiler has to be really smart to turn into a gheap 2D array indexing operation again. This really matters in number-crunching code, where it seems that almost everything is about multiplying arrays.
deleted 6y ago
[deleted]
Per_Bothner 6y ago
Which is why the sane way to do it is to have the array-specifier come before the element type: [,][]int crazy; It reads "2-dimensional array of array of int" in L-to-R order. Similarly, the type "pointer-to-int" should be "*p" or equivalent. Unfortunately, history/tradition as well parsing problems make the "sane" solution difficult. One solution is the Pascal approach putting the type after the variable being declared, with a colon between: crazy : [,][]int;
- Athas 6y ago
  Strongly agreed! During my PhD I had to design array type syntax for a programming language, and we eventually came up with something similar to that: https://futhark-lang.org/blog/2016-12-09-two-syntax-design-problems.html#array-types https://futhark-lang.org/blog/2016-12-09-two-syntax-design-p...
teleforce 6y ago
Take a look at D language library Mir for N-Dimensional array and its comparison to Numpy [1]. Its native performance inside GLAS implementation is something to shout about and even comparable to OpenBLAS that is currently being used by Julia and Matlab [2][3]. [1]http://docs.algorithm.dlang.io/latest/mir_ndslice.html http://docs.algorithm.dlang.io/latest/mir_ndslice.html [2]http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/... [3]http://docs.mir.dlang.io/latest/mir_glas.html http://docs.mir.dlang.io/latest/mir_glas.html

kqr 6y ago

This reasoning seems to me similar to how declaring a pointer in e.g. C works: many beginners write int* a, b; And think that this constructs two pointers-to-integer. In fact, it constructs one pointer and one plain integer. A better (equivalent) way to write it is int *a, b; You're not declaring variables of type int* You're saying that b is an int and *a Is an int, where the asterisk means "the dereferenced a"!

pwdisswordfish4 6y ago
Beginners and also C++ programmers, expert and beginner alike. Even though it’s just as misleading in C++. This: int a = 0; int& x = a, y = a; declares x to be a reference, but y an independent variable. Similarly, a template parametrised by a variadic pack of function pointers is declared thus: template <void (*...x)(void)> It’s a good thing I don’t work in C++ too often, because my forehead would have probably sustained noticeable injury from all the facepalming each time I see ‘int& x’ instead of ‘int &x’ and ‘typename... T’ instead of ‘typename ...T’.

xeromal 6y ago

That was a fun little exercise

Animats 6y ago

Over a decade ago I was trying to get the C++ committee to support multidimensional arrays via overloading, so we could have 2D collections. In C++, you can overload "operator[]". But it can't take more than one argument. Why? Because of the C "comma operator". In C, the comma operator evaluates both operands and discards the first result. It's an ancient hack used mostly with preprocessor defines. In C and C++, foo(a,b) is a call with two arguments. But foo[a,b] invokes the comma operator and presents one value to "[]" You have to dig through the C++ specification to find this. So I asked the question, could anyone find an example of the comma operator used in C or C++ inside square brackets in any production code. I couldn't. I got someone at IBM Almaden to search IBM's code archive and they couldn't. But there was the concern that somewhere, someone had used that misfeature for something. So, no 2D array syntax for you.

sesuximo 6y ago
Imo foo[x][y] is better for many reasons: - compiler can break it apart so foo[x] is evaluated once for many ys just like any other function - you can make types that are unaware of their rank eg vector doesn’t know if it’s a 1D vector of int or a 2D vector of vectors - “seamlessly” handles jagged arrays
- jiggawatts 6y ago
  Which reminds me of an insightful observation that the array indexing operator [] and the function call operator () are basically doing the same thing: evaluating a function and returning a value. So what you've just described is basically Currying, or partial function evaluation. It's a bit like defining "al(i)" as array lookup for an index 'i' instead of "[i]". Then the following are equivalent: something[i][j] something.al(i).al(j) What people also want are: something[i,j] something.al(i,j) In languages like Haskell, every function can always be evaluated argument-by-argument, with no special effort by the programmer. The compiler takes care of generating the code for the various intermediate call forms. In languages like C++, it would be a significant hassle to create all of the various partially-evaluated wrapper types.
  - deleted 6y ago
    [deleted]
  - gpderetta 6y ago
    In C++ you can create a simple generic reusable currying wrapper. Boost as a few. The reality is that the vast majority of C++ programmers don't see the need.
    - Animats 6y ago
      Trying to do this this through Currying turns a simple 2D array access into a quite complicated operation. One that a compiler has to be really smart to turn into a gheap 2D array indexing operation again. This really matters in number-crunching code, where it seems that almost everything is about multiplying arrays.

deleted 6y ago

[deleted]

Per_Bothner 6y ago

Which is why the sane way to do it is to have the array-specifier come before the element type: [,][]int crazy; It reads "2-dimensional array of array of int" in L-to-R order. Similarly, the type "pointer-to-int" should be "*p" or equivalent. Unfortunately, history/tradition as well parsing problems make the "sane" solution difficult. One solution is the Pascal approach putting the type after the variable being declared, with a colon between: crazy : [,][]int;

Athas 6y ago
Strongly agreed! During my PhD I had to design array type syntax for a programming language, and we eventually came up with something similar to that: https://futhark-lang.org/blog/2016-12-09-two-syntax-design-problems.html#array-types https://futhark-lang.org/blog/2016-12-09-two-syntax-design-p...

teleforce 6y ago

Take a look at D language library Mir for N-Dimensional array and its comparison to Numpy [1]. Its native performance inside GLAS implementation is something to shout about and even comparable to OpenBLAS that is currently being used by Julia and Matlab [2][3]. [1]http://docs.algorithm.dlang.io/latest/mir_ndslice.html http://docs.algorithm.dlang.io/latest/mir_ndslice.html [2]http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/... [3]http://docs.mir.dlang.io/latest/mir_glas.html http://docs.mir.dlang.io/latest/mir_glas.html