Author
Topic: Dynamic array extensions ? (Read 7710 times)

I would like to draw your attention to a new feature announced on the FPC mailing list: Dynamic array extensions. In short:

- support for array constructors using "[...]" syntax- support for Insert(), Delete() and Concat()- support for "+" operator- support for dynamic array constants (and variable initializations)

Sounds ok, however: The "+" operator is effectively an alias for concat(), and it will be an intrinsic, which means that existing "+" operator overloads for dynamic arrays will no longer compile. Intrinsic operators cannot be overloaded, hence it will no longer be possible to custom define the "+" operator to do a mathematical elementwise addition of numerical vectors/matrices.

With the "+" operator hijacked, all other obvious mathematical operators i.e. -, *, / for numeric vectors are effectively obliterated. We would either have to revert to procedural style as in turbo pascal days, such as in function add (V1, V2: TVector): TVector; or declare extra container classes for numeric vectors / matrices, to which mathematical operators can be applied.

That gives several examples of constant arrays being declared within the code that uses the arrays. I assume something like that will be available in Pascal. If so, that should make for cleaner code, less code.

I'm kind of indifferent to operator overloading. Since you already have to declare a function that gets called when you use the overloaded operator, maybe just make that function available in the interface section so it can be used in case "+" is lost.

The Swift example also uses operator overloading for tensor arithmetic. So something like this:

tanh(matmul(x, w1) + b1)

Could be written without operator overloading like this:

tanh(add(matmul(x, w1), b1))

That still seems pretty clear. After all, you can't get away completely from calling functions when you're doing this kind of stuff. I suppose you could overload operators for both tanh and matmul if there were obvious math symbols that made sense. Are there limitations on what characters you can overload? In Swift, I believe you can use any Unicode character as an overloaded operator. In fact, they actually overload ⊗ for matrix multiplication, so you could write this:

tanh(x ⊗ w1 + b1)

Interesting that they don't use that overloaded operator in their own example. Perhaps cooler heads prevailed.

In my Pascal interface to TensorFlow I overloaded the arithmetic operators too, per Swift, but I don't think I would miss them if they weren't available.

Perhaps just rejoice in the "lower-ceremony" syntax for arrays and make peace with the loss of an overloaded "+" in this one case.

I would like to draw your attention to a new feature announced on the FPC mailing list: Dynamic array extensions. In short:

- support for array constructors using "[...]" syntax- support for Insert(), Delete() and Concat()- support for "+" operator- support for dynamic array constants (and variable initializations)

Sounds ok, however: The "+" operator is effectively an alias for concat(), and it will be an intrinsic, which means that existing "+" operator overloads for dynamic arrays will no longer compile. Intrinsic operators cannot be overloaded, hence it will no longer be possible to custom define the "+" operator to do a mathematical elementwise addition of numerical vectors/matrices.

With the "+" operator hijacked, all other obvious mathematical operators i.e. -, *, / for numeric vectors are effectively obliterated. We would either have to revert to procedural style as in turbo pascal days, such as in function add (V1, V2: TVector): TVector; or declare extra container classes for numeric vectors / matrices, to which mathematical operators can be applied.

What is your opinion on that ?

on one hand it nice not to have to write those pesky init routines, on the other I have no idea why it is needed to become an intrinsic, until I get some insight on that I can't really comment. I guess it makes things both better and worst. Its better because now + becomes standard, stable, when I see it on piece of code that I debug, I know exactly what it does, it is worst well I guess you know why. Now you have to type all kinds of staff and your code moves a bit farther away from math symbolism. You could say I'm on the fence on that.ps Oh by the way becoming like swift is a bad thing not a good one (just kidding)

« Last Edit: June 07, 2018, 04:36:09 am by taazz »

Logged

Good judgement is the result of experience … Experience is the result of bad judgement.

Well the logical thing for dynamic arrays is really concat after all, because it not necessarily holds data that you can perform vector math on.For use as vectors you can write a type helper Add(), something like:

Still, how do you retrieve the dimensions easily? (also goes for the operators on vector cells) These must be known and furthermore dynamic arrays can be ragged arrays, which complicates it even further.Ragged: Given an array of array of integer, you can do this: Setlength(a,3,5); Setlength(a[0],3); Setlength(a[4],2);

Well the logical thing for dynamic arrays is really concat after all, because it not necessarily holds data that you can perform vector math on.

You could invert that logic, and say that contrary to strings because dynamic arrays CAN contain data you can do math on, you reserve that operator for its mathematical meaning.

And for appending you can write a type helper Append()

Then you keep the association between static and dynamic arrays instead of strings and dynamics arrays. Also, Strings are commonly concatenated, but general arrays much less often, while running an operator on every element of an array is more common.

while I like most of improvements, the support for "+" operator seems strange even for me (I generally like new things)... Also strange is breaking backward compatibility (which AFAIK is one of priority) with questionable gain.

I would like to take the opportunity to share what I miss: faster math vector operations. Some vectors I use have 10000 elements that are summed/multiplied with other vectors. I ended coding it in assembler (the full code has more than 4000 lines):

TNeuralFloatArrPtr is a pointer to the first element of a single precision floating point dynamic array.

With the "+" operator hijacked, all other obvious mathematical operators i.e. -, *, / for numeric vectors are effectively obliterated. We would either have to revert to procedural style as in turbo pascal days, such as in function add (V1, V2: TVector): TVector; or declare extra container classes for numeric vectors / matrices, to which mathematical operators can be applied.

Oh dear!

I consistently use operator overloading on vectors and matrixes. Seems like going backwards to rewrite everything as functions or container classes. If I add two vectors I don't want them concatenated!! :/

@schuler:1. I think you did not really read the original post; I did not advertize these "improvements", which in my view are unnecessary as part of the core language, as it is trivial to implement them manually. I wanted to hear other user's opinion on the developer's plan to implement the + operator as intrinsic for concatenation of dynamic strings, making it unavailable for simple vector addition: I use vector addition a lot but never needed concatenation.

2. Thanks for the code. For my current project the normal non-vectorised math is sufficient, although optimisation is always tempting. My own knowledge of assembler is poor, and I appreciated the native support for vectorised math which had once been introduced (I think by switch $Sv). But unfortunately it has not been maintained any further and is now broken, at least under windows :-(