This concerns the contributed package "concord". Sorry to bother
you with it, but my attempt to contact the author/maintainer
failed (see below). Perhaps you can forward it, or let me
know where to send it.
Regards, Rob Kushler
--
This i
It's due to a change in the way dlltool is called. Easy to fix (I've just
done so): add -k to the DLLTOOL line in MkChmDll.
On Thu, 27 Oct 2005 [EMAIL PROTECTED] wrote:
> Hi,
>
> I encountered this problem just before the 2.2.0 release. Then it went
> away for a while and came back at the begi
Hi,
I encountered this problem just before the 2.2.0 release. Then it went
away for a while and came back at the beginning of this week. Here is what
is happening (I am on Win2000 machine with all the necessary tools
installed).
I compile R-devel and R-patched trees every couple of days and ins
Dear all,
I have been doing tests using SVM, random forests and PPR. The data is from a
data stream (that is, the data for training and for test is always increasing /
changing). With SVM and random forests everything is ok, but with ppr there are
situations where it crashes. For the examples I
Dear Sir or Madam,
the society for software development and analytic (GSA) is a business
company settled in Germany (Rostock/Mecklenburg-Western Pomerania).
In particular we concentrate on doing the planning and evaluation of
Microarray-Geneexpression-experiments that are based on the Affymetri
I am using 2.2.0
If the QR decomposition of an N*M matrix is such that the pivoting order
is not 1:M, Q%*%R does not result in the original matrix but in a
matrix with the columns permuted. This is clearly intentional, and
probably to be expected if pivoting is used --- chol() behaves in the
same
[EMAIL PROTECTED] writes:
> Where is my error??
> I have a strange behaviour in R, looks like type conversions are messed =
> up.
> Maybe i just make a stupid mistake, but help would be appreciated.
>
> To reproduce:
>
> expected:
> > typeof(3)
> [1] "double"
>
> > as.integer(3)
> [1] 3
>
> >
> Where is my error??
You are assuming that numbers are represented exactly:
http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
> 0.3/0.1 == 3
[1] FALSE
Hadley
__
R-devel@r-project.org mailing list
https:
[EMAIL PROTECTED] schreef op de 27e dag van de wijnmaand van het...:
> Where is my error??
> I have a strange behaviour in R, looks like type conversions are messed =
> up.
> Maybe i just make a stupid mistake, but help would be appreciated.
Not maybe. You definately make a stupid mistake. There
On Thu, 2005-10-27 at 15:24 +0200, [EMAIL PROTECTED] wrote:
> Full_Name: Grischa Tödt
> Version: 2.1.1
> OS: windows XP
> Submission from: (NULL) (192.108.25.32)
>
>
> I have a strange behaviour in R, looks like type conversions are messed up.
>
> To reproduce:
>
> expected:
> > typeof(3)
> [1]
On 10/27/2005 9:24 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Grischa Tödt
> Version: 2.1.1
> OS: windows XP
> Submission from: (NULL) (192.108.25.32)
>
>
> I have a strange behaviour in R, looks like type conversions are messed up.
This is not a bug, it's normal behaviour for floating point valu
On 10/27/2005 9:24 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Grischa Tödt
> Version: 2.1.1
> OS: windows XP
> Submission from: (NULL) (192.108.25.32)
>
>
> I have a strange behaviour in R, looks like type conversions are messed up.
This is not a bug, it's normal behaviour for floating point valu
Where is my error??
I have a strange behaviour in R, looks like type conversions are messed =
up.
Maybe i just make a stupid mistake, but help would be appreciated.
To reproduce:
expected:
> typeof(3)
[1] "double"
> as.integer(3)
[1] 3
> typeof((0.3/0.1))
[1] "double"
strange:
> as.intege
Full_Name: Grischa Tödt
Version: 2.1.1
OS: windows XP
Submission from: (NULL) (192.108.25.32)
I have a strange behaviour in R, looks like type conversions are messed up.
To reproduce:
expected:
> typeof(3)
[1] "double"
> as.integer(3)
[1] 3
strange:
> typeof((0.3/0.1))
[1] "double"
> as
Hi,
Somebody gave me this little problem about QR decomposition and
Choleski Decomposition. The column names of the matrix (if the user
choose to name them explicitly with dimname or it was composed from
named vectors) remains the same after the operation, although
the content has been swapped
Dear list
I think there might be an inconsistency in the function "do_optimhess"
in src/main/optim.c.
Consider changing the line
"eps = OS->ndeps[i]/(OS->parscale[i]);"
to
"eps = OS->ndeps[i];"
Then "ndeps" is the finite-difference step on "par/parscale" as it
should be according to the document
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status Patched
major2
minor2.0
year 2005
month10
day 24
svn rev 36016
language R
Re: plot.TukeyHSD
Thanks for the recent quick fix. Another small fix is needed.
I should have tested more thoro
As requested a while back, x11() and dataentry() in R-devel now respond to
a few X11 resources, notably geometry, and x11() has xpos and ypos
arguments for positioning (as windows() has long had).
I've tested these on three separate X11 window managers, but the code
does depend on WM hints so w
> > is.loaded("supsmu_")
>
> [1] FALSE
>
> > is.loaded("supsmu")
>
> [1] TRUE
>
> That is a Fortran entry point, and it complies with the description
> quoted.
>
> What is.loaded() needs depends on how the symbol would be found
> and so it is not much use.
OK, thanks.
But still
> is.loaded("fst
19 matches
Mail list logo
