On Thu, Nov 28, 2013 at 12:42 PM, Emmanuel Bourg wrote:
> "Rationale: each instance variable gets initialized twice, to the same
> value. Java initializes each instance variable to its default value (0
> or null) before performing any initialization specified in the code. So
> in this case, x gets
On Sun, Nov 24, 2013 at 7:22 AM, Phil Steitz wrote:
>> Are there any objections to changing the API sigs from foo(double[] values)
>> to foo(double... values) ?
>
> Yes. I am -0 for adding new methods that take varargs; -1 for
> removing the double[] versions.
Phil note that foo(double... value
For background, see https://issues.apache.org/jira/browse/MATH-1053
The issue is what to do when QRDecomposition is used on a tall, skinny
matrix (m rows > n cols), and getSolver().getInverse() is called.
Right now a DimensionMismatchException is thrown, which is almost
certainly not intended.
Th
On Sun, Nov 3, 2013 at 1:43 PM, Gilles wrote:
> A case that occurs often is "zero" (as "double").
> I prefer "0d".
(I'm certainly not going to propose to change it, but my personal
preference is 0.0 because it's obviously decimal even to newbies and
can't be confused with a hex value. But this is
On Sun, Nov 3, 2013 at 4:17 AM, Ted Dunning wrote:
> Does this actually matter after the JIT takes hold? And if the JIT doesn't
> care to optimize this away, does it even matter?
Unclear. There aren't hard guarantees about what the JIT does, but
transformations like this should be easy and local
On Sat, Nov 2, 2013 at 4:49 PM, Phil Steitz wrote:
> If the improvements make a material difference [1], by all means
> open tickets and submit patches. If they are just cosmetic, my
> personal opinion is this should be done in small commits
> incrementally if at all [2]. It is OK to open master
more until
it's clear we're getting too fine-grained.
I'll do this over time since some changes will affect the same files
or sections of code.
On Sat, Nov 2, 2013 at 3:03 PM, Gilles wrote:
> On Sat, 2 Nov 2013 14:52:34 +, Sean Owen wrote:
>>
>> In Math, is t
In Math, is there any appetite for large patches containing many
instances of particular micro-optimizations? Examples:
- Replace:
a[i][j] = a[i][j] + foo;
with:
a[i][j] += foo;
… which is faster/leaner in the byte code by a little bit. It might
make a difference in many nested, tight
On Sun, Oct 27, 2013 at 10:41 AM, Luc Maisonobe wrote:
>>> +return 743 + 809 * + 233 * MathUtils.hash(value) + 167 *
>> ^^
>> Typo?
>
> Yes. I don't even understand why this code does not raise a compilation
> error ...
>
> Thanks for spotting this. Everythin
one stops early, always.
On Wed, Oct 23, 2013 at 4:50 PM, Ted Dunning wrote:
> On Wed, Oct 23, 2013 at 3:14 PM, Sean Owen wrote:
>
>> EigenDecomposition resembles QR in this respect, as far as they are
>> implemented here. This argues for them to treat arguments similarly.
>&g
t on the the Solver created by getSolver().
>
> Imho, it would be more logical to chose the singularity threshold when
> calling getSolver() for the respective decomposition, that way we could
> also add it to the EigenDecomposition class.
>
> Thomas
>
>
> On Wed,
In MATH-1045 (https://issues.apache.org/jira/browse/MATH-1045) we have
discussed adding a zero threshold tolerance to EigenDecomposition just
like QRDecomposition has. This involves adding a new constructor with
a new double parameter.
Just one problem: there's already such a constructor:
/**
On Sat, Oct 19, 2013 at 5:51 PM, Phil Steitz wrote:
> Investigation / tests / documentation much appreciated.
>
> Thanks for looking into this!
OK Phil I'll have another go. I would like to propose three patches
(three JIRAs?)
1. The javadoc updates discussed on this thread, which I really
would
On Sat, Oct 19, 2013 at 12:21 AM, Phil Steitz wrote:
> The decomposition solvers can "invert" non-square matrices. There
> is no documentation describing what exactly is being returned in
> these cases. It is not obvious to me exactly what conditions the
> returned value satisfies in each case w
On Thu, Oct 17, 2013 at 11:05 AM, Gilles wrote:
> "sortInPlace" should not be made any slower only for the sake of using a
> _generally_ correct implementation of "Comparator". The implementation in
> "sortInPlace" is quite correct for the task at hand.
I buy that -- but my point here was just th
On Wed, Oct 16, 2013 at 11:23 PM, Gilles wrote:
> Consequently, the lexicographic comparator will definitely be slower since
> it
> will needlessly spend time ordering the values.
Yeah if value's compareTo() is expensive, this could hurt. Here, for an
Integer value it's going to be a rounding er
No, it's the current implementation that is technically wrong. Pair.java
defines equality as equality of both keys and values. Comparator orderings
are supposed to be consistent with equals() (
http://docs.oracle.com/javase/7/docs/api/java/util/Comparator.html). That
is, two Pairs should be equal i
You are right that it adds 1 or 2 more branches per comparison. The new
Comparator would at least be consistent with equals(), though it probably
doesn't matter for correctness in practice.
I am interested in closing this minor issue so I suggest you ignore this
part if you guess that this overhea
On Wed, Oct 16, 2013 at 9:52 AM, Gilles wrote:
> I think the Comparator can also replace a
>> custom one in MathArrays.
>>
>
> Are you sure?
>
Yes, at least tests pass. There are two anonymous comparator classes there
which compare by key. The new Comparator compares by key too (and by value,
bu
On Wed, Oct 16, 2013 at 1:13 AM, Phil Steitz wrote:
> On 10/15/13 2:51 PM, Sean Owen wrote:
> > Hello all,
> >
> > I'd like to propose a few small additions to the Pair class in Common
> > Math3: a factory method, to avoid redundant generics-related
> eclarati
Hello all,
I'd like to propose a few small additions to the Pair class in Common
Math3: a factory method, to avoid redundant generics-related eclarations, a
toString() method, and a basic Comparator.
It's already pretty well summarized, simple as it is, at
https://issues.apache.org/jira/browse/MA
21 matches
Mail list logo
