+1 On Nov 8, 2013 3:28 PM, "Thomas Neidhart" <[email protected]> wrote:
> On 11/08/2013 09:20 PM, Phil Steitz wrote: > > On 11/8/13 11:59 AM, Ted Dunning wrote: > >> On Fri, Nov 8, 2013 at 11:47 AM, Luc Maisonobe <[email protected]> > 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)? > > +1, I think removing the sparse matrix implementations w/o an > alternative will leave a lot of users quite puzzled. > > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
