octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: surface cdata property restricted to double or uint8


From: Jaroslav Hajek
Subject: Re: surface cdata property restricted to double or uint8
Date: Mon, 30 Aug 2010 12:58:06 +0200

On Mon, Aug 30, 2010 at 12:52 PM, Michael Goffioul
<address@hidden> wrote:
> On Mon, Aug 30, 2010 at 6:34 AM, John W. Eaton <address@hidden> wrote:
>> On 30-Aug-2010, Jaroslav Hajek wrote:
>>
>> | If I see right, however, you save the space for lda doubles, but there
>> | are already two arrays of 3*lda doubles around (cmapv and av), which
>> | means you'll save 14% memory at best. That is really not much in
>> | Octave's context. I would likewise prefer the simpler change.
>>
>> OK, I checked in the following change.
>>
>>  http://hg.savannah.gnu.org/hgweb/octave/rev/56f9c10e9e98
>>
>> Note that instead of adding a constraints, I simply removed the
>> existing constraints on the cdata and alphadata surface properties.
>> Does anyone see a problem with doing that?
>
> What about in-place editing? Something like:
>
> NDArray a = cdata.array_value ();
> a.resize (dv);
>
> double *av = a.fortran_vec ();
> const double *cv = a.data ();
>
> (untested)
> Jaroslav can probably comment about the performance of the above code.
>

Array::resize essentially boils down to allocate-copy-replace, so you
won't actually save the temporary memory. I daresay that your original
approach of having both pointers was quite suitable; this only implied
an extra conditional jump (in the ternary expression) per cycle which
I guess was pretty negligible considering the total complexity of the
loop body.

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]