From bug-octave-request at bevo dot che dot wisc dot edu Fri Dec 19 12:18:25 2003 Subject: Re: (-1).^.5 == NaN From: Paul Kienzle To: "John W. Eaton" Cc: bug-octave at bevo dot che dot wisc dot edu Date: Fri, 19 Dec 2003 13:17:59 -0500 On Fri, Dec 19, 2003 at 11:56:50AM -0600, John W. Eaton wrote: > On 19-Dec-2003, Paul Kienzle wrote: > > | > OK, how about the following change? OTOH, I'm not sure that this > | > should be "fixed" in Octave, but maybe it can eventually be changed > | > back when the buggy libm function is no longer likely to be > | > encountered. > | > | How about fixing it in lo-mappers instead? > > I don't see any pow function in liboctave/lo-mappers.cc, so how would > you fix it there? Do you want to add an xpow(double,double) function > that works around the bug and then use that instead of std::pow > everywhere else in Octave? Sorry, I meant to say oct-cmplx.h. Looking at the details of oct-cmplx.h, though I see that this won't work since oct-cmplx.h is there only to import the complex math functions into the global namespace. Since we still support broken compilers (?), we can't redefine it before importing. The "proper" solution is as you have suggested elsewhere to define an octave namespace which exports all of the functions we need. Then we can fix whatever is broken on the machine we are using. I don't think this bug is sufficient to force that though. Meanwhile, xpow already exists and is defined to return an octave_value. I would leave that alone for now and just fix pow as you have done whereever we need to. Or not, and warn during configure that libstdc++ is broken. Paul Kienzle pkienzle at nist dot gov ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------