[Csdp] Puzzling result using icc

[Ronald Bruck]

Try watching the Fnorm of X as the iterations proceed.  (I think that's available with
printlevel 2 or greater).  It's clearly blowing up.  It's even more spectacular in extended
precision; After 200 iterates, using 1024-bit precision, the Fnorm of X is about 3.0e40.
(That takes 116 seconds.)

BTW, what platform are you running the quadruple-precision on?

-- Ron Bruck
Due to University fiscal constraints, .sigs may no longer exceed one
line.

----- Original Message -----
From: Brian Borchers <borchers at nmt.edu>
Date: Wednesday, August 19, 2009 1:00 pm
Subject: Re: [Csdp] Puzzling result using icc
To: csdp at list.coin-or.org, bruck at usc.edu
Cc: borchers at math.nmt.edu

> I ran my quadruple precision of CSDP on Ron's problem, and got:
> 
> Iter: 23 Ap: 7.85e-01 Pobj:  3.2920448e-01 Ad: 9.53e-01 Dobj:  
> 3.2920448e-01 
> Success: SDP solved
> Primal objective value: 3.292044793644429146e-01 
> Dual objective value: 3.292044793644470224e-01 
> Relative primal infeasibility: 3.78e-23 
> Relative dual infeasibility: 1.68e-29 
> Real Relative Gap: 2.48e-15 
> XZ Relative Gap: 2.48e-15 
> DIMACS error measures: 1.46e-22 0.00e+00 2.16e-29 0.00e+00 2.48e-15 
> 2.48e-15
> 
> So, I don't think that there's anything particularly wrong with the 
> problem itself.  
> 
> I haven't yet tried building the code with icc 11, so I can't really
> comment on what might have gone wrong there.  It's not uncommon for
> compilers to produce buggy code with high levels of optimization. Or,
> in what appears to be almost the same thing, for buggy code that works
> with one compiler to break under another compiler that performs more
> agressive (but legal) optimizations that reveal the bug.  
> 
> I should also say that this problem is so extremely small that doing
> speed comparisons with it is a bad idea- some optimizations may result
> in code which is much faster for large problems but slower for
> extremely small problems.  Since what we normally want to is fast
> performance on big long running problems, that's actually a good
> thing, even if it means that it takes an extra fraction of a second to
> solve a very small problem.
> 
> _______________________________________________
> Csdp mailing list
> Csdp at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/csdp
>