Ryan,
On May 30, 2006, at 5:06 PM, [EMAIL PROTECTED] wrote:
> /Library/Frameworks/R.framework/Versions/2.3/Resources/etc/ppc/
> Renviron and
> /Library/Frameworks/R.framework/Versions/2.3/Resources/etc/i386/
> Renviron
> both use /usr/local/teTeX/bin/powerpc-apple-darwin-current for
> LaTeX r
Whether this works or not depends on the graphics device. The description
in the driver sources says
* Line textures are stored as an array of 4-bit integers within
* a single 32-bit word. These integers contain the lengths of
* lines to be drawn with the pen alternately do
Full_Name: Ryan Lovett
Version: 2.3.0
OS: Mac OS X 10.4
Submission from: (NULL) (128.32.135.41)
/Library/Frameworks/R.framework/Versions/2.3/Resources/etc/ppc/Renviron and
/Library/Frameworks/R.framework/Versions/2.3/Resources/etc/i386/Renviron
both use /usr/local/teTeX/bin/powerpc-apple-darwin-c
/Library/Frameworks/R.framework/Versions/2.3/Resources/etc/ppc/Renviron and
/Library/Frameworks/R.framework/Versions/2.3/Resources/etc/i386/Renviron
both use /usr/local/teTeX/bin/powerpc-apple-darwin-current for LaTeX
related variables. Could this be updated for i386 to take into account the
teTeX
Full_Name: Brian D. Peyser
Version: 2.1 (also 2.3)
OS: Windows XP Pro
Submission from: (NULL) (162.129.236.18)
In the documentation for par() (both on-line and manual) there is an error
regarding line type specification (lty). It actually omits a feature. The
documentation states that a string up
Beyond the R FAQ 7.31 the article "What Every Computer Scientist Should
Know About Floating-Point Arithmetic, by David Goldberg"
(http://docs.sun.com/source/806-3568/ncg_goldberg.html) is very
informative, but it is rather long (this topic has many subtleties).
Wikipedia has a shorter page on "
G'day Teck,
I am taking R-bugs out of the recipient list because, as other have
pointed out to you, it definitely is not a bug and doesn't belong
there.
I was about to answer your e-mail yesterday, but then decided that my
reply was overly sarcastic, cancelled it and went home instead. In
the mo
"ltp" <[EMAIL PROTECTED]> writes:
> Hi
>
> Thanks for the quick reply. However, I am not satisfied, as
> > round(3.1500, 1)
> [1] 3.1
> > round(3.7500, 1)
> [1] 3.8
>
> I think the problem is really more of an error in the rounding off
> algorithm than finite precision.
It i
"ltp" <[EMAIL PROTECTED]> writes:
> Hi
>
> Thanks for the quick reply. However, I am not satisfied, as
> > round(3.1500, 1)
> [1] 3.1
> > round(3.7500, 1)
> [1] 3.8
>
> I think the problem is really more of an error in the rounding off
> algorithm than finite precision.
It i
Hi
Thanks for the quick reply. However, I am not satisfied, as
> round(3.1500, 1)
[1] 3.1
> round(3.7500, 1)
[1] 3.8
I think the problem is really more of an error in the rounding off
algorithm than finite precision.
Thanks
Teckpor
-Original Message-
From: Dunca
Hi
Thanks for the quick reply. However, I am not satisfied, as
> round(3.1500, 1)
[1] 3.1
> round(3.7500, 1)
[1] 3.8
I think the problem is really more of an error in the rounding off
algorithm than finite precision.
Thanks
Teckpor
-Original Message-
From: Uwe L
Hi
Thanks for the quick reply. However, I am not satisfied, as
> round(3.1500, 1)
[1] 3.1
> round(3.7500, 1)
[1] 3.8
I think the problem is really more of an error in the rounding off
algorithm than finite precision.
Thanks
Teckpor
-Original Message-
From: Peter
Hi
Thanks for the quick reply. However, I am not satisfied, as
> round(3.1500, 1)
[1] 3.1
> round(3.7500, 1)
[1] 3.8
I think the problem is really more of an error in the rounding off
algorithm than finite precision.
Thanks
Teckpor
-Original Message-
From: [EMAIL
Many thanks for your very useful comments and suggestions.
Renaud
2006/5/30, Prof Brian Ripley <[EMAIL PROTECTED]>:
> On Tue, 30 May 2006, Prof Brian Ripley wrote:
>
> > This is not really a bug. See
> >
> > http://developer.r-project.org/model-fitting-functions.txt
> >
> > for how this is handl
Many thanks for your very useful comments and suggestions.
Renaud
2006/5/30, Prof Brian Ripley <[EMAIL PROTECTED]>:
> On Tue, 30 May 2006, Prof Brian Ripley wrote:
>
> > This is not really a bug. See
> >
> > http://developer.r-project.org/model-fitting-functions.txt
> >
> > for how this is handl
On Tue, 30 May 2006, Prof Brian Ripley wrote:
> This is not really a bug. See
>
> http://developer.r-project.org/model-fitting-functions.txt
>
> for how this is handled in other packages. All model-fitting in R used to
> do this (and it is described in the White Book and MASS1-3).
>
> predict.lme
This is not really a bug. See
http://developer.r-project.org/model-fitting-functions.txt
for how this is handled in other packages. All model-fitting in R used to
do this (and it is described in the White Book and MASS1-3).
predict.lme does not use model.frame as described in that URL. Dr Bat
On Tue, 30 May 2006, [EMAIL PROTECTED] wrote:
> I would like to call the R regression routines in C/C++. I have seen that
> it is possible to call distribution function, optimisation routines etc,
> but is it possible to call a simple OLS and which is the relevant header
> file?
Regression is don
I would like to call the R regression routines in C/C++. I have seen that
it is possible to call distribution function, optimisation routines etc,
but is it possible to call a simple OLS and which is the relevant header
file?
Thanks.
__
R-devel@r-projec
19 matches
Mail list logo
