On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote:
> These issues can be fixed by not adding/subtracting 0.5, but Pred (0.5).
An interesting idea. Usually I see libraries switch to chopped
rounding instead, which also avoids the problem described.
r~
On Thu, Apr 07, 2005 at 07:14:05PM +0100, Paul Brook wrote:
> On Thursday 07 April 2005 18:54, Steve Kargl wrote:
> > On Thu, Apr 07, 2005 at 01:41:21PM -0400, Geert Bosch wrote:
> > > On Apr 7, 2005, at 13:27, Steve Kargl wrote:
> > > >Try -fdump-parse-tree. You've given more digits in y than
> >
Geert Bosch <[EMAIL PROTECTED]>:
> As far as I can seem from this patch, it rounds
incorrectly.
> This is a problem with the library version as well,
I believe.
>
> The issue is that one cannot round a positive float
to int
> by adding 0.5 and truncating. (Same issues with
negative values
> an
On Apr 7, 2005, at 13:54, Steve Kargl wrote:
I missed that part of the output. The exceeding
long string of digits caught my attention. Can
you submit a PR?
These routines should really be done as builtins, as almost all
front ends need this facility and we'd fit in with the common
frameworks for
On Thursday 07 April 2005 18:54, Steve Kargl wrote:
> On Thu, Apr 07, 2005 at 01:41:21PM -0400, Geert Bosch wrote:
> > On Apr 7, 2005, at 13:27, Steve Kargl wrote:
> > >Try -fdump-parse-tree. You've given more digits in y than
> > >its precision. This is permitted by the standard. It appears
> >
On Thu, Apr 07, 2005 at 01:41:21PM -0400, Geert Bosch wrote:
> On Apr 7, 2005, at 13:27, Steve Kargl wrote:
> >Try -fdump-parse-tree. You've given more digits in y than
> >its precision. This is permitted by the standard. It appears
> >the gfortran frontend is taking y = 0.49 and the closest
On Apr 7, 2005, at 13:27, Steve Kargl wrote:
Try -fdump-parse-tree. You've given more digits in y than
its precision. This is permitted by the standard. It appears
the gfortran frontend is taking y = 0.49 and the closest
representable nubmer is y = 0.5.
So, why does the test y < 0.5 yield tr
> print *, 'nint ( y ) =', nint (y), ', where y < 0.5 = ', y < 0.5
> end
>
> output is
> nint ( 8388609. ) = 8388610
> nint ( y ) = 1 , where y < 0.5 = T
Try -fdump-parse-tree. You've given more digits in y than
its precision. T
On Thu, Apr 07, 2005 at 01:10:49PM -0400, Geert Bosch wrote:
>
> On Apr 7, 2005, at 10:12, Steve Kargl wrote:
>
> >On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote:
> >>As far as I can seem from this patch, it rounds incorrectly.
> >>This is a problem with the library version as well,
On Apr 7, 2005, at 10:12, Steve Kargl wrote:
On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote:
As far as I can seem from this patch, it rounds incorrectly.
This is a problem with the library version as well, I believe.
Which library?
libgfortran, or whatever is used to implement NINT and
On 2005-04-07 08:08:15 -0400, Geert Bosch wrote:
> On platforms such as x86, where GCC implicitly widens intermediate
> results for IEEE double,
This depends on the FPU configuration, so...
> the rounding to integer should be performed entirely in long double
> mode, using the long double predece
On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote:
> As far as I can seem from this patch, it rounds incorrectly.
> This is a problem with the library version as well, I believe.
>
Which library?
--
Steve
As far as I can seem from this patch, it rounds incorrectly.
This is a problem with the library version as well, I believe.
The issue is that one cannot round a positive float to int
by adding 0.5 and truncating. (Same issues with negative values
and subtracting 0.5, of course). This gives an error
Hi, all
Gfortran translates the Fortran 95 intrinsic DNINT to
round operation with double precision type argument
and return value. Inline round operation will speed up
the SPEC CFP2000 benchmark 189.lucas which contains
function calls of intrinsic DNINT from 706 (SPEC
ratio) to 783 on IA64 1
14 matches
Mail list logo
