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
> "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
