On 8/26/13 4:37 AM, Gilles wrote:
> On Sun, 25 Aug 2013 17:14:37 -0700, Phil Steitz wrote:
>> On 8/25/13 9:59 AM, Gilles wrote:
>>> On Sun, 25 Aug 2013 09:19:41 -0700, Phil Steitz wrote:
On 8/25/13 8:10 AM, Gilles wrote:
> On Sat, 24 Aug 2013 21:55:36 -, pste...@apache.org wrote:
>
On 8/25/13 11:15 PM, Ted Dunning wrote:
> I think that it will be somewhat slower, but next to imperceptibly so.
>
> It will not be any more accurate.
>
> It should be noted, however, that this code will fail for input longer than
> 2^16 because of integer overflow.
Good point. We should either c
On 8/26/13 11:28 AM, Oliver Heger wrote:
> Am 26.08.2013 16:18, schrieb Phil Steitz:
>>
>> On Aug 26, 2013, at 7:38 PM, Oliver Heger
>> wrote:
>>
>>> Am 25.08.2013 18:45, schrieb Adrian Crum:
+1
-Adrian
On 8/25/2013 9:26 AM, James Carman wrote:
> AtomicReference?
>>>
In regards to your first comments. I do not understand your point. You
are implementing large API changes, but refuse to take the final step
that would tie everything together and make it robust for future
changes.
In regards to second comments, you can make it whatever interface
hierarchy that yo
On a side note. Given a derivative structure ds. Wouldn't it be nice to
generate a constant derivative structure with something like:
ds.getConstant(dobule value);
Currently I"m doing something like:
new DerivativeStructure(length, order, value); ... seesm more verbose than
necessary when I have
On 08/26/2013 03:33 PM, Gilles wrote:
> On Mon, 26 Aug 2013 13:59:32 -0400, Evan Ward wrote:
>> Hi again,
>>
>> I rearranged the least squares package and I've posted the results.[1]
>> I've also created a pull request[2] and an associated issue.[3]
>>
>> [1] https://github.com/wardev/commons-math
On Mon, 26 Aug 2013 15:11:22 -0400, Konstantin Berlin wrote:
I looked only at the GuassNewton class as a general guide to how
things work. I like it a lot! I only wish all of the optimizations
were rewritten in this way.
Several comments
1) I believe this code can now be simplified
// build th
On Mon, 26 Aug 2013 13:59:32 -0400, Evan Ward wrote:
Hi again,
I rearranged the least squares package and I've posted the
results.[1]
I've also created a pull request[2] and an associated issue.[3]
[1] https://github.com/wardev/commons-math/tree/sepOpt
[2] https://github.com/apache/commons-ma
I looked only at the GuassNewton class as a general guide to how
things work. I like it a lot! I only wish all of the optimizations
were rewritten in this way.
Several comments
1) I believe this code can now be simplified
// build the linear problem
final double[] b = new double[nC];
Am 26.08.2013 16:18, schrieb Phil Steitz:
>
>
> On Aug 26, 2013, at 7:38 PM, Oliver Heger
> wrote:
>
>> Am 25.08.2013 18:45, schrieb Adrian Crum:
>>> +1
>>>
>>> -Adrian
>>>
>>> On 8/25/2013 9:26 AM, James Carman wrote:
AtomicReference?
>>
>> There are multiple aspects here. One is the saf
Hi again,
I rearranged the least squares package and I've posted the results.[1]
I've also created a pull request[2] and an associated issue.[3]
[1] https://github.com/wardev/commons-math/tree/sepOpt
[2] https://github.com/apache/commons-math/pull/1
[3] https://issues.apache.org/jira/browse/MATH-
GitHub user wardev opened a pull request:
https://github.com/apache/commons-math/pull/1
Separate optimization problem from algorithm in the least squares package
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/wardev/commons-math
I'm a fan of the "bean-based" approach (no static methods). Seems
cleaner to me.
On Mon, Aug 26, 2013 at 10:08 AM, Oliver Heger
wrote:
> Am 25.08.2013 18:45, schrieb Adrian Crum:
>> +1
>>
>> -Adrian
>>
>> On 8/25/2013 9:26 AM, James Carman wrote:
>>> AtomicReference?
>
> There are multiple aspec
With regards to what is happening in DsCompiler.pow():
IMHO, when a==0 and x>=0 the function is well behaved because log|a| -> Inf
slower than a^x -> 0. I got to this by simulation.
One could probably get to something more conclusive using L'Hopital rule :
http://en.wikipedia.org/wiki/L%27H%C3%B4pi
On Mon, 26 Aug 2013 10:04:01 -0400, Konstantin Berlin wrote:
I think I like this approach a lot more.
One thing that is left out, and we discussed a lot, is the need to
support vector operations. This can also be done as an additional
interface. This is critical since it forms the basic building
On Aug 26, 2013, at 7:38 PM, Oliver Heger wrote:
> Am 25.08.2013 18:45, schrieb Adrian Crum:
>> +1
>>
>> -Adrian
>>
>> On 8/25/2013 9:26 AM, James Carman wrote:
>>> AtomicReference?
>
> There are multiple aspects here. One is the safe publishing of a value
> written into the member field. Th
Am 25.08.2013 18:45, schrieb Adrian Crum:
> +1
>
> -Adrian
>
> On 8/25/2013 9:26 AM, James Carman wrote:
>> AtomicReference?
There are multiple aspects here. One is the safe publishing of a value
written into the member field. This can be achieved by atomic
references, synchronization, or a vola
I think I like this approach a lot more.
One thing that is left out, and we discussed a lot, is the need to
support vector operations. This can also be done as an additional
interface. This is critical since it forms the basic building block
upon which all higher level matrix operations rely on. I
On Sun, 25 Aug 2013 17:14:37 -0700, Phil Steitz wrote:
On 8/25/13 9:59 AM, Gilles wrote:
On Sun, 25 Aug 2013 09:19:41 -0700, Phil Steitz wrote:
On 8/25/13 8:10 AM, Gilles wrote:
On Sat, 24 Aug 2013 21:55:36 -, pste...@apache.org wrote:
[...]
I wonder whether the utility should involve
On Mon, 26 Aug 2013 01:05:12 -, dbros...@apache.org wrote:
Author: dbrosius
Date: Mon Aug 26 01:05:11 2013
New Revision: 1517404
URL: http://svn.apache.org/r1517404
Log:
remove dead store to 'resultb'
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/FastMath
Ajo Fod a écrit :
>Are you saying patched the code? Can you provide the link?
I committed it in the development version. You just have to update your checked
out copy from either the official
Apache subversion repository or the git mirror we talked about in a previous
thread.
The new metho
21 matches
Mail list logo