[Pkg-octave-devel] Errors in octave-signal's testsuite

Jordi Gutiérrez Hermoso jordigh at octave.org
Thu Mar 15 20:54:42 UTC 2012


On 15 March 2012 13:11, Thomas Weber <tweber at debian.org> wrote:
> On Thu, Mar 15, 2012 at 12:48:53AM +0100, Rafael Laboissiere wrote:
>> * Thomas Weber <tweber at debian.org> [2012-03-14 19:56]:
>>
>> > On Wed, Mar 14, 2012 at 08:58:20AM +0100, Rafael Laboissiere wrote:
>> > > Since I get the same values for a and b as yours, the only conceivable
>> > > source of divergence is the filter function.  What does "which filter"
>> > > yield for you?
>> >
>> > I've put a .mat file with the variables after running your commands at
>> > http://people.debian.org/~tweber/logs/pei_tseng_notch.mat.lzma
>> >
>> > Can you compare the variables with your workspace?
>>
>> As I suspected, the divergence between your data and mine happen in
>> the filter function.  I assume that we are using the same one, in
>> /usr/lib/i386-linux-gnu/octave/3.6.1/oct/i486-pc-linux-gnu/filter.oct
>
> Yes, although mine is in the 64 bit location.
>
>> The only difference that I can imagine between our systems is the
>> precision.  I am using a 32-bits system and I guess you are using a
>> 64-bit system.  Which is the value of eps in your system?
>
> octave:2> format long
> octave:3> eps
> ans =  2.22044604925031e-16

Guys, std::numeric_limits<double>::epsilon() doesn't depend on the
computer architecture that way... It's the same value in any IEEE
754-conforming hardware, and it's next to impossible to find any
nowadays that does floating point operations without being
conformant...

- Jordi G. H.



More information about the Pkg-octave-devel mailing list