[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/
- [Octave-bug-tracker] [bug #54241] Lookup documentation, (continued)
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Mike Miller, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Mike Miller, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Michael Leitner, 2018/07/04
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/04
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Michael Leitner, 2018/07/04
- [Octave-bug-tracker] [bug #54241] Lookup documentation,
Dan Sebald <=