Matrix and Vector class structure

[Lance Norskog <go...@gmail.com>]

Working through Vector/Matrix classes I found a lot of things that
could be tightened.

-Would it be worthwhile to change the Vector and Matrix structures so
that things like "sparse against dense" and popped in a central place?
For example, Vector would have a few methods, and there would be a new
"VectorOps" class. The latter implements "sparse v.s. dense" using the
classes of input vectors.

For example, DenseVector currently has "if the other is DenseVector,
here is the fast path" code bits. Under this redo, there is a
DenseDense operator. Vector.multiply(vector, vector)  is a static
method that pulls the classes of the inputs, and finds the DenseDense
version.

Yes, it would be an invasive patch.

Lance Norskog
goksron@gmail.com

Re: Matrix and Vector class structure

[Ted Dunning <te...@gmail.com>]

Yeah...

The other classic approach is to implement an inverted operation.  The
problem is to figure out what to dispatch to.  Using an Op class helps a bit
because polymorphism might let you dispatch based on two operands.  In our
case, it doesn't help much at all because everything inherits from Vector or
Matrix anyway so we get no automagical dispatch at all.

Pretty much the best we can do is implement special cases in sub-classes of
Vector and Matrix which try to guess when a reversed dispatch might actually
be more useful.

For the most part this is pretty trivial since we only have to major cases
(isDense() and !isDense()).  There is the secondary case of randomly
accessible sparse vectors versus sequentially accessible sparse vectors, but
I think that we mostly have things covered for the important cases.

On Sat, May 21, 2011 at 4:53 PM, Hector Yee <he...@gmail.com> wrote:

> Could use the visitor pattern and have the visitor implement the logic.
>
> On Sun, May 22, 2011 at 4:07 AM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > This is an instance of the classic double dispatch problem.
> >
> > There are no really good answers in single dispatch languages like Java.
> >  My
> > own opinion is that there aren't a lot of good answers in multi-dispatch
> > languages either.
> >
> > For now, I think that access to the private data trumps other
> > considerations.
> >
> > On Fri, May 20, 2011 at 9:53 PM, Jake Mannix <ja...@gmail.com>
> > wrote:
> >
> > > Hmmm... standard OO practice would be "keep the logic specific to the
> > > impl with the impl".  Also: this could get really ugly, due to proper
> > > encapsulation
> > > we currently have, if not impossible: do to DenseDense things most
> fast,
> > > you
> > > would need access to the (rightfully) private double[].
> > >
> > > I'm not sure what would be gained...
> > >
> > >  -jake
> > >
> > > On Fri, May 20, 2011 at 9:31 PM, Lance Norskog <go...@gmail.com>
> > wrote:
> > >
> > > > Working through Vector/Matrix classes I found a lot of things that
> > > > could be tightened.
> > > >
> > > > -Would it be worthwhile to change the Vector and Matrix structures so
> > > > that things like "sparse against dense" and popped in a central
> place?
> > > > For example, Vector would have a few methods, and there would be a
> new
> > > > "VectorOps" class. The latter implements "sparse v.s. dense" using
> the
> > > > classes of input vectors.
> > > >
> > > > For example, DenseVector currently has "if the other is DenseVector,
> > > > here is the fast path" code bits. Under this redo, there is a
> > > > DenseDense operator. Vector.multiply(vector, vector)  is a static
> > > > method that pulls the classes of the inputs, and finds the DenseDense
> > > > version.
> > > >
> > > > Yes, it would be an invasive patch.
> > > >
> > > > Lance Norskog
> > > > goksron@gmail.com
> > > >
> > >
> >
>
>
>
> --
> Yee Yang Li Hector
> http://hectorgon.blogspot.com/ (tech + travel)
> http://hectorgon.com (book reviews)
>

Re: Matrix and Vector class structure

[Hector Yee <he...@gmail.com>]

Could use the visitor pattern and have the visitor implement the logic.

On Sun, May 22, 2011 at 4:07 AM, Ted Dunning <te...@gmail.com> wrote:

> This is an instance of the classic double dispatch problem.
>
> There are no really good answers in single dispatch languages like Java.
>  My
> own opinion is that there aren't a lot of good answers in multi-dispatch
> languages either.
>
> For now, I think that access to the private data trumps other
> considerations.
>
> On Fri, May 20, 2011 at 9:53 PM, Jake Mannix <ja...@gmail.com>
> wrote:
>
> > Hmmm... standard OO practice would be "keep the logic specific to the
> > impl with the impl".  Also: this could get really ugly, due to proper
> > encapsulation
> > we currently have, if not impossible: do to DenseDense things most fast,
> > you
> > would need access to the (rightfully) private double[].
> >
> > I'm not sure what would be gained...
> >
> >  -jake
> >
> > On Fri, May 20, 2011 at 9:31 PM, Lance Norskog <go...@gmail.com>
> wrote:
> >
> > > Working through Vector/Matrix classes I found a lot of things that
> > > could be tightened.
> > >
> > > -Would it be worthwhile to change the Vector and Matrix structures so
> > > that things like "sparse against dense" and popped in a central place?
> > > For example, Vector would have a few methods, and there would be a new
> > > "VectorOps" class. The latter implements "sparse v.s. dense" using the
> > > classes of input vectors.
> > >
> > > For example, DenseVector currently has "if the other is DenseVector,
> > > here is the fast path" code bits. Under this redo, there is a
> > > DenseDense operator. Vector.multiply(vector, vector)  is a static
> > > method that pulls the classes of the inputs, and finds the DenseDense
> > > version.
> > >
> > > Yes, it would be an invasive patch.
> > >
> > > Lance Norskog
> > > goksron@gmail.com
> > >
> >
>



-- 
Yee Yang Li Hector
http://hectorgon.blogspot.com/ (tech + travel)
http://hectorgon.com (book reviews)

Re: Matrix and Vector class structure

[Ted Dunning <te...@gmail.com>]

This is an instance of the classic double dispatch problem.

There are no really good answers in single dispatch languages like Java.  My
own opinion is that there aren't a lot of good answers in multi-dispatch
languages either.

For now, I think that access to the private data trumps other
considerations.

On Fri, May 20, 2011 at 9:53 PM, Jake Mannix <ja...@gmail.com> wrote:

> Hmmm... standard OO practice would be "keep the logic specific to the
> impl with the impl".  Also: this could get really ugly, due to proper
> encapsulation
> we currently have, if not impossible: do to DenseDense things most fast,
> you
> would need access to the (rightfully) private double[].
>
> I'm not sure what would be gained...
>
>  -jake
>
> On Fri, May 20, 2011 at 9:31 PM, Lance Norskog <go...@gmail.com> wrote:
>
> > Working through Vector/Matrix classes I found a lot of things that
> > could be tightened.
> >
> > -Would it be worthwhile to change the Vector and Matrix structures so
> > that things like "sparse against dense" and popped in a central place?
> > For example, Vector would have a few methods, and there would be a new
> > "VectorOps" class. The latter implements "sparse v.s. dense" using the
> > classes of input vectors.
> >
> > For example, DenseVector currently has "if the other is DenseVector,
> > here is the fast path" code bits. Under this redo, there is a
> > DenseDense operator. Vector.multiply(vector, vector)  is a static
> > method that pulls the classes of the inputs, and finds the DenseDense
> > version.
> >
> > Yes, it would be an invasive patch.
> >
> > Lance Norskog
> > goksron@gmail.com
> >
>

Re: Matrix and Vector class structure

[Jake Mannix <ja...@gmail.com>]

Hmmm... standard OO practice would be "keep the logic specific to the
impl with the impl".  Also: this could get really ugly, due to proper
encapsulation
we currently have, if not impossible: do to DenseDense things most fast,
you
would need access to the (rightfully) private double[].

I'm not sure what would be gained...

  -jake

On Fri, May 20, 2011 at 9:31 PM, Lance Norskog <go...@gmail.com> wrote:

> Working through Vector/Matrix classes I found a lot of things that
> could be tightened.
>
> -Would it be worthwhile to change the Vector and Matrix structures so
> that things like "sparse against dense" and popped in a central place?
> For example, Vector would have a few methods, and there would be a new
> "VectorOps" class. The latter implements "sparse v.s. dense" using the
> classes of input vectors.
>
> For example, DenseVector currently has "if the other is DenseVector,
> here is the fast path" code bits. Under this redo, there is a
> DenseDense operator. Vector.multiply(vector, vector)  is a static
> method that pulls the classes of the inputs, and finds the DenseDense
> version.
>
> Yes, it would be an invasive patch.
>
> Lance Norskog
> goksron@gmail.com
>