Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: Efficient general purpose 1D lookup table?
Replies: 7   Last Post: Jan 6, 2014 11:58 AM

 Messages: [ Previous | Next ]
 Paul Posts: 517 Registered: 2/23/10
Re: Efficient general purpose 1D lookup table?
Posted: Dec 11, 2013 11:51 AM

On Sunday, December 8, 2013 9:05:23 PM UTC-5, Steven Lord wrote:
>> I was in fact using a similar approach as your non-sparse lookup
>> table. Since the allowable input values are not continguous, it
>> would be nice if the input argument didn't have to be continuous
>> (matrix indexes have to be).

>
> I'm not sure what you mean here. In a sparse matrix, only the
> nonzero elements are stored. If you have a nonzero element in row 1
> and a nonzero element in row 1000000, that sparse matrix stores just
> those two nonzero values.

Yes, but you still get a valid return value (zero) when the index points to a zero value. I don't want to have to trap zeros because zero is one of the valid values to be returned in a lookup.

>> ...And it would be
>> good if I could cause some kind of abnormality like use NaNs in
>> place of the zeros in a sparse matrix.

>
> The FULL command is just to display the results nicely. It's not
> necessary if you want to work with the values.
>
> sparseFoundValues = lookupTable(valuesToFind, 1); for k =
> 1:length(interpolationLocations) % Do something with
> interpolationLocations(k) and sparseFoundValues(k) end % or just
> work with the whole vectors
> plot(interpolationLocations,sparseFoundValues)

Understood, thanks. However, it seems to me that I would have to work with full matrix just to stick NaNs into locations where the input argument should be invalid. If I understood correctly.

>> Currently, I avoid the issue by restricting myself to contigous
>> input values starting from 1. Strictly speaking, I could encounter
>> situations where that isn't the case, so I was hoping to write code
>> that handles those situations without adding to much to the code
>> (and ideally without departing from vectorization).

Date Subject Author
12/5/13 Paul
12/6/13 EBS
12/6/13 Steven Lord
12/6/13 Paul
12/8/13 Steven Lord
12/11/13 Paul
12/11/13 Steven Lord
1/6/14 Paul