commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <kber...@gmail.com>
Subject Re: [math] Re: Sparse matrices not supported anymore?
Date Sat, 09 Nov 2013 12:02:53 GMT
+1
On Nov 8, 2013 3:28 PM, "Thomas Neidhart" <thomas.neidhart@gmail.com> 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 <luc@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)?
>
> +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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message