octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #54241] Lookup documentation


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #54241] Lookup documentation
Date: Wed, 4 Jul 2018 15:14:27 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #12, bug #54241 (project octave):


2.2 GiB
octave:1> a=rand(1e8,1);
3.0 GiB
b=a;
3.0 GiB
b=a(2:end);
3.0 GiB
b=a(1:end-1);
3.0 GiB
octave:6> b=a(1:end-1).^2;
3.8 GiB
octave:9> b=a(1:end-1);
3.0 GiB


Yeah, it's all parsing within that loop causing the delay; so you are right
about the memory.

In your second analysis, though, you've overlooked the extra math needed to
adjust the index from 1-start to 0-start:


octave:16> clear all
octave:17> table=sort(rand(5,1));
octave:18> y=rand(100000000,1);
octave:19> tic;for i=1:4 lookup(table(1:5),y);end;toc
Elapsed time is 11.1749 seconds.
octave:20> tic;for i=1:4 lookup(table(1:4),y);end;toc
Elapsed time is 9.89338 seconds.
octave:21> tic;for i=1:4 lookup(table(1:5),y,'r');end;toc
Elapsed time is 9.84659 seconds.
[Here's a more apples-to-apples test...]
octave:24> tic;for i=1:4 lookup(table(2:5),y)+1;end;toc
Elapsed time is 12.8138 seconds.


This is why I've been examining the actual usages of "lookup()" in the script
code to see how much post-function-call math is done.  The math manipulation
in C is but an extra one or two CPU cycles because the value is already in a
register--very low overhead (see the 'r' option above).  But if there is post
processing, that means bringing the values back from memory which adds much
more overhead.

I'm attaching a small diff file that uses "lr" in the file __interp_cube__.m
instead of using the table truncation technique.  (That's faster, correct?) 
The only place I see this routine used is isocolors.m, and the modification
doesn't seem to affect the tests or the appearance "demo isocolors".

One last comment is that I don't see why the rule regarding NaN is imposed as
such, i.e.:


If 'y(i) >= table(end)' or 'isnan (y(i))' then 'idx(i)' is N.


That is, to conflate those two conditions by default is a loss of information.
 Why not, by default, just map y(i) values of NaN to index values of NaN? 
Then, perhaps add an option lookup(...,"nan",VAL) where VAL could be anything,
e.g., -1, 0, N, NaN?

(file #44506)
    _______________________________________________________

Additional Item Attachment:

File name: interp_cube_lookup_lr-djs2018jul04.diff Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54241>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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