To Whom It May Concern:
The following appears to be a bug in the way POSIXct dates are formated.
The example is forced, but occurs naturally when importing Excel type dates
(where fractional part is fraction of a day) and small rounding errors
result.
As shown, looking at the POSIXct clas
No bug, as intended. If you want to see fractional seconds then you need
to use a non-default format. They are not (just) numbers, and fractional
seconds are intended only for use intentionally.
There is a round() method for POSIXct objects:
> a
[1] "2007-07-27 16:11:03 GMT Daylight Time"
[2]
Prof Brian Ripley stats.ox.ac.uk> writes:
...
>
> Do you have a NAMESPACE?
Hi Albart!
About the NAMESACE issue. Functions that are specified in NAMESPACE
are available when you install a package, while internal ones can
only be accessed with
myInternalFun:::myPackage
Gregor
_
Le 07-07-31 à 09:48, Gregor Gorjanc a écrit :
> Prof Brian Ripley stats.ox.ac.uk> writes:
> ...
>>
>> Do you have a NAMESPACE?
>
> Hi Albart!
>
> About the NAMESACE issue. Functions that are specified in NAMESPACE
> are available when you install a package, while internal ones can
> only be acces
?barplot seems to be missing the word "have" below (so that it reads
"Specifying a single value will have no visible effect..."):
\item{width}{optional vector of bar widths. Re-cycled to length the
number of bars drawn. Specifying a single value will no visible
effect unless \code{xlim} i
Stephen Weigand wrote:
> ?barplot seems to be missing the word "have" below (so that it reads
> "Specifying a single value will have no visible effect..."):
>
> \item{width}{optional vector of bar widths. Re-cycled to length the
> number of bars drawn. Specifying a single value will no visible
