Re: [eigen] Re: Eigen beta test errors |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Re: Eigen beta test errors
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Mon, 5 Jul 2010 09:40:44 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p05iSQ5GpcBRCwSnke6o7YIYV5YKv+w3ljtaH3Y0f5w=; b=Mqkr7z4HgD1p3OP8Mja4kLEbtwj3upBTiJb/nCCDZWoqF1RUHj8v1FYsilfSJRUEjQ zt0phm/3y6PvBxXYp8xbEh8Tbot9ZXigHhHKf9WUlw08/gvLtrXjdW4rcF2Uk4konswg gnWMuK6WR1Qd++mpBm2W7HqG54CmfZD1ItdTc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=E8fjFu2NBQnDNg2xdcwojsUaW8DjuFgPz/CKOMhhUTA7gIRrF1Wi0U4WCDRV/7IztY ow8q+C19pGXOSBsSP95oyG6n6P5Wfbh4QCKE6IY0A96ykvNi8CouQYxUmcNhsVjNMQxJ 6vrNBNz7Tr51fR9BHVN+jts7cSnpcJaclY3eY=
What was the error? Was it really 32bit specific or was it something
that a suitable unit test could detect on other platforms?
Benoit
2010/7/5 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> product_syrk_1 is fixed.
>
> I can also reproduce packetmath_1 by running it a very large number of
> times, but there is nothing critical here... it fails on stuff like:
> 0.00128718 is not approx to 0.00128716.... so that's fine.
>
> Same for SVD.
>
> It is "normal" that some tests randomly fail. Well, these tests should
> be fixed, but the problem is not in Eigen itself.
>
> gael
>
> On Mon, Jul 5, 2010 at 6:07 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> On linux x86-64 with gcc 4.4.4, I can't reproduce any of these issues.
>>
>> So they are probably 32bit-specific. Can anybody try these tests on
>> linux x86-32 and confirm? I don't have multilib working (one of many
>> fedora annoyances) so I can't try.
>>
>> I tried -mfpmath=387 and that didn't make any difference: I still
>> couldn't reproduce the failures.
>>
>> Can you also check that you are testing the latest revision from hg
>> (hg diff should say nothing and hg parent should return the latest
>> revision).
>>
>> Benoit
>>
>> 2010/7/4 Carlos Becker <carlosbecker@xxxxxxxxx>:
>>> I could now reproduce the error in packetmath_1:
>>> a[3]: 0.00128718, b[3]: 0.00128716
>>> Test packetmath<float>() failed in "/home/cjb/eigenThings
>>> areApprox(ref, data2, PacketSize) && "ei_preduxp"
>>> and in svd_1 after some trials:
>>> Test svd(Matrix3f()) failed in "/home/cjb/eigenThings/eigen/test/svd.cpp"
>>> (63)
>>> test_ei_isApprox(a * x, b)
>>> but I still have to get the right values.
>>> The most important error is in product_syrk_1, where I just get a segfault
>>> :S, anyone getting the same behaviour?
>>>
>>> On Sun, Jul 4, 2010 at 10:47 PM, Carlos Becker <carlosbecker@xxxxxxxxx>
>>> wrote:
>>>>
>>>> Hi everyone, these are the errors I get with OpenMP enabled, vectorization
>>>> enabled (up to SSE3) and row major alignment. GCC v4.4.1, ubuntu x32
>>>>
>>>> 99% tests passed, 4 tests failed out of 452
>>>>
>>>> The following tests FAILED:
>>>> 14 - packetmath_1 (Failed)
>>>> 194 - product_syrk_1 (Failed)
>>>> 214 - stable_norm_1 (Failed)
>>>> 319 - svd_1 (Failed)
>>>> Errors while running CTest
>>>>
>>>> However, I ran it a second time and only stable_norm_1 and product_syrk_1
>>>> failed! Now, ran it a third time and got these two failing again PLUS
>>>> redux_8 !!! I really don't know what is happening, and I tried running
>>>> packetmath_1 several times on my own and could not make it fail. The same
>>>> happened with svd_1.
>>>>
>>>> However, I can make redux_8 fail: Test vectorRedux(ArrayXf(33)) failed in
>>>> "/home/cjb/eigenThings/eigen/test/redux.cpp" (88)
>>>> test_ei_isApprox(s, v.head(i).sum())
>>>>
>>>> and printing some values: s : 0.000287235, v.head(i).sum(): 0.000286877,
>>>> although I don't know if this makes sense really.
>>>>
>>>> Does this all make sense somehow? I am starting to believe that something
>>>> is wrong with my processor, or I am a very special case.
>>>>
>>>> Carlos
>>>
>>
>>
>>
>
>
>