Installing additional packages. Starting up an Octave work environment. My guess is that to implement what you are thinking, i.e., that x(1:end-1) is simply an input and hence no new vector or parsing consideration is needed, would probably require some fair amount of work on JWEs part.Remarks on MATLAB and pointers to documentation. Octave:6> tic for i1:100000 table(1:end-1) end toc Elapsed time is 1.99329 seconds.
![]() ![]() Gnu Octave Documentation Full Table AndJust do aLookup() is being used in several places in a way similar to what you are doing by truncating the input table vector.Your assumption about the memory efficiency of x(1:end-1) is likely incorrect. This is something that could be also improved in the code, making it smaller and executing faster.There aren't that many uses of lookup. But I think that my previous conclusions were premature, because:Tic for i=1:4 lookup(table(1:5),y) end tocTic for i=1:4 lookup(table(1:4),y) end tocTic for i=1:4 lookup(table(1:5),y,'r') end tocSo actually what I thought should be faster (looking up into a smaller table) indeed is faster than looking up into the full table and doing post-processing.There might be big-data users who have a need for organizing in a lexicographic manner. I can see the "rows" option as useful for lookup(). That info would be needed for checking conformance, internal loop limits, etc.The option "m" (and hence "b") seems like it could be accomplished with the routine ismember(), which already has a "rows" option. There'd have to be some kind of reference to a vector for which the referencing "sub-vector" has a start and stop index specifying a subrange. E.g.,If the table is decreasing, then the tests are reversed. It would be a matter of convenience for the user. Plus, the case of table monotonically decreasing.1) Fix the "table(idx(i+1)) should be table(idx(i)+1)".2) Consider explicitly writing out the formula and endpoints for the monotonically decreasing table scenario. But that's really not a case where someone would use lookup(). There is even a conflicting aspect of the current definition with this example:I.e., this is a case where 'r' doesn't mean all induces are at most N-1, i.e., 0. They are close, but also the endpoint handling is a monkey wrench in a simple definition. Target meet me in the middle songAnd I too find it counterintuitive that there are options that make a function explicitly ignore an element of the input, when I could equally have just removed the element from the input (note that with Octave's memory management writing table(2:end) does not take any significant memory overhead). So not many bytes of code can be saved by using these options, at the expense of having to maintain the code in lookup and making the documentation more intimidating. And of course, lookup(table,y,'lr') is equal to lookup(table(2:end-1),y)+1. Indeed, these are just syntactic sugar (with not much energy content at that), because you do not even need to explicitly extend your table to infinity: as I said, lookup(table,y,'l') is always equal to lookup(table(2:end),y)+1, and lookup(table,y,'r') is equal to lookup(table(1:end-1),y). The result is undefined if TABLE is not monotonic, or if TABLE contains a NaN.Dan: interesting that you had just the same feeling with regard to 'l' and 'r' as I had. What probably will happen is that lookup does interval bisection and stops once it has found an idx so that table(idx)Mike wrote: "But I am also unclear on lookup, I have to relearn how it works every time I look at it"Yes, my impression from months back was that "table lookup" is a very simple concept but after reading the documentation one is left confused. Does anybody understand why this is?As regards the case of unsorted tables: the behaviour is undefined, that is, anything can happen. But the timing results do not confirm this, actually using 'l' and friends is faster. So I would have assumed that lookup(table,y,'r') takes longer than lookup(table,y), while my proposal of lookup(table(1:end-1),y) should have been faster, because it does not do post-processing and the table is smaller. Further: as I read the code of lookup, actually the function do_numeric_lookup in libinterp/corefcn/lookup.cc, it seems to me that the behaviour of 'l' and friends is provided by post-processing. SeeRik mentioned keeping 'lr' because of consistency with other routines. I did have comments about the very things you are mentioning. That is:"For each element of the function returns the index of the last element in that is smaller than or equal to the entry in If table is sorted, the result may be used as a prelude to interpolation."I cleaned up this documentation a bit not too long ago, but I didn't really look at the details as I didn't want to make too many changes. That is "y(i) y = 2 table = 5:-1:1 It becomes clear that Michael's definition is more correct.So how about we make the "increasing" aspect be an ancillary comment. What I see wrong with the current documentation definition is that its definition is implicitly dependent on table being ordered. ![]()
0 Comments
Leave a Reply. |
AuthorSteven ArchivesCategories |