From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,bf03d731a6ef511f X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "(see below)" Newsgroups: comp.lang.ada Subject: Re: Copying rows in a two dimensional array. Date: Tue, 09 Feb 2010 01:03:07 +0000 Message-ID: References: <12ezqn0wq0lmm$.s7nr5aueiwa4$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: individual.net /LcP2ZJPGSh4aG8cB862swzHAVnPIWs1P0ZAB0ogIpBFjxDy7o Cancel-Lock: sha1:JPKeyPqDSpQmvQPF3ij/UriEsGw= User-Agent: Microsoft-Entourage/12.20.0.090605 Thread-Topic: Copying rows in a two dimensional array. Thread-Index: AcqpI6PEB7YtMjqOM0ibO7/yvW1x2Q== Xref: g2news1.google.com comp.lang.ada:9010 Date: 2010-02-09T01:03:07+00:00 List-Id: On 09/02/2010 00:36, in article hkqamr$8mq$1@munin.nbi.dk, "Randy Brukardt" wrote: > > "(see below)" 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" 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 chez blueyonder.co.uk