>
> (2) More process and I/O facilities, specifically I'd like
> forking and
> something like a "functionconnection" which works like a
> textconnection but obtains input from / feeds output to a
> function.
> This would allow running an external process that receives inp
On Nov 8, 2007 3:16 PM, Jan T. Kim <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 08, 2007 at 01:35:34PM -0500, Duncan Murdoch wrote:
> > On 11/8/2007 1:26 PM, Barry Rowlingson wrote:
> > > hadley wickham wrote:
> > >
> > >> You're assuming an automatic cast from numbers into strings? What if
> > >> a +
On Thu, Nov 08, 2007 at 01:35:34PM -0500, Duncan Murdoch wrote:
> On 11/8/2007 1:26 PM, Barry Rowlingson wrote:
> > hadley wickham wrote:
> >
> >> You're assuming an automatic cast from numbers into strings? What if
> >> a + "4" threw an error?
> >
> > What's wrong with commas anyway when usin
On 11/8/2007 2:44 PM, Peter Dalgaard wrote:
...
> (We've been here before, haven't we?)
For anyone interested, last time was here:
https://mailman.stat.ethz.ch/pipermail/r-devel/2006-August/038991.html
and the very first thing Martin said in that message was that it was a
recurring theme.
Du
On 11/8/2007 2:44 PM, Peter Dalgaard wrote:
> Duncan Murdoch wrote:
>> On 11/8/2007 11:51 AM, Thomas Lumley wrote:
>>
>>> On Wed, 7 Nov 2007, Duncan Murdoch wrote:
>>>
>>>
At first I thought you were complaining about the syntax, which I find
ugly. There was a proposal last year
Duncan Murdoch wrote:
> On 11/8/2007 11:51 AM, Thomas Lumley wrote:
>
>> On Wed, 7 Nov 2007, Duncan Murdoch wrote:
>>
>>
>>> At first I thought you were complaining about the syntax, which I find
>>> ugly. There was a proposal last year to overload + to do concatenation
>>> of strings, so
On 11/8/2007 2:27 PM, Alberto Monteiro wrote:
> Duncan Murdoch wrote:
>>
>>> and there's always sprintf() for those moments when you
>>> want neat formatting.
>>
>> That's good when you want good control over the formatting, but it
>> doesn't tend to be all that readable, with the variables all l
Duncan Murdoch wrote:
>
>> and there's always sprintf() for those moments when you
>> want neat formatting.
>
> That's good when you want good control over the formatting, but it
> doesn't tend to be all that readable, with the variables all listed
> at the end, instead of in between the bits o
On 08-Nov-07 18:39:57, Gabor Grothendieck wrote:
> On Nov 8, 2007 1:26 PM, Barry Rowlingson <[EMAIL PROTECTED]>
> wrote:
>> hadley wickham wrote:
>>
>> > You're assuming an automatic cast from numbers into strings? What
>> > if
>> > a + "4" threw an error?
>>
>> What's wrong with commas anyway wh
On Nov 8, 2007 1:26 PM, Barry Rowlingson <[EMAIL PROTECTED]> wrote:
> hadley wickham wrote:
>
> > You're assuming an automatic cast from numbers into strings? What if
> > a + "4" threw an error?
>
> What's wrong with commas anyway when using cat():
>
> > cat("x is ",x,' and y is ',y,'\n',sep='')
On 11/8/2007 1:26 PM, Barry Rowlingson wrote:
> hadley wickham wrote:
>
>> You're assuming an automatic cast from numbers into strings? What if
>> a + "4" threw an error?
>
> What's wrong with commas anyway when using cat():
>
> > cat("x is ",x,' and y is ',y,'\n',sep='')
> x is 1 and y i
hadley wickham wrote:
> You're assuming an automatic cast from numbers into strings? What if
> a + "4" threw an error?
What's wrong with commas anyway when using cat():
> cat("x is ",x,' and y is ',y,'\n',sep='')
x is 1 and y is 2
and there's always sprintf() for those moments when you
On 11/8/2007 12:57 PM, hadley wickham wrote:
>> My objection, at least, was that + should be *associative*. I don't think
>> anyone would expect a + b and b+a to be the same for strings, but I do
>> think the fact that (a+b)+c and a+(b+c) would be different (if some of a,
>> b,c were strings) has
On 11/8/2007 11:51 AM, Thomas Lumley wrote:
> On Wed, 7 Nov 2007, Duncan Murdoch wrote:
>
>>
>> At first I thought you were complaining about the syntax, which I find
>> ugly. There was a proposal last year to overload + to do concatenation
>> of strings, so you'd type cat("x=" + x + "y=" + y + "
> My objection, at least, was that + should be *associative*. I don't think
> anyone would expect a + b and b+a to be the same for strings, but I do
> think the fact that (a+b)+c and a+(b+c) would be different (if some of a,
> b,c were strings) has real potential for ugliness.
You're assuming an
On Wed, 7 Nov 2007, Duncan Murdoch wrote:
>
> At first I thought you were complaining about the syntax, which I find
> ugly. There was a proposal last year to overload + to do concatenation
> of strings, so you'd type cat("x=" + x + "y=" + y + "\n"), but there was
> substantial resistance, on the
I'm anxiously awaiting my copy of the soon to be published "A First
Course in Statistical Programming with R" by
W. John Braun
University of Western Ontario
Duncan J. Murdoch
University of Western Ontario
Paperback
(ISBN-13: 9780521694247)
http://www.cambridge.org/catalogue/catalogue.asp?isbn=9
Although Crawley is an ecologist, not a programmer or statistician. But
he is an FRS. Maybe that counts for something. ;-)
Simon.
On Thu, 2007-11-08 at 01:56 +0300, Alexy Khrabrov wrote:
> With all due respect to the great book -- of which I own 2 copies I
> bought new -- it's not an "O'Reilly
On 11/7/2007 8:13 AM, Duncan Murdoch wrote:
> On 11/7/2007 7:46 AM, Alexy Khrabrov wrote:
>> Greetings -- coming from Python/Ruby perspective, I'm wondering about
>> certain features of R as a programming language.
>
> Lots of question, I'll intersperse some answers.
>>
>> Say I have a huge tab
With all due respect to the great book -- of which I own 2 copies I
bought new -- it's not an "O'Reilly Programming in " book. The
idea of a programming book like that is to thoroughly treat the
language from a programmer's standpoint, in a fairly standard way,
such as Ruby or Python.
As
On 11/7/2007 7:46 AM, Alexy Khrabrov wrote:
> Greetings -- coming from Python/Ruby perspective, I'm wondering about
> certain features of R as a programming language.
Lots of question, I'll intersperse some answers.
>
> Say I have a huge table t of the form
>
> run ord unitwords
>> (Will someone here please write an O'Reilly's "Programming in R"? :)
Someone already has ... see Venable and Ripley's S PROGRAMMING.
**However** R is more than a general purpose programming language: it is a
programming language specifically designed for data analysis -- including
statistical
On 11/7/2007 8:17 AM, Alexy Khrabrov wrote:
> On Nov 7, 2007, at 4:13 PM, Duncan Murdoch wrote:
>
>>> And, still no option processing as in GNU long options, or python
>>> or ruby's optparse.
>>> What's the semantics of parameter passing -- by value or by
>>> reference?
>>
>> By value.
>
> T
On Nov 7, 2007, at 4:13 PM, Duncan Murdoch wrote:
>> And, still no option processing as in GNU long options, or python
>> or ruby's optparse.
>> What's the semantics of parameter passing -- by value or by
>> reference?
>
> By value.
Thanks Duncan! So if I have a huge table t, and the idea w
Most of these have been answered but here are a few
additional options.
On Nov 7, 2007 7:46 AM, Alexy Khrabrov <[EMAIL PROTECTED]> wrote:
>
> Is there anything less ugly than
>
> print(paste("x=",x,"y=",y))
>
> library(gsubfn)
> a <- 1; b <- 2
> fn$cat("a = $a b = $b\n")
a = 1 b = 2
See gsubfn h
25 matches
Mail list logo
