octave-maintainers
[Top][All Lists]
Advanced

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

Re: Status of FLTK on MacOS X [changeset for chol.cc]


From: Michael D Godfrey
Subject: Re: Status of FLTK on MacOS X [changeset for chol.cc]
Date: Wed, 06 Jan 2010 11:24:42 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0

On 01/06/2010 10:48 AM, Ben Abbott wrote:
On Jan 6, 2010, at 11:53 AM, Michael D Godfrey <address@hidden> wrote:

On 01/06/2010 05:06 AM, Ben Abbott wrote:
On Jan 5, 2010, at 8:06 AM, Ben Abbott wrote:

  
> 
> On Jan 5, 2010, at 1:46 AM, John W. Eaton wrote:
> 
    
>> On  4-Jan-2010, Ben Abbott wrote:
>> 
>> | I discovered some typos in my build process.  With those fixed, I have one failure.
>> | 
>> | 	>>>>> processing /Users/bpabbott/Development/mercurial/local_clone/src/data.cc
>> | 	  ***** assert(log2(complex(0,Inf)), Inf + log2(i));
>> | 	!!!!! test failed
>> | 	assert (log2 (complex (0, Inf)),Inf + log2 (i)) expected
>> | 	Inf + 2.266i
>> | 	but got
>> | 	Inf - NaNi
>> | 	NaNs don't match
>> 
>> I think we discussed this problem on one of the lists recently.  It
>> happens with GCC if you compile without optimization.
      
> 
> Unfortunately, once I get to -O2 with Apple's variant of gcc 4.2 ...
> 
> octave:12> info = struct (zeros (0, 1), {"name", "date", "bytes", "isdir", "datenum", "statinfo"})
> info =
> {
>  0x1 struct array containing the fields:
> 
>    name
>    date
>    bytes
>    isdir
>    datenum
>    statinfo
> }
> 
> octave:13> info(554,1).name = 'zfstream.h'
> error: invalid assignment to cs-list outside multiple assign
    
After pulling the current sources, and building  autogen -> configure -> make -> make check ... the error above is gone. I recall trying this several days ago ... perhaps I typed "-01" instead?

In any event, for Xcode's gcc 4.2 compiler using "-O1" eliminates the error above.

  
> 
    
>> 
>> | About half the time I run fntests.m from the command line it
>> | passes. I occasionally get a failure when testing chol.cc
>> | (increasing the error tolerance would fix that).
>> 
>> Which test fails, and which tolerance should be increased?
>> 
      
> 
> I have trouble with the single precision tests.
> 
> %!test
> %! u2 = single ([  0.35080 ;
> %!                 0.63930 ;
> %!                 3.31057 ;
> %!                -0.13825 ;
> %!                 0.45266 ]);
> %!
> %! R = chol(single(A));
> %! 
> %! j = 3; p = [1:j-1, j+1:5];
> %! R1 = cholinsert(R,j,u2); A1 = R1'*R1;
> %! 
> %! assert(norm(triu(R1)-R1,Inf) == 0)
> %! assert(norm(A1(p,p) - A,Inf) < 1e1*eps('single'))
> %! 
> %!test
> %! u2 = single ([  0.35080  + 0.04298i;
> %!                 0.63930  + 0.23778i;
> %!                 3.31057  + 0.00000i;
> %!                -0.13825  + 0.19879i;
> %!                 0.45266  + 0.50020i]);
> %!
> %! R = chol(single(Ac));
> %! 
> %! j = 3; p = [1:j-1, j+1:5];
> %! R1 = cholinsert(R,j,u2); A1 = R1'*R1;
> %! 
> %! assert(norm(triu(R1)-R1,Inf) == 0)
> %! assert(norm(A1(p,p) - single(Ac),Inf) < 1e1*eps('single'))
> 
> I'd planned to increase the tolerance after running some tests and determining the error's mean and std.
> 
> Ben
    
A trivial changeset is attached to increase the tolerance for two single precision tests in chol.cc. If there are no objections, I'll push this latter today.

Ben

  
Ben,

I do not think that changing these tolerances is appropriate at this point.
There are no errors for me when I compile the current development system
on Linux, or on my Intel Mac 10.6 using -O0.   The Mac configuration is still very
flakey.  It would be good to wait until the right choices of compilers and
libraries have been better determined.  I am currently using gfortran 4.2.1.

Michael

Ok. I'll wait until things have stablized and reevaluate.

Ben 
Good.  It seems to me that the current tolerance values are working as they should:
on systems with stable software the tests pass, and (at least in the cases that I have
looked at) are consistent with IEEE floating point behavior.  The IEEE error behavior,
thanks to Kahan, is very well defined.  (And, these days, it is Kahan's students who do
most of the floating point core designs.) So, the most likely cause of test failures is software.
Unfortunately, identifying where in the software things have gone wrong is not easy.
I suspect that in my Mac there may be some library confusion since I have noticed
that on some occasions I have found the following: 
1. Install some version of gfortran.  Get correct check results.
2. Try another gfortran. Failure.
3. Reinstall the first gfortran.  Failure...
Or course there are other possibilities for error in this loop...  One clear indication
of problems is that fairly often ./configure fails on the CDOTU test.  Changes that
should not affect this actually make the failure go away.  More needs to be learned.

I recently updated sed to 4.2 and flex to 2.5.4.  This had noticeable effects, not all good.
But, some of the problems may be due to changes that should not have been made.
There are still way too many variables floating around in the Mac 10.6 systems.
(Well, at least in mine: I have too much stuff in  /usr/local/bin and ../lib much of it
left over from when the system was running 10.5.)

Michael



reply via email to

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