OK I have ready the changes described in this thread, but I didn't go
ahead with removing "quick" methods. It proved to be a very large
change, and, there were some situations where it looks like we need to
think a little harder about what to do with the resulting code; it's
not really just a matte
IN fact, setQuick could be viewed as a performance degrading option since it
leads people to imagine that they have "optimized" their code. set() is
generally inlined and the bounds checks are often lifted out of the loop so
there would be no difference. As Sean suggest, however, there is a huge
I don't claim that an 'end-user' has much business. Just a
class-that-extends. I'll all for your proposed names. Watch out for
'zero' if the 'default' value is in fact configurable.
On Mon, Jun 15, 2009 at 7:54 PM, Sean Owen wrote:
> Yeah exactly, not entirely clear why the *caller* should care ab
Yeah exactly, not entirely clear why the *caller* should care about
this; the class should take care of stuff like that.
At least I propose a rename of size() to getNumNonzeroElements() or
somesuch, and rename of cardinality() to size().
On Tue, Jun 16, 2009 at 12:46 AM, Benson Margulies wrote:
>
Lets say you have an algorithm in which a vector starts out sparse,
but gradually fills in. At some point, you want to give up and switch
to an ordinary vector. This came up in Brown and DiPietro's
entropy-based bigram information word clustering algorithm, and I
think it could come up elsewhere.
I don't dispute it but what is the use case? I am mostly curious at this point.
On Tue, Jun 16, 2009 at 12:40 AM, Benson Margulies wrote:
> The 'numberOfNonDefaultValueElements' is useful. I'd give it an
> accessor, with, well, that very name.
>
> On Mon, Jun 15, 2009 at 5:20 PM, Sean Owen wrote:
The 'numberOfNonDefaultValueElements' is useful. I'd give it an
accessor, with, well, that very name.
On Mon, Jun 15, 2009 at 5:20 PM, Sean Owen wrote:
> OK don't want to push on this last bit too much, but I still see a
> small concern here.
>
> I think it will be error-prone to call this method
OK don't want to push on this last bit too much, but I still see a
small concern here.
I think it will be error-prone to call this method size(). On Vector,
I would strongly expect that this tells me the logical number of
elements of the vector -- which is its cardinality. This is what
seeing meth
Sean Owen wrote:
On Mon, Jun 15, 2009 at 4:17 PM, Jeff Eastman wrote:
The difference is getQuick does not check bounds.
This does make sense for practical reasons. From an API perspective,
seems like it's slightly undesirable to have two of these methods, one
of which exists just to by
On Mon, Jun 15, 2009 at 4:17 PM, Jeff Eastman wrote:
> The difference is getQuick does not check bounds.
This does make sense for practical reasons. From an API perspective,
seems like it's slightly undesirable to have two of these methods, one
of which exists just to bypass the checks, as it migh
Sean Owen wrote:
While leafing through the Vector API today, I had a few questions...
toArray() -- should we really have this? the values, without the
dimensions/indices, don't seem necessarily meaningful. It is used in
one place, DenseMatrix.assignRow(), but seems like there is a
potential bug
11 matches
Mail list logo
