<div>Hi,</div>
<div> </div>
<div>Thanks for this info. I set the cw to the one in which my program was running properly.</div>
<div>Apparently, IPOpt has just the INEXACT flag on, whereas LAPACKPP has all the flags you mentioned on.</div>
<div> </div>
<div>If I turn on all the flags, it doesnt crash in the lapackpp function calls. </div>
<div>But I was wondering if this is ok ? If there was an underflow (or zerodivide, etc) in the calculations, doesnt it mean something went wrong in the calculations? Even though I am getting the right answer.</div>
<div> </div>
<div>Thanks,</div>
<div>~ sonia <br><br> </div>
<div><span class="gmail_quote">On 12/16/06, <b class="gmail_sendername">Steven Dirkse</b> <<a href="mailto:sdirkse@gams.com">sdirkse@gams.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Sonia Singhal wrote:<br>> Hi,<br>><br>> I am doing development in Microsoft Visual Studio 2003. I have been
<br>> using LAPACK through a C++ interface provided in lapackpp-2.5.0. I was<br>> using it for solving linear system of equations and doing SVD. This<br>> package provides the libs for lapack and blas which I used for compiling
<br>> their c++ interface package.<br>> Recently I used IpOpt ( 3.2.3 ) version in the code to solve an<br>> optimization problem. I havnt written the complete code yet, just made a<br>> dummy optimization class just to see if I was able to link the entire
<br>> ipopt infrastructure with my existing code. I was able to compile and<br>> run the Cpp Example given in the IPOpt distribution.<br>> The problem is that my code crashes in the lapackpp's call to their<br>> interface to SVD (dgesdd). It crashes giving a "floating point
<br>> underflow" error. This doesnt happen if I remove ipopt's libs and code.<br>> I have posted this question on the lapackpp forum too. I am posting here<br>> too just in case anyone has any idea of what the problem could be.
<br>><br>> Thanks,<br>> ~ sonia<br>><br><br>Sonia,<br><br>Floating point underflow is a hardware exception that can be raised on<br>most CPUs. Typically this is masked, so when underflow occurs the<br>result is stored as a denormal (if it isn't one already) if possible or
<br>silently flushed to zero. I'd guess that LAPACK is expecting this<br>setting. Somehow running with the IPOPT code in there, this exception<br>is unmasked and you LAPACK behaves differently.<br><br>You can experiment with your code to see what the exception mask is when
<br>it works and when it aborts. Here is a snippet of code to get you started:<br><br>#if defined(_WIN32)<br>{<br> unsigned int cw;<br><br> cw = _control87(0,0);<br> if (cw & _EM_INVALID ) ADD2MASK(EX_INVALIDOP );
<br> if (cw & _EM_DENORMAL ) ADD2MASK(EX_DENORMAL );<br> if (cw & _EM_ZERODIVIDE) ADD2MASK(EX_ZERODIVIDE);<br> if (cw & _EM_OVERFLOW ) ADD2MASK(EX_OVERFLOW );<br> if (cw & _EM_UNDERFLOW ) ADD2MASK(EX_UNDERFLOW );
<br> if (cw & _EM_INEXACT ) ADD2MASK(EX_PRECISION );<br>}<br><br>I would google _control87 for more info. FYI, ADD2MASK is a macro of<br>mine, but _EM_INVALID are defined by some system headers. If you<br>replace ADD2MASK by some print statements you should see what the mask is.
<br><br>-Steve<br><br></blockquote></div><br>