[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.0.1 release?
From: |
Michael Goffioul |
Subject: |
Re: 3.0.1 release? |
Date: |
Tue, 8 Apr 2008 23:25:07 +0200 |
On Tue, Apr 8, 2008 at 5:11 PM, David Bateman
<address@hidden> wrote:
> Yes this is the issue... It seems the bitmax under windows if not
> returning the right value.. bitmax uses
>
> static_cast<double> (0x1FFFFFFFFFFFFFLL)
>
> as its definition and so perhaps its the "LL" at the end that is causing
> the issue as it really should be a "UL".. Can you try
>
> #include <iostream>
>
> int main (void)
> {
> uint64_t a = 0x001FFFFFFFFFFFFFUL^0x0007FFFFFFFFFFFFUL;
> double b = static_cast<double> (0x1FFFFFFFFFFFFFLL);
> double c = static_cast<double> (0x1FFFFFFFFFFFFFUL);
>
> std::cerr << 0x001FFFFFFFFFFFFFUL << std::endl;
> std::cerr << 0x0007FFFFFFFFFFFFUL << std::endl;
> std::cerr << a << std::endl;
> std::cerr << b << std::endl;
> std::cerr << c << std::endl;
> std::cerr << b - c << std::endl;
> return 0;
> }
>
> and see whether the last result is something other than zero.. If so I
> think we've found the issue.
I don't think so: the last result is effectively zero. I tracked down a little
bit the problem and what I discovered is that bitmax returns the correct
result, that is
9007199254740991
but when casting this double value to uint64, then it becomes
9007199254740992
When debugging the "cast" call, I end up calling
octave_int<uint64_t>(double d), which calls xround. As MSVC does
not have native round, xround code is:
return x > 0 ? floor (x + 0.5) : ceil (x - 0.5);
This effectively adds 1 when x is equal to bitmax.
At this point, I don't now what to do. If there's not quick solution for
this problem, John, then I'd say release 3.0.1 with the problem. I don't
think this is a critical problem as it seems to only happen in this
specific corner case (when using bitmax). For instance:
octave.exe:9> cast(bitmax, 'uint64')
ans = 9007199254740992
octave.exe:10> cast(bitmax-1, 'uint64')
ans = 9007199254740990
Now, something I'm not sure is whether this is really the cause of the
test failure that started this thread. David, do you have an idea?
Michael.
- Re: 3.0.1 release? (cygwin), (continued)
- Re: 3.0.1 release? (cygwin), Tatsuro MATSUOKA, 2008/04/08
- Re: 3.0.1 release?, Michael Goffioul, 2008/04/08
- Re: 3.0.1 release?, David Bateman, 2008/04/08
- Re: 3.0.1 release?, Michael Goffioul, 2008/04/08
- RE: 3.0.1 release?, Bateman David-ADB014, 2008/04/08
- Re: 3.0.1 release?, Michael Goffioul, 2008/04/08
- Re: 3.0.1 release?, David Bateman, 2008/04/08
- Re: 3.0.1 release?, Michael Goffioul, 2008/04/08
- Re: 3.0.1 release?, David Bateman, 2008/04/08
- Re: 3.0.1 release?, John W. Eaton, 2008/04/08
- Re: 3.0.1 release?,
Michael Goffioul <=
- Re: 3.0.1 release?, John W. Eaton, 2008/04/08
- Re: 3.0.1 release?, Michael Goffioul, 2008/04/09
- Re: 3.0.1 release?, David Bateman, 2008/04/09
- Re: 3.0.1 release?, Michael Goffioul, 2008/04/09
- Re: 3.0.1 release?, John W. Eaton, 2008/04/09
- Re: 3.0.1 release?, Marco Atzeri, 2008/04/10
- Re: 3.0.1 release?, Shai Ayal, 2008/04/08
- Re: 3.0.1 release?, Thomas Weber, 2008/04/09
Re: 3.0.1 release?, David Bateman, 2008/04/03