On Wed, 24 Mar 2010, William Dunlap wrote:
Should both parts of a complex number be printed
to the same precision? The imaginary part of 0
looks a bit odd when log10(real/imag) =~ getOption(digits),
but I'm not sure it is awful. Some people might
expect the same number of significant digits
Hi,
Just a note, if you want an exact character representation of an 8 byte
IEEE float you may want to extract the exact 16 character hexidecimal
equivalent of the raw binary 8 byte float. Converting possible non-integer
or non 2^x float to decimal is often an approximation and may not be
I'm not sure it's awful either, but it
is surprising -- at least to my eye.
In particular, it is using the same
amount of real estate as it would to
print the right value.
Pat
On 25/03/2010 01:14, William Dunlap wrote:
Should both parts of a complex number be printed
to the same precision?
AndrewC == Andrew Clausen clau...@econ.upenn.edu
on Tue, 23 Mar 2010 08:04:12 -0400 writes:
AndrewC Hi all,
AndrewC I forgot to test my patch! I fixed a few bugs.
and this time, you even forgot to attach it (in a way to pass
through the list filters).
Note however, that all this
Hi Martin,
I re-attached the patch with a filename that will hopefully get
through the filters this time.
I agree that the case that you want to specify an integer is already
well handled with sample.int(). I disagree that the resample() code
for the set case given in the example is trivial.
I'm relaying a question from my institute's sysadmin:
Would it be possible to modify update.packages() and related functions so
that 'lib.loc' accepts integer values to specify a library from the
.libPaths() vector?
Many Linux users want to update all user packages (inside the R_LIBS_USER
There appears to be a quoting problem in the way R CMD install handles file
names containing spaces, more specifically, in the way the argument is passed
through to gzip.
The install.packages command
(from R)
install.packages(~/Projects/R library/bar/eyetrackR_0.13.tar.gz, repos =
NULL, type
