On Tue, May 05, 2009 at 11:27:36AM +0200, Peter Dalgaard wrote:
> I know. The point was rather that if you are not careful with rounding,
> you get the some of the bars wrong (you get 2 or 3 small bars very close
> to each other instead of one longer one). Computed p values from
> permutation tests
4dscape.com> writes:
> Full_Name: alexios galanos
> Version: 2.8.1
> OS: windows/vista
> Submission from: (NULL) (81.100.160.71)
>
> While the script editor now respects user preferences for the background color
> in 2.8.1, it does not do so for the user text color defaulting to black. So my
> pr
Just expressing MHO: The algorithm cannot give predictions in classes
that never appear in the training data, so any entries in the loss
matrix related to such classes are irrelevant w.r.t. the training data.
They should be removed before feeding to rpart (or any other algorithm
that can make use
Petr Savicky wrote:
>
>> Notice that the discrepancy comes from sums that really are identical
>> values (in decimal arithmetic), but where the binary FP inaccuracy makes
>> them slightly different.
>>
>> [for a nice picture, continue the example with
>>
>>> tt <- table(signif(zz,7))
>>> plot(as
On 05/05/2009 5:04 AM, robin hankin wrote:
Hi Duncan
I asked this question to R-devel, and there was no reply, so I thought
I'd ask you
directly. Any ideas?
best wishes
Robin
I am having difficulty including a LaTeX formula in an Rd
file.
The example given in section 2.7 in 'Parsing Rd f
> "PD" == Peter Dalgaard
> on Mon, 04 May 2009 19:28:06 +0200 writes:
PD> Petr Savicky wrote:
>> On Mon, May 04, 2009 at 05:39:52PM +0200, Martin Maechler wrote:
>> [snip]
>>> Let me quickly expand the tasks we have wanted to address, when
>>> I started changing fa
On Mon, May 04, 2009 at 07:28:06PM +0200, Peter Dalgaard wrote:
> Petr Savicky wrote:
> > For this, we get
> >
> > > convert(0.3)
> > [1] "0.3"
> > > convert(1/3)
> > [1] "0." # 16 digits suffice
> > > convert(0.12345)
> > [1] "0.12345"
> > > convert(0.123456789012345
