Octave 3.0.1 available for ftp

[John W. Eaton]

On 24-Apr-2008, Michael Goffioul wrote:

| On Thu, Apr 24, 2008 at 3:38 PM, Tatsuro MATSUOKA <tmacchant at yahoo.co.jp> wrote:
| > Hello David
| >
| >  Thank you for your reply.
| >
| >  --- David Bateman <David.Bateman at motorola.com> wrote:
| >  > Wouldn't it better better to have the autoconf test refuse to set
| >  > HAVE_ROUND for mingw rather than hard code in the source.. Alternatively
| >  > we code test the behavior of the round function in an autoconf test to
| >  > see if it fails for the case near bitmax, though that would be more work
| >  > to implement..
| >  >
| >  > D.
| >
| >  What you said is right.  However, I do not have enough knowledge of auto tools.
| >  And I cannot understand what is the problem with 'round' implemeted in the MinGW g++ 3.4.5.
| >  If you suggest me a autoconf modification, I will test to it and report here.
| 
| The code used internally by MinGW for "round" is the following
| (http://www.koders.com/c/fidB63EAFA2C117AAFC1CF9FE9691F8DDBE4DD01A22.aspx)
| 
| double
| round (double x)
| {
|   /* Add +/- 0.5 then then round towards zero.  */
|   return trunc ( x + (x >= 0.0 ?  0.5 : -0.5));
| }
| 
| The problem with this implementation is when x is the vicinity of bitmax: it
| leads to floating-point overflow (in the mantissa) and produces rounding error,
| For instance if x = bitmax, round(x) => bitmax+1, while it should return
| bitmax.
| 
| Octave used to use the above implementation for MSVC, but because of
| this problem, I switched it to use the (more robust) gnulib implementation.

Please report the problem to the MinGW maintainers.  In the meantime,
it would be helpful to have a configure test that actually tests the
feature, not just that we are running on a MinGW system.  That way,
the test should automatically switch to using code from MinGW when the
problem is fixed in their sources.

Thanks,

jwe