I think I'm just saying that we should try to a) remind everyone not to do this, and b) check carefully in Mahout internally to see that we're not doing a lot of nasty map-by-Vector key stuff in places where it will be horribly inefficient.
You're right that *forcibly* breaking the contract to not allow it is probably a bad idea. -jake On Thu, Feb 23, 2012 at 11:35 AM, Dmitriy Lyubimov <[email protected]>wrote: > yes. this is a trick but what i mean complexity of operation still > reflects the by-value effect. (if it is cached or otherwise smartly > organized, it is a different issue from just repelling by-value > equals(). ). > > What i am saying that IMO equals-by-value is a contract and repelling > it in actual implementation will only create contract inconsistency, > but not really introduce any solutions to the problem deefined or > improve existing identity based solutions. As such, what's add-on > value (aside from the fact of catering to naive and untrue view of > O(1) hashing complexity)? > > > > On Thu, Feb 23, 2012 at 11:28 AM, Ted Dunning <[email protected]> > wrote: > > Actually, using a string as a key in a hash map is nearly as efficient as > > bare array indexing. > > > > The reason is that hashes for strings are computed when the string is > > created. > > > > On Thu, Feb 23, 2012 at 7:09 PM, Dmitriy Lyubimov <[email protected]> > wrote: > > > >> All you say is true. It should be noted that using vector as a key is > >> innefficient. Similarly to that using String as a key in a map is just > >> about as inefficient for the same reason. > >> > >> >
