Re: Copying rows in a two dimensional array.

["(see below)" <yaldnif.w@blueyonder.co.uk>]

On 09/02/2010 00:36, in article hkqamr$8mq$1@munin.nbi.dk, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

> 
> "(see below)" <yaldnif.w@blueyonder.co.uk> wrote in message
> news:C7964E2E.135979%yaldnif.w@blueyonder.co.uk...
>> On 08/02/2010 21:20, in article wccd40fpgpu.fsf@shell01.TheWorld.com,
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>> 
>>> It's trivial if you only want slices as R-values.
>>> And anyway, slices as L-values don't really work:
>> 
>> I can't agree. I have this code:
>> 
>> procedure FFT_to_HWT (FFTCs    : in  complex_array; ...
>>                      HWT_tree : out complex_array; ...) is
>> ...
>>   iFFTCs : complex_array (1..f(FFTCs'length));
>> begin
>> ...
>>   iFFTCs(1..nr_bins) := FFTCs(first_bin..last_bin);
>>   iFFTCs(nr_bins+1..iFFT_size) := (others => (0.0,0.0));
>>   inverse_FFT(iFFTCs(1..iFFT_size));
>> ...
>>   HWT_tree(next_HWTC..next_HWTC+iFFT_size-1) := iFFTCs(1..iFFT_size);
>> ...
>> end FFT_to_HWT;
>> 
>> I think that using slices as L-values as well as R-values helps to make
>> this
>> a lot clearer than it otherwise would be, and probably faster as well.
> 
> It's cases like this that make both the pro and con for slices. Expressions
> like these are probably easier to read and probably faster than the
> equivalent non-slice code.
> 
> But on the flip side, it's very hard to get the bounds right (I think I get
> these sorts of slices wrong 25% of the time). So you end up spending a lot
> of time debugging (at least Ada detects this). Moreover, it's hard to figure
> out from the code whether or not the bounds are right -- I'll often end
> drawing a picture and plug in various values to see if it makes sense. Case

But you rraly have to do that reasoning in any case.

> in point is the first statement; it fails unless last_bin - first_bin + 1 =
> nr_bins. So it's not clear how that is saving anything.

The elided statements include:

if ... then
   nr_bins  := ...;
   last_bin := nr_bins + first_bin - 1;
else
   last_bin := ...;
   nr_bins := last_bin - first_bin + 1;
end if;

I was hoping the compiler would be able to propagate the bounds down to the
slices, and then note that:

  iFFTCs(1..nr_bins)'Length == FFTCs(first_bin..last_bin)'Length

Perhaps that is asking too much.

Recoding thus:

   iFFTCs(1..last_bin-first_bin+1) := FFTCs(first_bin..last_bin);
   iFFTCs(last_bin-first_bin+2..iFFT_size) := (others => (0.0,0.0));

 might even be an improvement in clarity, and I'd be disappointed if the
compiler did not then notice the identity of lengths.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk