Re: [Rd] Add to Documentation of atan2.

[Stefan Evert]

> On 18 May 2021, at 20:30, Ben Bolker  wrote:
> 
>  On my system (Ubuntu), 'man 3 catan' gives documentation on the function, 
> and says "The real part of y is chosen in the interval [-pi/2,pi/2]" - but 
> that _could_ be system-dependent.

My copy of "C in a Nutshell" suggests that this requirement is part of the C99 
standard (specified for catanh).

Best,
Stefan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] the pipe |> and line breaks in pipelines

[Stefan Evert]

I'm not a pipe user, so I may be overlooking some issue, but wouldn't simply 
putting identity() on the last line solve your main problem?

### Example 1 ###
 my_data_frame_1 %>%
   filter(some_conditions_1) %>%
   inner_join(my_data_frame_2, by = some_columns_1) %>%
   group_by(some_columns_2) %>%
   summarize(some_aggregate_functions_1) %>%
   filter(some_conditions_2) %>%
   left_join(my_data_frame_3, by = some_columns_3) %>%
   group_by(some_columns_4) %>%
   summarize(some_aggregate_functions_2) %>%
   arrange(some_columns_5) %>%
   identity()

I agree that it would be visually more pleasing to have the pipe symbols lined 
up at the start of each line, but I don't think it's worth breaking R's 
principle of evaluating any line with a complete expression.

With your solution 1, R wouldn't be able to execute any complete command 
because it would have to wait and see if the next line happens to start with 
%>%.

With your solution 2, 
  
  my_data_frame_1 %>%

would be a complete expression (because an extra trailing %>% is allowed on the 
last line of a pipe) and hence execute immediately rather than wait for the 
next line.

Best,
Stefan


> On 9 Dec 2020, at 06:45, Timothy Goodman  wrote:
> 
> Hi,
> 
> I'm a data scientist who routinely uses R in my day-to-day work, for tasks
> such as cleaning and transforming data, exploratory data analysis, etc.
> This includes frequent use of the pipe operator from the magrittr and dplyr
> libraries, %>%.  So, I was pleased to hear about the recent work on a
> native pipe operator, |>.
> 
> This seems like a good time to bring up the main pain point I encounter
> when using pipes in R, and some suggestions on what could be done about
> it.  The issue is that the pipe operator can't be placed at the start of a
> line of code (except in parentheses).  That's no different than any binary
> operator in R, but I find it's a source of difficulty for the pipe because
> of how pipes are often used.
> 
> [I'm assuming here that my usage is fairly typical of a lot of users; at
> any rate, I don't think I'm *too* unusual.]
> 
> === Why this is a problem ===
> 
> It's very common (for me, and I suspect for many users of dplyr) to write
> multi-step pipelines and put each step on its own line for readability.
> Something like this:
> 
>  ### Example 1 ###
>  my_data_frame_1 %>%
>filter(some_conditions_1) %>%
>inner_join(my_data_frame_2, by = some_columns_1) %>%
>group_by(some_columns_2) %>%
>summarize(some_aggregate_functions_1) %>%
>filter(some_conditions_2) %>%
>left_join(my_data_frame_3, by = some_columns_3) %>%
>group_by(some_columns_4) %>%
>summarize(some_aggregate_functions_2) %>%
>arrange(some_columns_5)
> 
> [I guess some might consider this an overly long pipeline; for me it's
> pretty typical.  I *could* split it up by assigning intermediate results to
> variables, but much of the value I get from the pipe is that it lets my
> code communicate which results are temporary, and which will be used again
> later.  Assigning variables for single-use results would remove that
> expressiveness.]
> 
> I would prefer (for reasons I'll explain) to be able to write the above
> example like this, which isn't valid R:
> 
>  ### Example 2 (not valid R) ###
>  my_data_frame_1
>%>% filter(some_conditions_1)
>%>% inner_join(my_data_frame_2, by = some_columns_1)
>%>% group_by(some_columns_2)
>%>% summarize(some_aggregate_functions_1)
>%>% filter(some_conditions_2)
>%>% left_join(my_data_frame_3, by = some_columns_3)
>%>% group_by(some_columns_4)
>%>% summarize(some_aggregate_functions_2)
>%>% arrange(some_columns_5)
> 
> One (minor) advantage is obvious: It lets you easily line up the pipes,
> which means that you can see at a glance that the whole block is a single
> pipeline, and you'd immediately notice if you inadvertently omitted a pipe,
> which otherwise can lead to confusing output.  [It's also aesthetically
> pleasing, especially when %>% is replaced with |>, but that's subjective.]
> 
> But the bigger issue happens when I want to re-run just *part* of the
> pipeline.  I do this often when debugging: if the output of the pipeline
> seems wrong, I re-run the first few steps and check the output, then
> include a little more and re-run again, etc., until I locate my mistake.
> Working in an interactive notebook environment, this involves using the
> cursor to select just the part of the code I want to re-run.
> 
> It's fast and easy to select *entire* lines of code, but unfortunately with
> the pipes placed at the end of the line I must instead select everything
> *except* the last three characters of the line (the last two characters for
> the new pipe).  Then when I want to re-run the same partial pipeline with
> the next line of code included, I can't just press SHIFT+Down to select it
> as I otherwise would, but instead must move the cursor horizontally to a
> position three characters before the end 

Re: [R-pkg-devel] Submission to CRAN Contributed Documentation

[Stefan Evert]

Did you read the notice

Note: The CRAN area for contributed documentation is frozen and no 
longer actively maintained

at the top of that page?

Best,
Stefan


> On 4 Sep 2020, at 14:43, Jakub Nowosad  wrote:
> 
> Dear all,
> 
> I have tried to submit a textbook to the CRAN Contributed Documentation
> (https://cran.r-project.org/other-docs.html#nenglish).
> 
> However, the instruction on how to do that are vague. The Contributed
> Documentation page states "To submit, follow the submission instructions
> on the CRAN main page.", however, it is impossible to upload non-R
> package using the standard way (https://cran.r-project.org/submit.html).
> Therefore, I decided to follow another CRAN suggestion "If this fails,
> upload toftp://CRAN.R-project.org/incoming/  and send an email to
> cran-submissi...@r-project.org    
> following the policy.", uploaded the PDF to CRAN incoming FTP and wrote
> an email several days ago. I did not get any answers back.
> 
> Could you suggest me a proper way how to add a document to the CRAN
> Contributed Documentation?
> 
> Best,
> 
> Jakub Nowosad
> 
> -- 
> https://nowosad.github.io/ | @jakub_nowosad | nowosad.ja...@gmail.com
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] nlminb with constraints failing on some platforms

[Stefan Evert]

Also no error on MacOS 10.13.6, R 3.5.1 with system-supplied VecLib BLAS.

> > f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 )
> > opt <- nlminb(rep(0, 10), f, lower=-1, upper=3)
> > str(opt)
> List of 6
>  $ par: num [1:10] 1 1 1 1 1 ...
>  $ objective  : num -41.4
>  $ convergence: int 0
>  $ iterations : int 65
>  $ evaluations: Named int [1:2] 92 773
>   ..- attr(*, "names")= chr [1:2] "function" "gradient"
>  $ message: chr "relative convergence (4)"
> > xhat <- rep(1, 10)
> > all.equal(opt$par, xhat,  tol=0) # good: 5.53 e-7
> [1] "Mean relative difference: 3.368798e-06"
> > all.equal(opt$objective, f(xhat), tol=0) # good: 1.8 e-12
> [1] "Mean relative difference: 1.09683e-11"
> > abs( opt$objective - f(xhat) ) < 1e-4  ## Must be TRUE
> [1] TRUE

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [R-pkg-devel] Replicate solaris errors

[Stefan Evert]

> On 12 Aug 2018, at 00:18, peter dalgaard  wrote:
> 
> Have you tried asking CRAN for help? I mean, if you don't fix an obvious 
> error, with a well-known cause, like the log thing, they'll get fed up and 
> throw you off. However, fixing and then discovering an issue elsewhere is 
> different, especially if you cannot easily reproduce it at your end. 

When I did that for a similar problem with the 'sparsesvd' package – before 
Solaris was available via R-hub, so I really had no chance to chase down the 
problem without help from CRAN – I never got a response.

I later managed to identify and fix the problem by tedious trial & error via 
R-hub.

Symptoms were similar: build succeeded, but the package always crashed when 
running tests and examples, but only on Solaris.

The solution turned out to be that the 3rd-party C code my package wraps 
defines a C function named store(), which causes Solaris to segfault for 
reasons that I don't understand at all.  But renaming the function to anything 
else solved the issue.

Best,
Stefan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] Control multi-threading in standard matrix product

[Stefan Evert]

> On 21 Aug 2017, at 17:40, Ghislain Durif  wrote:
> 
> I understand why this is a BLAS related issue and not directly an R related 
> issue. Nonetheless, my concern was for non-advanced R users, that may don't 
> even know what BLAS is. For instance, I have a package on the CRAN that use 
> 'mclapply' from the 'parallel' package and the multi-threading from BLAS 
> (when using OpenBLAS) totally messes up with my multi-threading (regarding 
> computing performance). Hence, I think that some of the users of my package, 
> if not aware of that, may encounter severe issues, especially because this 
> package is mainly used to analyse bioinformatics data, which requires 
> important computing resources.

Why do you expect that users who don't know what BLAS is would explicitly 
install a multi-threaded BLAS on their Ubuntu machine? 

Best,
Stefan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] dist function in R is very slow

[Stefan Evert]

> By the way, since the tcrossprod function in the Matrix package is so fast, 
> the Euclidean distance can be computed very fast:

Indeed.

> euc_dist <- function(m) {mtm <- Matrix::tcrossprod(m); sq <- rowSums(m*m);  
> sqrt(outer(sq,sq,"+") - 2*mtm)}

There are two reasons why I didn't use this optimization in "wordspace":

1) It can be inaccurate for small distances between vectors of large Euclidean 
length because of loss of significance in the subtraction step.  This is not 
just a theoretical concern – I've seen data sets were this became a real 
problem.

2) It incurs substantial memory overhead for a large distance matrix. Your code 
allocates at least five matrices of this size: outer(…), mtm, 2 * mtm, outer(…) 
- 2*mtm, and the final result obtained by taking the square root.  [Actually, 
there is additional overhead for m*m (an even larger matrix) when computing the 
Euclidean norms, but this could be avoided with sq <- rowNorms(m, 
method="euclidean").]

I am usually more concerned about RAM than raw processing speed, so the package 
was designed to keep memory overhead as low as possible and allow users to work 
with realistic data sets on ordinary laptop computers.


> It takes less than 50 seconds for my (dense) matrix of 5,054 rows and 12,803 
> columns, while dist.matrix with method="euclidean" takes almost 10 minutes 
> (which is still orders of magnitude faster than dist).

It's a little disappointing that dist.matrix() is still relatively slow despite 
all simplifications and better cache consistency (the function automatically 
transposes the input matrix and computes distances by columns rather than 
rows).  I'm a little surprised about your timing, though.  Testing with a 
random 5000 x 2 matrix, my MacBook computers the full Euclidean distance 
matrix in about 5 minutes.  

If your machine (and version of R) supports OpenMP, you can improve performance 
by allowing multithreading with wordspace.openmp(threads=).  In my test 
case, I get a 2.2x speed-up with 4 threads (2m 15s instead of 5m).


Best wishes,
Stefan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] dist function in R is very slow

[Stefan Evert]

> On 17 Jun 2017, at 08:47, Moshe Olshansky via R-devel  
> wrote:
> 
> I am visualising high dimensional genomic data and for this purpose I need to 
> compute pairwise distances between many points in a high-dimensional space 
> (say I have a matrix of 5,000 rows and 20,000 columns, so the result is a 
> 5,000x5,000 matrix or it's upper diagonal).Computing such thing in R takes 
> many hours (I am doing this on a Linux server with more than 100 GB of RAM, 
> so this is not the problem). When I write the matrix to disk, read it ans 
> compute the distances in C, write them to the disk and read them into R it 
> takes 10 - 15 minutes (and I did not spend much time on optimising my C 
> code).The question is why the R function is so slow? I understand that it 
> calls C (or C++) to compute the distance. My suspicion is that the transposed 
> matrix is passed to C and so each time a distance between two columns of a 
> matrix is computed, and since C stores matrices by rows it is very 
> inefficient and causes many cache misses (my first C implementation was like 
> this and I had to stop the
  run after an hour when it failed to complete).

There are two many reasons for the relatively low speed of the built-in dist() 
function: (i) it operates on row vectors, which leads to many cache misses 
because matrices are stored by column in R (as you guessed); (ii) the function 
takes care to handle missing values correctly, which adds a relatively 
expensive test and conditional branch to each iteration of the inner loop.

A faster implementation, which omits the NA test and can compute distances 
between column vectors, is available as dist.matrix() in the "wordspace" 
package.  However, it cannot be used with matrices that might contain NAs (and 
doesn't warn about such arguments).

If you want the best possible speed, use cosine similarity (or equivalently, 
angular distance).  The underlying cross product is very efficient with a 
suitable BLAS implementation.

Best,
Stefan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] issues with dev.new avoiding RStudio plot device on unix?

[Stefan Evert]

> The problem is that the device chosen by dev.new() depends on the GUI.
> You can see the code that does this in grDevices:::.onLoad.  So in fact
> with noRstudioGD=TRUE, the decision is identical to what it is in R:
> you only get X11 if your GUI is X11 or Tk, you get pdf otherwise.
> It's pretty common to use R on a machine where X11 won't work, so this
> makes sense.

But not if running from RStudio always causes the X11 check to fail.  If the 
function is used outside RStudio, there's little point in specifying 
noRStudioGD=TRUE in the first place.

If you consider the code used to determine whether quartz() or X11() is 
available

dsp <- Sys.getenv("DISPLAY")
if (.Platform$OS.type == "windows")
windows
else if (.Platform$GUI == "AQUA" || ((!nzchar(dsp) || 
grepl("^/tmp/launch-", dsp)) && .Call(C_makeQuartzDefault)))
quartz
else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
X11
else defdev 

you can see that it checks for a DISPLAY variable and assumes that X11 can be 
used if it is set.  Wouldn't it be just as safe to add RStudio to the list of 
accepted .Platform$GUIs?

In my case (Mac OS X 10.10.5), I'd like to get a quartz device.  The problem 
here is that I have XQuartz installed, so DISPLAY is always set and looks like 
this

/private/tmp/com.apple.launchd.2wKas4wzPe/org.macosforge.xquartz:0 

while dev.new() checks for ^/tmp/launch-; I suppose the DISPLAY variable has 
changed between different versions of Mac OS X or XQuartz.  Perhaps the 
additional patterns could just be added to the grepl() call?

Best,
Stefan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] issues with dev.new avoiding RStudio plot device on unix?

[Stefan Evert]

Same problem here on Mac OS X 10.10.5 with R 3.2.2 and RStudio 0.99.473.

I think dev.new() tries to find a suitable device in an interactive session 
with this code

dsp <- Sys.getenv("DISPLAY")
if (.Platform$OS.type == "windows")
windows
else if (.Platform$GUI == "AQUA" || ((!nzchar(dsp) || 
grepl("^/tmp/launch-", dsp)) && .Call(C_makeQuartzDefault)))
quartz
else if (nzchar(dsp) && .Platform$GUI %in% c("X11", "Tk"))
X11
else defdev 

which fails for me because RStudio sets .Platform$GUI to "RStudio" (thanks, 
RStudio!) and my DISPLAY variable looks like this

/private/tmp/com.apple.launchd.2wKas4wzPe/org.macosforge.xquartz:0

so the grepl() on dsp doesn't match.

Best,
Stefan


> On 26 Sep 2015, at 06:42, Skye Bender-deMoll  wrote:
> 
> Sorry, should have given more background.  x11 works fine on all my systems 
> when called by x11().  I'm the maintainer of a package that uses the 
> animation library, which has performance issues when used with the RStudio 
> plot device.  But if you call plot.new() when using RStudio, you get an 
> RStudio device, not the standard device for the platform because it overrides 
> the device option.  So I've had to have the library do platform detection and 
> platform-specific device calls, which R CMD check doesn't like.  I believe 
> that noRStudioGD argument was avoided to give users a way around this, but it 
> doesn't seem to be behaving correctly in the unix interactive case.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] BLAS benchmarks on R 2.12.0 and related performance issues

[Stefan Evert]

On 2 Nov 2010, at 19:33, Prof. John C Nash wrote:

 Ultimately we need good performance benchmarks. They are difficult to set up 
 properly and
 tedious to run. Maybe a good subject for a Google Summer of Code project for 
 next year or
 some undergraduate projects.

Seconded and thirded!

Stefan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Cannot Change Function (PR#14041)

[Stefan Evert]

What makes you think this is a bug in R?

Whenever I try changing a function, it keeps coming up with the same  
error

message.

I have the function
CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state  
for the log

 [...]

}

When I try to run it in the loop:
for (j in 1:length(BB_mean_ref)){	# find copy number states (0 for  
homozygous
deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single  
amplification,

4 for multiple amplification)
state_log_sum[j]=CN_state_log_sum(Tot_log_sum[j])
state_sum_log[j]=CN_state_sum_log(Tot_sum_log[j])
}
I get the error message:
Error in Im(Tot_sum_log) != 0 || Re(Tot_sum_log) - 2 :
 could not find function ||-


The error message indicates that the problem happens in the function  
CN_state_sum_log() rather than CN_state_log_sum(), so it's hardly  
surprising that changing the latter doesn't have any effect.


My guess: you've go a condition (Re(Tot_sum_log)-2), which is  
mistaken for the assignment operator - by the R parser. Adding some  
whitespace (Re(Tot_sum_log)  -2) should help both R and human readers  
to make sense of it.


Best,
Stefan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R 2.9.2 crashes when sorting latin1-encoded strings

[Stefan Evert]

Hi everyone!

I think I stumbled over a bug in the latest R 2.9.2 patched for OS X:


R version 2.9.2 Patched (2009-09-24 r49861)
i386-apple-darwin9.8.0



When I try to sort latin1-encoded character vectors, R sometimes  
crashes with a segmentation fault.  I'm running OS X 10.5.8 and have  
observed this behaviour both with the i386 and x86_64 builds, in the  
R.app GUI as well as on the command line.


Here's a minimal example that reliably triggers the crash on my machine:

=
print(sessionInfo())

words - c(aa, ab, a\xfc, a\xe4, b\xe4, b\xfc, \xe4\xfc)
str(words)

print(table(Encoding(words)))
Encoding(words) - latin1  # this is the correct encoding!
print(table(Encoding(words)))

N - 1000
words - rep(words, length.out=N)

print(N)
for (i in 1:N) {
x - words[1:i]
# the following line will crash for some i, depending on the particular
# strings in words and the subset selected for x above
order(x)
}
=

The output I get from this code is appended at the end of the mail.  
Note that R incorrectly declares the latin1 strings in word to have  
UTF-8 encoding (this seems wrong to me because the \x escapes insert  
raw bytes into the string). The crash only occurs if the correct  
latin1 encoding (or unknown) is explicitly specified. Otherwise  
the string handling code appears to ignore everything after the first  
invalid multibyte character.


I haven't been able to trigger the bug without some kind of loop.  The  
crash always occurs at the same iteration, but this changes depending  
on the contents of words and the specific subset selected in each  
loop iteration.  Also note that the 64-bit version of R gives a  
different error message.  If I omit the unrelated statement  
print(N), the 64-bit version segfaults and the 32-bit version just  
hangs with high CPU load. All this suggests to me that there must be  
some insidious memory corruption or stack/range overflow in the  
internal ordering code.


Can other people reproduce this problem on different platforms and  
possibly with different versions of R?



BTW, I ran into the crash when trying to read.delim() a file in latin1  
encoding, using either encoding=latin1 or fileEncoding=latin1, and  
then converting it back and forth between a character vector and a  
factor.  I still don't understand what's going on there.  The  
behaviour of read.delim() seems to depend very much on my locale  
settings when running R, which is rather unpleasant.  Is there a way  
to find out how strings are stored internally (i.e. getting the exact  
byte representation) and whether R believes them to be in UTF-8 or  
latin1 encoding?



Best regards,
Stefan Evert

[ stefan.ev...@uos.de | http://purl.org/stefan.evert ]





Output of sample code on my machine:


 print(sessionInfo())
R version 2.9.2 Patched (2009-09-24 r49861)
i386-apple-darwin9.8.0

locale:
en_GB/en_GB/C/C/en_GB/en_GB

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

 words - c(aa, ab, a\xfc, a\xe4, b\xe4, b\xfc,  
\xe4\xfc)

 str(words)
chr [1:7] aa ab a\xfc a\xe4 b\xe4 b\xfc ...
 print(table(Encoding(words)))

unknown   UTF-8
2   5

 Encoding(words) - latin1  # this is the correct encoding!
 print(table(Encoding(words)))

latin1 unknown
5   2

 N - 1000
 words - rep(words, length.out=N)

 print(N)
[1] 1000
 for (i in 1:N) {
+   x - words[1:i]
+   # the following line will crash for some i, depending on the  
particular

+   # strings in words and the subset selected for x above
+   order(x)
+ }

*** caught bus error ***
address 0x86, cause 'non-existent physical address'

Traceback:
1: order(x)
aborting ...
Bus error


64-bit version:


 print(sessionInfo())
R version 2.9.2 Patched (2009-09-24 r49861)
x86_64-apple-darwin9.8.0

locale:
en_GB/en_GB/C/C/en_GB/en_GB

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

 words - c(aa, ab, a\xfc, a\xe4, b\xe4, b\xfc,  
\xe4\xfc)

 str(words)
chr [1:7] aa ab a\xfc a\xe4 b\xe4 b\xfc ...
 print(table(Encoding(words)))

unknown   UTF-8
2   5

 Encoding(words) - latin1  # this is the correct encoding!
 print(table(Encoding(words)))

latin1 unknown
5   2

 N - 1000
 words - rep(words, length.out=N)

 print(N)
[1] 1000
 for (i in 1:N) {
+   x - words[1:i]
+   # the following line will crash for some i, depending on the  
particular

+   # strings in words and the subset selected for x above
+   order(x)
+ }
Error in order(x) : 'translateCharUTF8' must be called on a CHARSXP
Execution halted



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] Semantics of sequences in R

[Stefan Evert]

Dear vQ,


vectors (can-be-considered-lists),


can you please stop repeating this nonsense?  I don't think anybody  
ever claimed that vectors can be considered list.  It's rather the  
other way round: lists can also be seen as vectors to R (possibly they  
are implemented as such, but I don't much about the internals of R).


 a - as.list(1:10)
 b - 1:10
 is.vector(a)
[1] TRUE
 is.list(a)
[1] TRUE
 is.vector(b)
[1] TRUE
 is.list(b)
[1] FALSE

Hence the confusion about

 mode(as.vector(a))
[1] list

which prompted the original comment that you are taking so much  
exception to.



as to it could only work in very specific circumstances -- no, it
would work for any list whatsoever, provided the user has a correctly
implemented comparator.  for example, i'd like to sort a list of  
vectors

by the vectors' length -- is this a very exotic idea?


Honestly, I can't think of a situation where I would want to do than  
in R.  In a Perl script, quite likely; but this is a kind of data  
manipulation that R wasn't really designed for IMHO.


Not that I'd mind having sort() operate properly on lists; it just  
isn't something I miss in the language.


Best,
Stefan

[ stefan.ev...@uos.de | http://purl.org/stefan.evert ]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5

[Stefan Evert]

I guess that we this comparing apples with oranges here:
a default R install is leaving binaries in the path when performing  
a default install, which does not seem to be the case here  
(therefore forcing a hunt for the executable for the R console and  
resulting in the present thread).



Well, the assumption seems to be that end users who just run an  
installer without reading the associated documentation won't be  
interested in a command-line version and will just start the R GUI  
that shows up in their /Applications folder ...


The point seems to be slightly missed here: the result of installing  
R is that there is no R executable in the path, and that adding the  
only bin/ directory coming with the install to be path results in a  
broken system.


... and that people who add directories to their PATH tend to read  
instructions carefully.  The download page for the Mac OS X binaries  
says:



You may also want to read the R FAQ and R for Mac OS X FAQ.


and in the Mac OS X FAQ you'll easily find the necessary instructions  
for using the command-line version:



3 Command line version of R
The command line version of R is identical to R as used on other  
unix operating systems. Therefore general documentation forR applies  
to this version as well. On each release (and patched-release) ready  
to use binaries are distributed through CRAN. These binaries come  
with a common installer used by R.app so please read the related  
notes (see How to get R.app). To use Ryou probably need to add a  
symbolic link on your system as the R binary is located inside the  
framework. Suppose you have the/usr/local/bin directory on your  
system (if you do not have one, you can use /usr/bin instead) you  
should just type in your Terminal (a root password is required)


sudo ln -s /Library/Frameworks/R.framework/Resources/R /usr/local/ 
bin/R
Assuming that you have /usr/local/bin in your PATH environment  
variable, you will be able to launch R from any location on your  
system just by typing R. In this way, when you install a new version  
of the R.framework this link will point to the latest R binary.




I suppose that with doing things the Unix way you've probably been  
referring to the package managers / installers that most Linux  
distributions use and which do indeed make their installed programs  
available from the command line.






Best regards,
Stefan Evert

[ [EMAIL PROTECTED] | http://purl.org/stefan.evert ]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5

[Stefan Evert]

The steps needed to generate the error are:

- install a binary distribution of R (default location)
- add R to the PATH


Did you actually add

/Library/Frameworks/R.framework/Resources/bin/

to your PATH?  You're not supposed to do that!  What made you think so?

This directory contains a range of support scripts for R which are not  
intended for direct use from the command line or other programs.  In  
my installation, there's just a symlink from /usr/bin/R to the R  
binary in the directory above, which AFAIK is the only program you  
need to invoke directly.


In your case, R's INSTALL script, which implements the R CMD  
INSTALL functionality masks the standard install program in /usr/ 
bin/install, so Python's installer now picks up a completely wrong  
program.  Even if you edit R's INSTALL script, it'll do something  
entirely different from what you expect.


BTW, putting the R binary directory ahead of system directories such  
as /usr/bin in your PATH is an even worse idea than including it there  
in the first place. ;-)




Best regards,
Stefan Evert

[ [EMAIL PROTECTED] | http://purl.org/stefan.evert ]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel