A Bunch of Vector questions

[Grant Ingersoll <gs...@apache.org>]

I'm looking into the whole labels thing as well as Vector stuff and  
I'm confused by a couple of things.

1. DirchletMapper assumes DenseVector implementation, no?  Line 45?

2. Shouldn't DenseVector implement equals like SparseVector does?

3. VectorView doesn't appear to implement asFormatString consistently  
with the other Vectors.  Adding:
private static void doTestVectors(Vector left, Vector right) {
     left.setQuick(0, 1);
     left.setQuick(1, 2);
     left.setQuick(2, 3);
     right.setQuick(0, 4);
     right.setQuick(1, 5);
     right.setQuick(2, 6);
     double result = left.dot(right);
     assertEquals(result + " does not equal: " + 32, 32.0, result);
     String formattedString = left.asFormatString();
     System.out.println("Vec: " + formattedString);
     Vector vec = AbstractVector.decodeVector(formattedString);
     assertTrue("vec is null and it shouldn't be", vec != null);
     assertTrue("Vector could not be decoded from the formatString",  
vec.equals(left));
   }

to VectorTest causes a failure for the VectorView test stuff.   
Shouldn't it output the format in a manner consistent with the  
underlying implementation?  Thus, if it is a DenseVector, then it  
outputs that type, else if it is a Sparse it outputs the sparse type.

Thoughts?

-Grant

Re: A Bunch of Vector questions

[Grant Ingersoll <gs...@apache.org>]

On Jun 11, 2009, at 2:43 AM, Sean Owen wrote:

> Why two flavors of this method?
>
> Implementing equals() to return true across classes is indeed
> sometimes tricky or problematic, but here, seems exactly the right
> thing to do, for the same reason two Lists of different
> implementations can be equals().

Hmmm, guess I hadn't thought about it that way.  That makes sense, too.

>
> On Thu, Jun 11, 2009 at 3:15 AM, Grant  
> Ingersoll<gs...@apache.org> wrote:
>> So, I think maybe instead of allowing equals() to return true across
>> implementations, we could add a static method that compares two  
>> Vectors and
>> returns true, something like:
>>
>> static boolean equivalent(Vector a, Vector b)
>>
>>
>> -Grant
>>

Re: A Bunch of Vector questions

[Sean Owen <sr...@gmail.com>]

Why two flavors of this method?

Implementing equals() to return true across classes is indeed
sometimes tricky or problematic, but here, seems exactly the right
thing to do, for the same reason two Lists of different
implementations can be equals().

On Thu, Jun 11, 2009 at 3:15 AM, Grant Ingersoll<gs...@apache.org> wrote:
> So, I think maybe instead of allowing equals() to return true across
> implementations, we could add a static method that compares two Vectors and
> returns true, something like:
>
> static boolean equivalent(Vector a, Vector b)
>
>
> -Grant
>

Re: A Bunch of Vector questions

[Grant Ingersoll <gs...@apache.org>]

On Jun 9, 2009, at 6:36 PM, Grant Ingersoll wrote:

>
> On Jun 9, 2009, at 5:49 PM, Grant Ingersoll wrote:
>
>> I'm looking into the whole labels thing as well as Vector stuff and  
>> I'm confused by a couple of things.
>>
>> 1. DirchletMapper assumes DenseVector implementation, no?  Line 45?
>>
>> 2. Shouldn't DenseVector implement equals like SparseVector does?
>
> And, along those lines, do the equals() implementations really need  
> to be class equivalent?  In other words, isn't it possible to have a  
> SparseVector and a DenseVector containing the same points be  
> equals(), despite what the SparseVector.equals() method implements?   
> Likewise for VectorView?

So, I think maybe instead of allowing equals() to return true across  
implementations, we could add a static method that compares two  
Vectors and returns true, something like:

static boolean equivalent(Vector a, Vector b)


-Grant

Re: A Bunch of Vector questions

[Grant Ingersoll <gs...@apache.org>]

On Jun 9, 2009, at 5:49 PM, Grant Ingersoll wrote:

> I'm looking into the whole labels thing as well as Vector stuff and  
> I'm confused by a couple of things.
>
> 1. DirchletMapper assumes DenseVector implementation, no?  Line 45?
>
> 2. Shouldn't DenseVector implement equals like SparseVector does?

And, along those lines, do the equals() implementations really need to  
be class equivalent?  In other words, isn't it possible to have a  
SparseVector and a DenseVector containing the same points be equals(),  
despite what the SparseVector.equals() method implements?  Likewise  
for VectorView?