octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compiling development sources


From: Jaroslav Hajek
Subject: Re: compiling development sources
Date: Thu, 11 Feb 2010 12:41:09 +0100

On Thu, Feb 11, 2010 at 11:49 AM, Jaroslav Hajek <address@hidden> wrote:
> On Thu, Feb 11, 2010 at 10:52 AM, Carlo de Falco
> <address@hidden> wrote:
>>
>> On 11 Feb 2010, at 10:21, Jaroslav Hajek wrote:
>>
>>>
>>> Great. Thanks for the impulse. You may try to vary the random seed at line
>>> 64
>>>
>>>     data seed /4*3/
>>> -->
>>>     data seed /4*13/
>>>
>>> the "4*" prefix is needed (it's not multiplication, just an ugly
>>> Fortran feature), any integer will do as the second. Or you can supply
>>> 4 different integers separated by commas.
>>> Prior to doing so, please apply this patch:
>>>
>>> Index: test/Makefile
>>> ===================================================================
>>> --- test/Makefile       (revision 22)
>>> +++ test/Makefile       (revision 23)
>>> @@ -31,6 +31,7 @@
>>>        ./report_results $(OUTS)
>>>
>>> $(OUTS): %.out: %
>>> +       echo > $@
>>>        ./$< | tee $@
>>>
>>> $(PROGS): % : %.f utils.o ../libqrupdate.a
>>>
>>>
>>> or delete the *.out files after each try, otherwise a segfault may
>>> escape your attention.
>>> If you can't produce a failure this way, the problem is probably not
>>> in qrupdate.
>>> The next step i
>>
>> OK, I used 'data seed /4*23/' and got some test failures, and even in tests
>> that do pass some residuals are not very small
>> c.
>>
>>
>
> The tests are randomized so random failures like this mean nothing (in
> theory you can get arbitrarily bad residuals). The single precision
> routines generally produce much worse residuals. This is the reason
> why the seed is hard-coded.
> Anyway I just discovered that I occassionally get failures as well,
> cause by NaNs compute by CHERK.

Update: I upgraded to fresh new GotoBLAS2, and the problem is gone.
Hence, I'm pretty sure it was a buggy CHERK to blame. It's not the
first time; CHERK/ZHERK seem to be the buggiest BLAS routines. ATLAS
(at least some versions) has buggy CHERK as well.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]