On 2004-04-29 08:43:37 +0200, "Unknown W. Brackets" <unknown@at.simplemachines.dot.org> said:

> Drew McCormack wrote:
>> double[] a = { 1, 2, 3, 4 };
>> double[4] a = { 1, 2, 3, 4 };
>> 
>> It would be good if they did, and even that array literals were allowed in other contexts:
>> 
>> funcToDoSomething( someArgument, {1, 2, 3, 4} );
>> 
>> Drew McCormack
>> Free University, Amsterdam
>> 
> 
> http://digitalmars.com/d/arrays.html#bounds
> 
> Scroll down to "Array Initialization"... it seems you use brackets. (meaning the kind in my name - [ and ].)
> 
> It doesn't work, of course, for associative arrays though.. sadly... I'm not sure if that's meant to change or not.
> 
> -[Unknown]

Hmm, you're right. Please excuse my ignorance.
It would be good if you could do this in places other than initialization though. I still would like array literals.

Drew

On 2004-04-21 21:38:49 +0200, "Walter" <walter@digitalmars.com> said:

> 
> "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message
> news:c65fmi$2js$1@digitaldaemon.com...
>> From what I have read so far, D really has the potential to close the gap
>> between C++ and Fortran and in this way gain a huge share in the
>> scientific/high-performance area of computing. Anyway, to have any chance
>> to go there, much care has to be taken now.
>> 
>> People unfamiliar with numeric programming often wonder why Fortran still
>> has such a huge share among scientists. Many scientists still use
> Fortran77
>> and even those who have moved to Fortran95 only use it for its modern
>> syntax, never touching the advanced concepts of it. And this is not only
>> because they don't know better, but also because it is extremely hard to
>> match the performance of Fortran77! (OK, 99% of the reason might actually
>> be the lazyness to learn a different language and the existing code-base,
>> but still people usual argue based on the superior performance of the
>> language)
> 
> What Fortran has over C is the 'noalias' on function parameters which allows
> for aggressive optimization. What I'm thinking of is writing the spec for D
> functions so that parameters are always 'noalias' (for extern (C) functions
> this would not apply).
> 
> What do you think?
> 
> For reference: http://www.lysator.liu.se/c/restrict.html

I'm all for it. It's bad programming form anyway, so just forbid it like fortran. It will solve a lot of headaches.

Drew

Matthew wrote:
> Have you looked at the very efficient (though poorly documented)
> multidimensional arrays in STLSoft (http://stlsoft.org/)? There's
> fixed_array for fixed-dimensional arrays (up to four) with dimension
> extents variable at runtime, and frame_array (soon to be renamed to
> something more meaningful) which have a fixed number of dimensions and
> fixed extents (a thin veneer for STL compatility over built-in arrays).
> 
> I reckon they're about as close to the bone as C++ will let you get. I'd be interested in hearing your opinions of the implementations.
> 
> Their storage is contiguous

Just found them. What I'm missing is slicing.

Actually, the internal representation of STL has only to be generalized slightly to give far more power to arrays.

The vision I have of rectangular arrays in D is, to take the concept of the current dynamic arrays, where many different array references can point to different slices of the same physical data block.

One array reference does not need to know anything but position of its own [0,0] element, and the range and the stride of all dimensions.

The stride for the last dimension would usually be one, but allowing different values will immediately give you grid-slicing at no additional cost. It will even allow direct access to fortran arrays and even reversing the array without moving anything in the memory.

Many array implementations have plain arrays and array slices as different types. I believe, this is not necessary. Assuming that every array has arbitrary strides will allow much more flexible use of libraries etc. Optimizing the code for cases where certain strides are one should then be left to the compiler.

Drew McCormack wrote:
> Hmm, you're right. Please excuse my ignorance.
> It would be good if you could do this in places other than initialization though. I still would like array literals.
> 
> Drew
> 

No, not ignorance... I happened to remember where it was.  I know I would like array literals myself, but as it seems this is planned for the future:

http://digitalmars.com/d/future.html

-[Unknown]

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c6qrhd$119j$1@digitaldaemon.com...
> Matthew wrote:
> > Have you looked at the very efficient (though poorly documented)
> > multidimensional arrays in STLSoft (http://stlsoft.org/)? There's
> > fixed_array for fixed-dimensional arrays (up to four) with dimension
> > extents variable at runtime, and frame_array (soon to be renamed to
> > something more meaningful) which have a fixed number of dimensions and
> > fixed extents (a thin veneer for STL compatility over built-in arrays).
> >
> > I reckon they're about as close to the bone as C++ will let you get. I'd be interested in hearing your opinions of the implementations.
> >
> > Their storage is contiguous
>
> Just found them. What I'm missing is slicing.
>
> Actually, the internal representation of STL has only to be generalized slightly to give far more power to arrays.
>
> The vision I have of rectangular arrays in D is, to take the concept of
the
> current dynamic arrays, where many different array references can point to different slices of the same physical data block.
>
> One array reference does not need to know anything but position of its own [0,0] element, and the range and the stride of all dimensions.
>
> The stride for the last dimension would usually be one, but allowing different values will immediately give you grid-slicing at no additional cost. It will even allow direct access to fortran arrays and even
reversing
> the array without moving anything in the memory.
>
> Many array implementations have plain arrays and array slices as different types. I believe, this is not necessary. Assuming that every array has arbitrary strides will allow much more flexible use of libraries etc. Optimizing the code for cases where certain strides are one should then be left to the compiler.

I agree that arrays and their slices should be the same type, but
rectangular
arrays and jagged arrays should be different types.

Ivan Senji wrote:

> "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c6qrhd$119j$1@digitaldaemon.com...
>> Matthew wrote:
>> > Have you looked at the very efficient (though poorly documented)
>> > multidimensional arrays in STLSoft (http://stlsoft.org/)? There's
>> > fixed_array for fixed-dimensional arrays (up to four) with dimension
>> > extents variable at runtime, and frame_array (soon to be renamed to
>> > something more meaningful) which have a fixed number of dimensions and
>> > fixed extents (a thin veneer for STL compatility over built-in arrays).
>> >
>> > I reckon they're about as close to the bone as C++ will let you get. I'd be interested in hearing your opinions of the implementations.
>> >
>> > Their storage is contiguous
>>
>> Just found them. What I'm missing is slicing.
>>
>> Actually, the internal representation of STL has only to be generalized slightly to give far more power to arrays.
>>
>> The vision I have of rectangular arrays in D is, to take the concept of
> the
>> current dynamic arrays, where many different array references can point to different slices of the same physical data block.
>>
>> One array reference does not need to know anything but position of its
>> own
>> [0,0] element, and the range and the stride of all dimensions.
>>
>> The stride for the last dimension would usually be one, but allowing different values will immediately give you grid-slicing at no additional cost. It will even allow direct access to fortran arrays and even
> reversing
>> the array without moving anything in the memory.
>>
>> Many array implementations have plain arrays and array slices as different types. I believe, this is not necessary. Assuming that every array has arbitrary strides will allow much more flexible use of libraries etc. Optimizing the code for cases where certain strides are one should then be left to the compiler.
> 
> I agree that arrays and their slices should be the same type, but
> rectangular
> arrays and jagged arrays should be different types.

Of course. As I mentioned, I'm working on a detailed proposal, hoping to get to have it written by next week. Jagged arrays would be just what they are now: arrays of references to arrays of arbitrary size. Newly introduced would be references to truely rectangular arrays with arbitrary dimension, ranges and strides.