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 11 February 2014 at 02:53, Kirill Müller wrote:
| Why does it seem to be necessary to load the methods package here?
"Just use littler (TM pending)".
It (auto-)load methods automagically, thanks to Jeff Horner. See below.
edd@max:~$ chmod 0755 /tmp/kirill.r
edd@max:~$ /tmp/kirill.r
On 02/11/2014 03:22 AM, Peter Meilstrup wrote:
Because "depends" is treated incorrectly (if I may place a value
judgement on it). I had an earlier thread on this, not sure if any
changes have taken place since then:
http://r.789695.n4.nabble.com/Dependencies-of-Imports-not-attached-td4666529.htm
Because "depends" is treated incorrectly (if I may place a value
judgement on it). I had an earlier thread on this, not sure if any
changes have taken place since then:
http://r.789695.n4.nabble.com/Dependencies-of-Imports-not-attached-td4666529.html
On Mon, Feb 10, 2014 at 5:53 PM, Kirill Müller
Hi
Accesses the $new method for a class defined in a package fails if the
methods package is not loaded. I have created a test package with the
following single code file:
newTest <- function() {
cl <- get("someClass")
cl$new
}
someClass <- setRefClass("someClass")
(This is similar to
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
FWIW, documentation .dta from Stata 13::
http://www.stata.com/help.cgi?dta
"Stata 13 writes what are
known as .dta format-117 files and can read all formats of files that
have ever been released. The recent history of .dta formats is
FormatCurrent as of
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
13 matches
Mail list logo
