If you want to have the original mutable vector around, you may want to
keep it as a value instead of a key. You can do something like map the
Vector{Int} to a single Int value, use that as a key and then keep the
Vector{Int} as part of the Dict value.
On Mon, Apr 13, 2015 at 6:06 PM, Seth <catch...@bromberger.com> wrote:
> Two ideas that *might* work:
>
> 1) is hashing the key - that is, if you can represent the Vector{Int} as
> an immutable type (say, by somehow quickly changing it into an Int64 or
> Int128, perhaps using hash()) then you store the computed result as the
> key. The thing to keep in mind here is that if you mutate the vector, you
> will mutate the hash as well. That is likely what you want, but it's good
> to be explicit. You will also not be able to "go back" unless you create a
> separate dict with the hash values as a key and the Vector{Int} as the
> value.
>
> 2) is creating two data structures: one is a Vector{Vector{Int}}, the
> other a Dict{Int, Vector{Float64}}. The index of the first data structure
> is the key of the second, and it should be* faster to check the former
> against a given vector then going through a dict. Unlike #1, the index will
> NOT change if you mutate the inner vector.
>
>
>
>
> On Monday, April 13, 2015 at 1:56:55 PM UTC-7, Will Kearney wrote:
>>
>> I'm hoping I can get some advice on optimizing some code.
>>
>> I have a data structure which is very conveniently represented as a
>> Dict{Vector{Int},Vector{Float64}}. That is, I need to look up
>> floating-point vectors stored at certain multidimensional (usually 2-10)
>> positions represented as a Vector{Int}. Before I construct this Dict, I
>> don't have a priori knowledge of what position vectors will be represented.
>>
>> I'm aware of the problems of using mutable objects as Dict keys, but
>> let's assume that's not really an issue.
>>
>> Profiling reveals that the real time sink is testing arrays for equality
>> when indexing into this data structure, and indexing happens very
>> frequently. What would be a good way to speed this process up?
>>
>> Is there a way to represent the keys which will be cheaper to compare? I
>> could convert the keys to tuples, but it's helpful to have them as mutable
>> arrays to do some calculations with them at certain points.
>>
>> Is there a different data structure which might work better? Should I
>> roll my own hash table implementation which is particularly optimized for
>> vector keys?
>>
>
