Re: [Rd] heatmap.2 in gplots (PR#8587)
[EMAIL PROTECTED] wrote:
> Full_Name: Shane Neph
> Version: 2.2.1
> OS: mac os x
> Submission from: (NULL) (71.113.43.247)
>
>
> While I found the names of the package authors and maintainer, I was
> unsuccessful in finding any contact information.
This is not a bug in R, hence please do not post it to R-bugs, R-devel
would have been much more appropriate.
You will get contact information of the maintainer by typing, e.g.:
library(help=gplots)
Uwe Ligges
> The preliminary documentation for heatmap.2 is inconsistent in at least a
> couple
> of places when discussing the suppression of one or more dendrograms (and
> column/row ordering in general).
> In the Details section, in regards to the Rowv and Colv parameters, "If either
> is NULL, no reordering will be done for the corresponding side." The default
> value for these parameters is NULL. With NULL, the dendrograms are computed
> (and hence reordering is done).
> In the Arguments section, Rowv shows "determines if and how the row dendrogram
> should be reordered. Either a dendrogram or a vector of values to reorder the
> row dendrogram of FALSE to suppres reordering or by default, NULL, ...". In
> particular, the portion about FALSE should be contrasted with the portion
> about
> NULL in the Details section.
>
> Finally, it is my belief that part of the intention or using FALSE (or
> whatever
> is supposed to suppress the reordering) is to suppress the actual dendrogram
> drawing as well. This is similar to how NA works for the same argument names
> in
> the heatmap function. Achieving this behavior is straightforward. Assuming
> FALSE is the argument for suppression, the column dendrogram/reordering can be
> achieved by modifying heatmap.2 near line 78-80:
>
> FROM:
> else {
> colInd <- order(Colv)
> }
>
> TO:
> else if ( isTRUE(Colv) ) {
> colInd <- order(Colv)
> }
> else
> colInd <- 1:nc
>
> This does suppress the automatic column ordering/dendrogram as desired.
> Similar
> fixes for the Rowv argument are needed.
>
> R is great - keep up the work.
> Shane
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] floor and ceiling can't handle more than 15 decimal places (PR#8590)
Full_Name: Ben Phalan Version: 2.2.1 OS: Win XP Submission from: (NULL) (131.111.111.231) I have noticed that floor returns the wrong number when there are more than 15 decimal places: > floor(6.999) [1] 6 > floor(6.) [1] 7 There is a similar problem with ceiling, so this may apply to all/most rounding functions? > ceiling (2.001) [1] 3 > ceiling (2.0001) [1] 2 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] floor and ceiling can't handle more than 15 decimal pla (PR#8591)
On 12-Feb-06 [EMAIL PROTECTED] wrote: > Full_Name: Ben Phalan > Version: 2.2.1 > OS: Win XP > Submission from: (NULL) (131.111.111.231) > > > I have noticed that floor returns the wrong number when there are more > than 15 > decimal places: > >> floor(6.999) > [1] 6 >> floor(6.) > [1] 7 > > There is a similar problem with ceiling, so this may apply to all/most > rounding functions? > >> ceiling (2.001) > [1] 3 >> ceiling (2.0001) > [1] 2 This is not a problem (nor a bug) with 'floor' or 'ceiling'. The "problem" (in quotes because the real problem is the user's) is in R, intrinsic to the finite-length floating-point arithmetic which is used. See: > 6.999 - 7 [1] -8.881784e-16 > 6. - 7 [1] 0 > 2.001 - 2 [1] 8.881784e-16 > 2.0001 - 2 [1] 0 so, in fact, R cannot "see" the 16th decimal place when you enter a number to that precision -- it is simply lost. Exactly the same "problem" would arise at some point whatever the finite precision to which a floating-point number is stored. The effect is not confined to functions 'floor' and 'ceiling' or any similar "rounding" functions. It applies to all functions; it is simply more obvious with the rounding functions. Enter .Machine and the first two items in the output are: $double.eps [1] 2.220446e-16 $double.neg.eps [1] 1.110223e-16 showing that the smallest difference which can be "seen" by R is greater than 1-^(-16). So, when you type it in, you *think* you have entered 2.0001 into R, but you have not. So the user has to face the problem of how to cope with the finite-length representation in any situation where the distinction between 2 and 2.0001 really matters. Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 12-Feb-06 Time: 15:37:53 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] floor and ceiling can't handle more than 15 decimal pla
On 12-Feb-06 [EMAIL PROTECTED] wrote: > Full_Name: Ben Phalan > Version: 2.2.1 > OS: Win XP > Submission from: (NULL) (131.111.111.231) > > > I have noticed that floor returns the wrong number when there are more > than 15 > decimal places: > >> floor(6.999) > [1] 6 >> floor(6.) > [1] 7 > > There is a similar problem with ceiling, so this may apply to all/most > rounding functions? > >> ceiling (2.001) > [1] 3 >> ceiling (2.0001) > [1] 2 This is not a problem (nor a bug) with 'floor' or 'ceiling'. The "problem" (in quotes because the real problem is the user's) is in R, intrinsic to the finite-length floating-point arithmetic which is used. See: > 6.999 - 7 [1] -8.881784e-16 > 6. - 7 [1] 0 > 2.001 - 2 [1] 8.881784e-16 > 2.0001 - 2 [1] 0 so, in fact, R cannot "see" the 16th decimal place when you enter a number to that precision -- it is simply lost. Exactly the same "problem" would arise at some point whatever the finite precision to which a floating-point number is stored. The effect is not confined to functions 'floor' and 'ceiling' or any similar "rounding" functions. It applies to all functions; it is simply more obvious with the rounding functions. Enter .Machine and the first two items in the output are: $double.eps [1] 2.220446e-16 $double.neg.eps [1] 1.110223e-16 showing that the smallest difference which can be "seen" by R is greater than 1-^(-16). So, when you type it in, you *think* you have entered 2.0001 into R, but you have not. So the user has to face the problem of how to cope with the finite-length representation in any situation where the distinction between 2 and 2.0001 really matters. Hoping this helps, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 12-Feb-06 Time: 15:37:53 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
