IN fact, setQuick could be viewed as a performance degrading option since it leads people to imagine that they have "optimized" their code. set() is generally inlined and the bounds checks are often lifted out of the loop so there would be no difference. As Sean suggest, however, there is a huge benefit to be gained by block updates.
Thus, eliminating setQuick might encourage people to avoid complacency and seek out a bulk update. On Mon, Jun 15, 2009 at 9:59 AM, Sean Owen <sro...@gmail.com> wrote: > > The difference is getQuick does not check bounds. > > This does make sense for practical reasons. From an API perspective, > seems like it's slightly undesirable to have two of these methods, one > of which exists just to bypass the checks, as it might lead to silent > bugs. I see the purpose: performance. but in that case, as I am > getting to in MAHOUT-121, perhaps it is better to attack that problem > in a different way? for instance, if most of the setting is done in > vector construction, and I imagine it is, then we might want instead > some kind of bulk-set method.
