Oops.
Right. Not paying full attention this morning. Sorry.
On Mon, Nov 2, 2009 at 2:11 PM, Jake Mannix wrote:
> Er, there already is, right?
--
Ted Dunning, CTO
DeepDyve
Er, there already is, right? RealVector#isNaN() and RealVector#isInfinite()
- they're
just not used anywhere except for as verification purposes in the unit
tests. No
actual internal use as of yet.
-jake
On Mon, Nov 2, 2009 at 1:58 PM, Ted Dunning wrote:
> This makes me think that we need t
This makes me think that we need to have containsNan and containsInfinite
methods on vectors and matrices so that it is easy to check.
On Mon, Nov 2, 2009 at 1:46 PM, Jake Mannix wrote:
> ... Yeah, in my own libraries, I tend to say that either don't force checks
> ever and at most throw unchec
On Mon, Nov 2, 2009 at 1:29 PM, Luc Maisonobe wrote:
> Jake Mannix a écrit :
> > On Mon, Nov 2, 2009 at 9:05 AM, Jake Mannix
> wrote:
> >
> >>> Also, why the special case for
> ArithmeticExcption here, for the zero norm case? Why not just let
> java just
> try to divide, and if i
Jake Mannix a écrit :
> On Mon, Nov 2, 2009 at 9:05 AM, Jake Mannix wrote:
>
>>> Also, why the special case for
ArithmeticExcption here, for the zero norm case? Why not just let
java just
try to divide, and if it divides by zero, well, it'll throw an
ArithmeticException itsel
On Mon, Nov 2, 2009 at 9:05 AM, Jake Mannix wrote:
> > Also, why the special case for
>> > ArithmeticExcption here, for the zero norm case? Why not just let
>> > java just
>> > try to divide, and if it divides by zero, well, it'll throw an
>> > ArithmeticException itself... seems like the whole
On Mon, Nov 2, 2009 at 12:43 PM, Luc Maisonobe wrote:
>
> There are several cases. If you do:
>
> RealVector v = new ArrayRealVector(...);
>
> and later use v, a static analysis would be sufficient to know v is
> really an ArrayRealVector instance.
>
Ok, I was familiar with this, yes, and in thi
Jake Mannix a écrit :
> On Mon, Nov 2, 2009 at 7:41 AM, wrote:
>
>> This is the reason why the boolean is there.
>>
>
> Yeah, I know, my point is that in the current method implementation,
> the boolean is not used properly - it's currently: return new
> ArrayRealVector(v)
> which forces a copy.
On Mon, Nov 2, 2009 at 7:41 AM, wrote:
>
> This is the reason why the boolean is there.
>
Yeah, I know, my point is that in the current method implementation,
the boolean is not used properly - it's currently: return new
ArrayRealVector(v)
which forces a copy. return new ArrayRealVector(v, fals
- "Jake Mannix" a écrit :
> Hey all,
>
> In digging through ArrayRealVector and OpenMapRealVector, while
> trying to
> draw up patches for MATH-312 and MATH-314, I found a number of
> performance (
> and other) issues:
>
> 1) in add(double[]), subtract(double[]), and mapXXX methods, the
Hey all,
In digging through ArrayRealVector and OpenMapRealVector, while trying to
draw up patches for MATH-312 and MATH-314, I found a number of performance (
and other) issues:
1) in add(double[]), subtract(double[]), and mapXXX methods, the idiom is:
double[] v = new double[data.length];
11 matches
Mail list logo
