Indeed, using the version of poly/test.c from the repository fixes the
issue.
Thanks,
Victor
On Mon, Aug 18, 2014 at 3:06 PM, Patrick Alken <patrick.al...@colorado.edu>
wrote:
> This should be fixed on the git repository (see bug #39055), though it may
> be that the tolerances need adjusting for your system.
>
>
> On 08/18/2014 04:02 PM, victor.zverov...@gmail.com wrote:
>
>> There is another test failure of a similar kind, but now without any -O
>> flags:
>>
>> $ ./configure CFLAGS=
>> $ make
>> $ poly/test
>> FAIL: z1.real, 15th-order polynomial (-0.999999999999994227 observed vs 1
>> expected) [159]
>> FAIL: z2.real, 15th-order polynomial (1.00000005616458409 observed vs -1
>> expected) [161]
>> FAIL: z13.real, 15th-order polynomial (1.99999988977862886 observed vs 2
>> expected) [183]
>> FAIL: z14.real, 15th-order polynomial (2.00000011022135338 observed vs 2
>> expected) [185]
>>
>> Victor
>>
>>
>> On Mon, Aug 18, 2014 at 2:48 PM, victor.zverov...@gmail.com <
>> victor.zverov...@gmail.com> wrote:
>>
>> Thanks for quick responses guys.
>>>
>>> Patrick, please find attached the patch that implements your suggestion
>>> which does fix the test failures. I've
>>> reused GSL_EIGEN_SORT_VAL_{ASC,DESC}, that were previously unused for
>>> complex numbers, for the new type of comparison.
>>>
>>> Victor
>>>
>>>
>>>
>>> On Mon, Aug 18, 2014 at 12:21 PM, Patrick Alken <
>>> patrick.al...@colorado.edu> wrote:
>>>
>>> GSL is already sorting the eigenvalues based on magnitude, so the
>>>> problem
>>>> seems to be that with the extra -O3 optimization, the gsl_eigen_gen and
>>>> gsl_eigen_genv routines are producing slightly different results,
>>>> leading
>>>> to a different sorting order. One way to fix this would be to sort by
>>>> real
>>>> part first and then by imaginary part, but it may be a little while
>>>> until I
>>>> can look into this further.
>>>>
>>>> Patrick
>>>>
>>>>
>>>> On 08/18/2014 12:59 PM, Martin Jansche wrote:
>>>>
>>>> I'm not sure if GSL makes any guarantees about the direction of
>>>>> eigenvectors. It looks like the test might pass if one only looks at
>>>>> the
>>>>> magnitude of the values. Perhaps the test could be made robust against
>>>>> sign
>>>>> changes by looking at absolute values.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 18, 2014 at 1:53 PM, victor.zverov...@gmail.com <
>>>>> victor.zverov...@gmail.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>>> I noticed that eigen test fails on 32-bit Linux (x86) when compiled
>>>>>> with
>>>>>> -O3 flag:
>>>>>>
>>>>>> $ ./configure CFLAGS="-O3"
>>>>>> $ make
>>>>>> $ eigen/test
>>>>>> FAIL: gen, direct eigenvalue(4) imag, random (-0.481216772353650846
>>>>>> observed vs 0.481216772353650846 expected) [877968]
>>>>>> FAIL: gen, direct eigenvalue(5) imag, random (0.481216772353650901
>>>>>> observed
>>>>>> vs -0.481216772353650846 expected) [877970]
>>>>>> FAIL: gen, direct eigenvalue(15) imag, random (6.85872455924790447
>>>>>> observed
>>>>>> vs -6.85872455924790536 expected) [877990]
>>>>>> FAIL: gen, direct eigenvalue(16) imag, random (-6.85872455924790536
>>>>>> observed vs 6.85872455924790625 expected) [877992]
>>>>>>
>>>>>> I'm using GSL version 1.16, 32-bit Ubuntu 10.04 and GCC 4.4.3.
>>>>>>
>>>>>> Best regards,
>>>>>> Victor
>>>>>>
>>>>>>
>>>>>>
>>>>
>
>
