The replacement of addTo() with .assign(..., Functions.PLUS) might cause
havoc in sparse vectors with dimension Integer.MAX_VALUE as
AbstractVector assign() will run from 0 to Integer.MAX_VALUE.

Should we reintroduce it then?

--sebastian

Why not just override assign() in the sparse subclasses?

On Sep 6, 2011 5:28 AM, "Sebastian Schelter" <[EMAIL PROTECTED]> wrote:

The replacement of addTo() with .assign(..., Functions.PLUS) might cause
havoc in sparse vectors with dimension Integer.MAX_VALUE as
AbstractVector assign() will run from 0 to Integer.MAX_VALUE.

Should we reintroduce it then?

--sebastian

Shouldn't AbstractVector specially detect the plus case and iterate only on
non-zeros?

On Tue, Sep 6, 2011 at 9:59 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> Why not just override assign() in the sparse subclasses?
>
> On Sep 6, 2011 5:28 AM, "Sebastian Schelter" <[EMAIL PROTECTED]> wrote:
>
> The replacement of addTo() with .assign(..., Functions.PLUS) might cause
> havoc in sparse vectors with dimension Integer.MAX_VALUE as
> AbstractVector assign() will run from 0 to Integer.MAX_VALUE.
>
> Should we reintroduce it then?
>
> --sebastian
>

Ah, good point, that's much better.  Although it's still risky: make sure
you special
case Plus, PlusMult, Mult, Div...  I wonder if it's worth it to do a special
case like
this:

  Vector assign(DoubleFunction f) {
    Iterator<Element> it = f.apply(0) == 0
      ? iterateNonZero()
      : iterate();
    // use whichever iterator you got to assign
  }

So if the function would send 0 => 0, go sparsely, else go densely.

  -jake
On Tue, Sep 6, 2011 at 8:24 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> Shouldn't AbstractVector specially detect the plus case and iterate only on
> non-zeros?
>
> On Tue, Sep 6, 2011 at 9:59 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>
> > Why not just override assign() in the sparse subclasses?
> >
> > On Sep 6, 2011 5:28 AM, "Sebastian Schelter" <[EMAIL PROTECTED]> wrote:
> >
> > The replacement of addTo() with .assign(..., Functions.PLUS) might cause
> > havoc in sparse vectors with dimension Integer.MAX_VALUE as
> > AbstractVector assign() will run from 0 to Integer.MAX_VALUE.
> >
> > Should we reintroduce it then?
> >
> > --sebastian
> >
>

Would need to iterate on non-zeros of the argument even, not on the
receiver.

On 06.09.2011 17:24, Ted Dunning wrote:
> Shouldn't AbstractVector specially detect the plus case and iterate only on
> non-zeros?
>
> On Tue, Sep 6, 2011 at 9:59 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>
>> Why not just override assign() in the sparse subclasses?
>>
>> On Sep 6, 2011 5:28 AM, "Sebastian Schelter" <[EMAIL PROTECTED]> wrote:
>>
>> The replacement of addTo() with .assign(..., Functions.PLUS) might cause
>> havoc in sparse vectors with dimension Integer.MAX_VALUE as
>> AbstractVector assign() will run from 0 to Integer.MAX_VALUE.
>>
>> Should we reintroduce it then?
>>
>> --sebastian
>>
>

Ah yes, forgot about which case we were doing.  Simple solution: bring back
addTo().  Why did we get rid of it?

On Tue, Sep 6, 2011 at 9:10 AM, Sebastian Schelter <[EMAIL PROTECTED]> wrote:

> Would need to iterate on non-zeros of the argument even, not on the
> receiver.
>
> On 06.09.2011 17:24, Ted Dunning wrote:
> > Shouldn't AbstractVector specially detect the plus case and iterate only
> on
> > non-zeros?
> >
> > On Tue, Sep 6, 2011 at 9:59 AM, Jake Mannix <[EMAIL PROTECTED]>
> wrote:
> >
> >> Why not just override assign() in the sparse subclasses?
> >>
> >> On Sep 6, 2011 5:28 AM, "Sebastian Schelter" <[EMAIL PROTECTED]> wrote:
> >>
> >> The replacement of addTo() with .assign(..., Functions.PLUS) might cause
> >> havoc in sparse vectors with dimension Integer.MAX_VALUE as
> >> AbstractVector assign() will run from 0 to Integer.MAX_VALUE.
> >>
> >> Should we reintroduce it then?
> >>
> >> --sebastian
> >>
> >
>
>

Because it is redundant.  Jake's testing suggestion is still good.

On Tue, Sep 6, 2011 at 11:21 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> Ah yes, forgot about which case we were doing.  Simple solution: bring back
> addTo().  Why did we get rid of it?
>
>
> On Tue, Sep 6, 2011 at 9:10 AM, Sebastian Schelter <[EMAIL PROTECTED]> wrote:
>
>> Would need to iterate on non-zeros of the argument even, not on the
>> receiver.
>>
>> On 06.09.2011 17:24, Ted Dunning wrote:
>> > Shouldn't AbstractVector specially detect the plus case and iterate only
>> on
>> > non-zeros?
>> >
>> > On Tue, Sep 6, 2011 at 9:59 AM, Jake Mannix <[EMAIL PROTECTED]>
>> wrote:
>> >
>> >> Why not just override assign() in the sparse subclasses?
>> >>
>> >> On Sep 6, 2011 5:28 AM, "Sebastian Schelter" <[EMAIL PROTECTED]> wrote:
>> >>
>> >> The replacement of addTo() with .assign(..., Functions.PLUS) might
>> cause
>> >> havoc in sparse vectors with dimension Integer.MAX_VALUE as
>> >> AbstractVector assign() will run from 0 to Integer.MAX_VALUE.
>> >>
>> >> Should we reintroduce it then?
>> >>
>> >> --sebastian
>> >>
>> >
>>
>>
>

On Tue, Sep 6, 2011 at 9:35 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:

> Because it is redundant.  Jake's testing suggestion is still good.
No, doesn't work.  It works on Vector.assign(DoubleFunction), but totally
fails on
Vector.assign(DoubleDoubleFunction, Vector).  For this, you need to verify
that
f(0, a) == a for all a.  I guess you could try a few, but you could fail,
right?

The only way to know for sure is to have a marker interface for
DoubleDoubleFunction
which designated that it is LeftZeroPreserving or something.

  -jake

That sounds good to me.

Two markers make sense.  LeftZeroUnit and RightZeroUnit.  The right case is
the important optimization although the left case allows the function call
to be omitted.  I suspect that the left optimization would cost more than
the win.

I don't think that these are well described as zero preserving so much as
marking functions as having zero as a right (or left) unit.

On Tue, Sep 6, 2011 at 5:01 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> The only way to know for sure is to have a marker interface for
> DoubleDoubleFunction
> which designated that it is LeftZeroPreserving or something.
>