You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2011/08/06 02:28:58 UTC
[Math] linearCombination (Was: Re: svn commit: r1154250 - [...])
> [...]
I've allowed myself to adapt your code to an array version of the
accurate "linearCombination" (committed in revision 1154416).
Here is a micro-benchmark (for an array of length 3):
-----
linearCombination (runs per timed block: 10000, timed blocks: 1000)
direct inline: 1.789185e-05 (1.580520e-05) ms
direct array: 2.009243e-05 (1.257636e-05) ms
accurate inline: 4.244761e-05 (5.882379e-05) ms
accurate array: 9.365895e-05 (6.902221e-05) ms
-----
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] linearCombination
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> [...]
> >
> >However, I'm concerned that the "stress" test ("testLinearCombination1")
> >taken from your test case for Vector3D might not be stringent enough. [I
> >think that while changing my implemementation, the test was still passing
> >just before I dicovered that I was using an unitialized (set to 0 by
> >default) variable.]
> >Could you devise one sure to detect bugs like this (i.e. where all the
> >various variables in "linearCombination" would be significant)?
>
> I think we could try something like generating randomly the first
> n-1 components of a and b arrays as high accuracy Dfp, then set up
> the last component of each array so that the higher bits cancels out
> and some non-zero lower bits remains. The Dfp computations would
> represent reference values and we would check if the method can
> retrieve at least some of the lower bits. With a large number of
> different arrays (say a few hundreds, with a few dozen elements
> each), this would stress the algorithm.
>
> Does this make sense ?
Maybe, but I can't look at Dfp for now. So I'll let you try ;-).
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] linearCombination
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 06/08/2011 13:15, Gilles Sadowski a écrit :
> Hi.
>
>>> [...]
>>
>> I've allowed myself to adapt your code to an array version of the
>> accurate "linearCombination" (committed in revision 1154416).
Thanks Gilles,
I wanted to add this too and simply forgot :-(
>>
>> Here is a micro-benchmark (for an array of length 3):
>> -----
>> linearCombination (runs per timed block: 10000, timed blocks: 1000)
>> direct inline: 1.789185e-05 (1.580520e-05) ms
>> direct array: 2.009243e-05 (1.257636e-05) ms
>> accurate inline: 4.244761e-05 (5.882379e-05) ms
>> accurate array: 9.365895e-05 (6.902221e-05) ms
>> -----
>
> Mre efficient implementation in revision 1154485:
> -----
> linearCombination (runs per timed block: 10000, timed blocks: 1000)
> direct inline: 1.899314e-05 (5.587518e-05) ms
> direct array: 1.918198e-05 (1.133822e-05) ms
> accurate inline: 4.178593e-05 (5.697845e-05) ms
> accurate array: 7.144897e-05 (3.897243e-05) ms
> -----
>
> However, I'm concerned that the "stress" test ("testLinearCombination1")
> taken from your test case for Vector3D might not be stringent enough. [I
> think that while changing my implemementation, the test was still passing
> just before I dicovered that I was using an unitialized (set to 0 by
> default) variable.]
> Could you devise one sure to detect bugs like this (i.e. where all the
> various variables in "linearCombination" would be significant)?
I think we could try something like generating randomly the first n-1
components of a and b arrays as high accuracy Dfp, then set up the last
component of each array so that the higher bits cancels out and some
non-zero lower bits remains. The Dfp computations would represent
reference values and we would check if the method can retrieve at least
some of the lower bits. With a large number of different arrays (say a
few hundreds, with a few dozen elements each), this would stress the
algorithm.
Does this make sense ?
Luc
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] linearCombination
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > [...]
>
> I've allowed myself to adapt your code to an array version of the
> accurate "linearCombination" (committed in revision 1154416).
>
> Here is a micro-benchmark (for an array of length 3):
> -----
> linearCombination (runs per timed block: 10000, timed blocks: 1000)
> direct inline: 1.789185e-05 (1.580520e-05) ms
> direct array: 2.009243e-05 (1.257636e-05) ms
> accurate inline: 4.244761e-05 (5.882379e-05) ms
> accurate array: 9.365895e-05 (6.902221e-05) ms
> -----
Mre efficient implementation in revision 1154485:
-----
linearCombination (runs per timed block: 10000, timed blocks: 1000)
direct inline: 1.899314e-05 (5.587518e-05) ms
direct array: 1.918198e-05 (1.133822e-05) ms
accurate inline: 4.178593e-05 (5.697845e-05) ms
accurate array: 7.144897e-05 (3.897243e-05) ms
-----
However, I'm concerned that the "stress" test ("testLinearCombination1")
taken from your test case for Vector3D might not be stringent enough. [I
think that while changing my implemementation, the test was still passing
just before I dicovered that I was using an unitialized (set to 0 by
default) variable.]
Could you devise one sure to detect bugs like this (i.e. where all the
various variables in "linearCombination" would be significant)?
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org