On 11/8/13 11:59 AM, Ted Dunning wrote: > On Fri, Nov 8, 2013 at 11:47 AM, Luc Maisonobe <l...@spaceroots.org> wrote: > >>> is there still consensus that we are going to remove the sparse >>> implementations with 4.0? >> Well, I really think it is a pity, we should support this. But lets face >> it: up to now we have been unable to do it properly. Sébastien who tried >> to do something in this direction has left the project and nobody >> replaced him. >> > I have done a fair bit of noodling and was unable to come up with a > solution that is performant. > > The issue is that you essentially have to maintain a additional bitmask of > exceptional values in addition to the implicit bitmask of non-zero > elements. I don't see any way of determining that exceptional value > bitmask short of a full scan. Moreover, the cost of propagating the > exceptional value bitmask significantly changes the cost of various > operations because exceptions require an OR while multiplication allows use > of an AND. Furthermore, even after the operation itself and the operation > on the exception bitmask are done, there needs to be another scan of the > results to find new exceptional values. > > > So the upshot is that dealing with this will cost at least a significant > integer degradation in performance at no benefit relative to the normal > user's expectations with regard to sparse vector operations. I say no > benefit because no other package handles this sort of issue so users are > very used to imprecise handling of exceptional values. > So why not just "doc and punt" - document the deficiencies that we know about and the fact that we are not going to try to "fix" them (which, IIUC is what other packages do)?
Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org