Adrian,
Yes, any "whole" number coming out of a computation bitten by floating
point issues, I think.
> x = 1/49*49
> x
[1] 1
> x%%1
[1] 1
> is.wholenumber <-
+ function(x, tol = .Machine$double.eps^0.5) abs(x - round(x)) < tol
> is.wholenumber(x)
[1] TRUE
Best,
~G
P.S Credit to Hadley Wic
In the help page for ?is.integer, there is this function
is.wholenumber <-
function(x, tol = .Machine$double.eps^0.5) abs(x - round(x)) < tol
A quick question: is there a case where this alternative function will not
work?
function(x) x %% 1 == 0
Best,
Adrian
--
Adrian Dusa
University
> "Stephan" == Stephan <[EMAIL PROTECTED]>
> on Tue, 1 May 2007 13:21:53 +0200 writes:
Stephan> Hi,
>> 0x10L
Stephan> returns: int 0
Stephan> I would expect: int 16? This happens with all
Stephan> integer constants given by hexadecimal notation.
Stephan> It'
[EMAIL PROTECTED] wrote:
> On 01/05/2007 7:21 AM, Stephan wrote:
>
>> Hi,
>>
>>
>>> 0x10L
>>>
>> returns: int 0
>>
>> I would expect: int 16?
>> This happens with all integer constants given by hexadecimal notation.
>> It's a bug?
>>
>
> Certainly looks like one; I've cc'd this
This works correctly on Linux. The problem is that the author assumed
that atof handles hexadecimal, which it does for a C99 compiler but not
apparently on MinGW.
We have a workaround for this in mkFloat, and need to use that for the 'L'
suffix case too.
On Tue, 1 May 2007, [EMAIL PROTECTED]
On 01/05/2007 7:21 AM, Stephan wrote:
> Hi,
>
>> 0x10L
> returns: int 0
>
> I would expect: int 16?
> This happens with all integer constants given by hexadecimal notation.
> It's a bug?
Certainly looks like one; I've cc'd this to the bug list (but won't be
able to look into fixing it).
Duncan
Hi,
> 0x10L
returns: int 0
I would expect: int 16?
This happens with all integer constants given by hexadecimal notation.
It's a bug?
> sessionInfo()
R version 2.5.0 (2007-04-23)
i386-pc-mingw32
locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252
