Hi Duncan,
Thanks a ton -- I appreciate your taking the time to investigate this,
and especially even checking into the IEEE standard to clarify.
Cheers,
Kevin
On Mon, Feb 10, 2014 at 11:54 AM, Rainer M Krug wrote:
>
>
> On 02/10/14, 19:07 , Duncan Murdoch wrote:
>> On 10/02/2014 10:21 AM, Tim
On 02/10/14, 19:07 , Duncan Murdoch wrote:
> On 10/02/2014 10:21 AM, Tim Hesterberg wrote:
>> This isn't quite what you were asking, but might inform your choice.
>>
>> R doesn't try to maintain the distinction between NA and NaN when
>> doing calculations, e.g.:
>> > NA + NaN
>> [1] NA
>> > NaN
On 10/02/2014 1:43 PM, Kevin Ushey wrote:
Also, similarly, to clarify, should there be _one_ unique bit pattern
for R's NA_REAL, or two? Because I see (for a function hex that
produces the hex representation of a number):
> hex(NA_real_)
[1] "7FF007A2"
> hex(NA_real_+1)
[1] "7FF8
On 10/02/2014 1:43 PM, Kevin Ushey wrote:
Also, similarly, to clarify, should there be _one_ unique bit pattern
for R's NA_REAL, or two? Because I see (for a function hex that
produces the hex representation of a number):
I don't think the language definition defines bit patterns, it defines
b
Also, similarly, to clarify, should there be _one_ unique bit pattern
for R's NA_REAL, or two? Because I see (for a function hex that
produces the hex representation of a number):
> hex(NA_real_)
[1] "7FF007A2"
> hex(NA_real_+1)
[1] "7FF807A2"
> hex(NaN)
[1] "7FF8"
Thi
On 10/02/2014 10:21 AM, Tim Hesterberg wrote:
This isn't quite what you were asking, but might inform your choice.
R doesn't try to maintain the distinction between NA and NaN when
doing calculations, e.g.:
> NA + NaN
[1] NA
> NaN + NA
[1] NaN
So for the aggregate package, I didn't attempt to tr
Thanks Tim, this is exactly the explanation I was hoping to see. Much
appreciated!
On Mon, Feb 10, 2014 at 7:21 AM, Tim Hesterberg wrote:
> This isn't quite what you were asking, but might inform your choice.
>
> R doesn't try to maintain the distinction between NA and NaN when
> doing calculatio
This isn't quite what you were asking, but might inform your choice.
R doesn't try to maintain the distinction between NA and NaN when
doing calculations, e.g.:
> NA + NaN
[1] NA
> NaN + NA
[1] NaN
So for the aggregate package, I didn't attempt to treat them differently.
The aggregate package is
There is one NA but mulitple NaNs.
And please re-read 'man memcmp': your cast is wrong.
On 10/02/2014 06:52, Kevin Ushey wrote:
Hi R-devel,
I have a question about the differentiation between NA and NaN values
as implemented in R. In arithmetic.c, we have
int R_IsNA(double x)
{
if (isnan
Hi R-devel,
I have a question about the differentiation between NA and NaN values
as implemented in R. In arithmetic.c, we have
int R_IsNA(double x)
{
if (isnan(x)) {
ieee_double y;
y.value = x;
return (y.word[lw] == 1954);
}
return 0;
}
ieee_double is just used for type punning so w
10 matches
Mail list logo
