[Rd] pb in regular expression with the character "-" (PR#9437)
Full_Name: FAN
Version: 2.4.0
OS: Windows
Submission from: (NULL) (159.50.101.9)
These are expected:
> grep("[\-|c]", c("a-a","b"))
[1] 1
> gsub("[\-|c]", "&", c("a-a","b"))
[1] "a&a" "b"
but these are strange:
> grep("[d|\-|c]", c("a-a","b"))
integer(0)
> gsub("[d|\-|c]", "&", c("a-a","b"))
[1] "a-a" "b"
Thanks
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to execute R scripts simultaneously from multiple threads
Vladimir Dergachev wrote: > On Wednesday 03 January 2007 3:47 am, Erik van Zijst wrote: > >>Appearantly the R C-API does not provide a mechanism for parallel >>execution.. >> >>It is preferred that the solution is not based on multi-processing (like >>C/S), because that would introduce IPC overhead. > > One thing to keep in mind is that IPC is very fast in Linux. So unless you > are > making lots of calls to really tiny functions this should not be an issue. Using pipes or shared memory to pass things around to other processes on the same box is very fast indeed, but if we base our design around something like RServe which uses TCP it could be significantly slower. Our R-based system will be running scripts in response to high-volume real-time stock exchange data, so we expect lots of calls to many tiny functions indeed. > What can be an issue is the overhead of starting a new R process. In which > case you can make some helper processes that do the same thing you wanted > from a multi-thread one and just pass the data around. Yes, we'll need to keep a pool of processes. Maybe use RServer, or build something ourselves around shared memory if the proof of concept proves TCP is too heavy for this. thanks, Erik > best > > Vladimir Dergachev > > >>Hopefully some thread-safe (single-proces) solution is readily >>available, written in C. >> >>What is the best solution to do this? >> >>(If there is no single-process solution, what is the alternative?) >> >>Regards, >>Erik. > > -- USENET would be a better laboratory is there were more labor and less oratory. -- Elizabeth Haley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem with function 'optimise' (PR#9438)
Full_Name: Karsten Krug Version: 2.4.0 OS: Open Suse 10.0, Windows XP Submission from: (NULL) (88.134.13.50) I found a problem in the 'optimise' function for one dimensional optimisation. Example 1: Try to find a maximum of the function below with the use of 'optimise' in the interval [0,0.5]. The function follows a parabola and has two local maxima located at the margins of the interval [0,0.5]. Please try the following code which performs this optimisation, produces a plot of the function within the given interval and adds the computed maximum returned by 'optimise()' ex1 <- function(x) log(4 * x^2 - 2 * x + 0.5) opt1 <- optimise(ex1, lower=0, upper=0.5, maximum=T) x <- seq(0,0.5,0.001) plot(x, ex1(x), type="l") abline(v=opt1$maximum, col="red") The returned value of the maximum is 0.309017 which is definitely wrong. Example 2: The next function has also two equivalent maxima this time not located at the margins of the interval [0, 9/41]. Thus, the maxima are real analytic extrema. The function 'optimise()' again returns a wrong value. ex2 <- function(x) log((18/41) * x - 2 * x^2) + 16 * log(4 * x^2 - (36/41) * x + (9/41)) + 24 * log((23/82) + (18/41) * x - 2 * x^2) opt2 <- optimise(ex2, lower=0, upper=(9/41), maximum=T) x <- seq(0,9/41,0.001) plot(x,ex2(x),type="l") abline(v=opt2$maximum, col="red") The two functions are not only of theoretical interest but have to be optimised as likelihood functions when dealing with SNP data. I observed this problem on Windows XP and Open Suse 10.0. Other platforms have to be tested. Some informations: Open Suse 10.0 platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 2 minor 4.0 year 2006 month 10 day03 svn rev39566 language R version.string R version 2.4.0 (2006-10-03) Windows XP: platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 4.0 year 2006 month 10 day03 svn rev39566 language R version.string R version 2.4.0 (2006-10-03) With best regards, Karsten Krug Student at University of Leipzig __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pb in regular expression with the character "-" (PR#9437)
Why do you think this is a bug in R? You have not told us what you
expected, but the character range |-| contains only | . Not agreeing with
your expectations (unstated or otherwise) is not a bug in R.
\- is the same as -, and - is special in character classes. (If it is
first or last it is treated literally.) And | is not a metacharacter
inside a character class. Also,
> grep("[d\\-c]", c("a-a","b"))
[1] 1 2
> grep("[d\\-c]", c("a-a","b"), perl=TRUE)
[1] 1
shows that escaping - works only in perl (which you will find from the
background references mentioned, e.g.
The interpretation of an ordinary character preceded by a backslash
('\') is undefined.
.)
This is all carefully documented in ?regexp, e.g.
Patterns are described here as they would be printed by 'cat': do
remember that backslashes need to be doubled in entering R
character strings from the keyboard.
This is not the first time you have wasted our resources with false
bug reports, so please show more respect for the R developers' time.
You were also explicitly asked not to report on obselete versions of R.
On Wed, 3 Jan 2007, [EMAIL PROTECTED] wrote:
> Full_Name: FAN
> Version: 2.4.0
> OS: Windows
> Submission from: (NULL) (159.50.101.9)
>
>
> These are expected:
>
>> grep("[\-|c]", c("a-a","b"))
> [1] 1
>
>> gsub("[\-|c]", "&", c("a-a","b"))
> [1] "a&a" "b"
>
> but these are strange:
>
>> grep("[d|\-|c]", c("a-a","b"))
> integer(0)
>
>> gsub("[d|\-|c]", "&", c("a-a","b"))
> [1] "a-a" "b"
>
> Thanks
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Which programming paradigm is the most used for make R packages?
Ross Boylan wrote: > On Wed, Jan 03, 2007 at 11:46:16AM -0600, Ricardo Rios wrote: >> Hi wizards, does somebody know Which programming paradigm is the most >> used for make R packages ? Thanks in advance. >> > You need to explain what you mean by the question, for example what > paradigms you have in mind. > Judging by the R code some people in our department write, the most used paradigm is 'bash something out that works and worry about paradigms later'-paradigm, used in conjunction with the 'write a very long .R file and source() it whenever you want to do something'-paradigm. This seems related to the 'write-first' paradigm, as opposed to the 'think-first' paradigm. Partly this is often due to the exploratory nature of working with R. You get a data set. You go 'okay, well, what's the mean of each column?', and do that. Then you wonder how A depends on B. Then you wonder how A depends on B given, ooh, C. Then you think, well, if I split the data into old and new measurements, rescaled by the median and offset by D, maybe something interesting appears. By now you've written 40 lines of R code and its starting to get messy... By the end of the thesis, instead of a nice neat redistributable R package that would look great on CRAN, there's a whole pile of R code scattered around in various directories. How many statistics departments still teach programming to their undergraduates? We dropped Fortran about 10 years ago, nowadays they maybe type a few things into a script for Matlab in their second year, learn R at the end of year 2, and do a project perhaps with R in their third year. But they are expected to develop their own paradigm for working in R. I don't think the fundamentals of programming, let along the idea of paradigms (functional/OO/whatever) is introduced. Scary. And wandering off-topic. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with function 'optimise' (PR#9438)
the issue here is a numerical one; for instance in your first example check: eps <- sqrt(.Machine$double.eps) opt1 <- optimise(ex1, lower = 0 - eps, upper = 0.5, maximum = TRUE) # or opt1 <- optimise(ex1, lower = 0 + eps, upper = 0.5, maximum = TRUE) which gives the correct results. I hope it helps. Best, Dimitris Dimitris Rizopoulos Ph.D. Student Biostatistical Centre School of Public Health Catholic University of Leuven Address: Kapucijnenvoer 35, Leuven, Belgium Tel: +32/(0)16/336899 Fax: +32/(0)16/337015 Web: http://med.kuleuven.be/biostat/ http://www.student.kuleuven.be/~m0390867/dimitris.htm - Original Message - From: <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Thursday, January 04, 2007 11:24 AM Subject: [Rd] problem with function 'optimise' (PR#9438) > Full_Name: Karsten Krug > Version: 2.4.0 > OS: Open Suse 10.0, Windows XP > Submission from: (NULL) (88.134.13.50) > > > > I found a problem in the 'optimise' function for one dimensional > optimisation. > > > Example 1: > Try to find a maximum of the function below with the use of > 'optimise' in the > interval [0,0.5]. The function follows a parabola and has two local > maxima > located at the margins of the interval [0,0.5]. Please try the > following code > which performs this optimisation, produces a plot of the function > within the > given interval and adds the computed maximum returned by > 'optimise()' > > ex1 <- function(x) log(4 * x^2 - 2 * x + 0.5) > opt1 <- optimise(ex1, lower=0, upper=0.5, maximum=T) > x <- seq(0,0.5,0.001) > plot(x, ex1(x), type="l") > abline(v=opt1$maximum, col="red") > > The returned value of the maximum is 0.309017 which is definitely > wrong. > > > Example 2: > The next function has also two equivalent maxima this time not > located at the > margins of the interval [0, 9/41]. Thus, the maxima are real > analytic extrema. > The function 'optimise()' again returns a wrong value. > > ex2 <- function(x) log((18/41) * x - 2 * x^2) + 16 * log(4 * x^2 - > (36/41) * x > + (9/41)) + 24 * log((23/82) + (18/41) * x - 2 * x^2) > opt2 <- optimise(ex2, lower=0, upper=(9/41), maximum=T) > x <- seq(0,9/41,0.001) > plot(x,ex2(x),type="l") > abline(v=opt2$maximum, col="red") > > > The two functions are not only of theoretical interest but have to > be optimised > as likelihood functions when dealing with SNP data. > > I observed this problem on Windows XP and Open Suse 10.0. Other > platforms have > to be tested. > > > Some informations: > > Open Suse 10.0 > > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 4.0 > year 2006 > month 10 > day03 > svn rev39566 > language R > version.string R version 2.4.0 (2006-10-03) > > Windows XP: > > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 2 > minor 4.0 > year 2006 > month 10 > day03 > svn rev39566 > language R > version.string R version 2.4.0 (2006-10-03) > > > > With best regards, > > Karsten Krug > Student at University of Leipzig > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Am I missing something about debugging?
It is possible to do some of these things with the 'debug' package-- the
article in R-news 2003 #3 shows a few of the tricks. Suppose 'b1' calls
'c1'. If 'c1' exists as "permanent" function defined outside 'b1' (which
I generally prefer, for clarity), then you can call 'mtrace( c1)' and
'c1' will be invoked whenever it's called-- you don't have to first
'mtrace' 'b1' and then manually call 'mtrace(c1)' while inside 'b1'.
Even if 'c1' is defined inside the body of 'b1', you can get something
similar by using conditional breakpoints, like this
> mtrace( b1)
> # whatever you type to get 'b1' going
D(17)> # now look at the code window for 'b1' and find the line just
after the definition of 'c1'
D(17)> # ... say that's on line 11
D(17)> bp( 11, {mtrace( c1);FALSE})
# which will auto-mtrace 'c1' without stopping; of course you could
hardwire this in the code of 'b1' too
the point is that you can stick all sorts of code inside a conditional
breakpoint to do other things-- if the expression returns FALSE then the
breakpoint won't be triggered, but the side-effects will still happen.
You can also use conditional breakpoints and 'skip' command to patch
code on-the-fly, but I generally find it's too much trouble.
Note also the trick of
D(17)> bp(1,F)
which is useful if 'b1' will be called again within the lifetime of the
current top-level expression and you actually don't want to stop.
The point about context is subtle because of R's scoping rules-- should
one look at lexical scope, or at things defined in calling functions?
The former happens by default in the 'debug' package (ie if you type the
name of something that can be "seen" from the current function, then the
debugger will find it, even if it's not defined in the current frame).
For the latter, though, if you are currently "inside" c1, then one way
to do it is to use 'sys.parent()' or 'sys.parent(2)' or whatever to
figure out the frame number of the "context" you want, then you could do
e.g.
D(18)> sp <- sys.frame( sys.parent( 2))
D(18)> evalq( ls(), sp)
etc which is not too bad. It's worth experimenting with sys.call etc
while inside my debugger, too-- I have gone to some lengths to try to
ensure that those functions work the way that might be expected (even
though they actually don't... long story).
If you are 'mtrace'ing one of the calling functions as well, then you
can also look at the frame numbers in the code windows to work out where
to 'evalq'.
The current 'debug' package doesn't include a "watch window" (even
though it's something I rely on heavily in Delphi, my main other
language) mainly because R can get stuck figuring out what to display in
that window. It's not that hard to do (I used ot have one in the Splus
version of my debugger) and I might add one in future if demand is high
enough. It would help if there was some way to "time-out" a
calculation-- e.g. a 'time.try' function a la
result <- time.try( { do.some.big.calculation}, 0.05)
which would return an object of class "too-slow" if the calculation
takes more than 0.05s.
I'm certainly willing to consider adding other features to the 'debug'
package if they are easy enough and demand is high enough! [And if I
have time, which I mostly don't :( ]
Hope this is of some use
Mark
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ross Boylan
> Sent: Wednesday, 3 January 2007 9:09 AM
> To: R Development List
> Subject: [Rd] Am I missing something about debugging?
>
> I would like to be able to trace execution into calls below
> the current function, or to follow execution as calls return.
> This is roughly the distinction between "step" and "next" in
> many debuggers.
>
> I would also like to be able to switch to a location further
> up the call stack than the location at which I enter the
> debugger, to see the context of the current operations.
>
> Are there ways to do these things with the R debugger? I've
> studied the man pages and FAQ's, and looked at the debug
> package, but I don't see a way except for manually calling
> debug on the function that is about to be called if I want to
> descend. That's quite awkward, particularly since it must be
> manually undone (the debug package may be better on that
> score). I'm also not entirely sure that such recursion
> (essentially, debugging within the debugger) is OK.
>
> I tried looking up the stack with things like sys.calls(),
> from within the browser, but they operated as if I were at
> the top level (e.g.,
> sys.function(-1) gets an error that it can't go there). I
> was doing this in ess, and there's some chance the "can't
> write .Last.value" error (wording approximate) cause by
> having an old version is screwing things up).
>
> Since R is interpreted I would expect d
Re: [Rd] problem with function 'optimise' (PR#9438)
That's only incidental to the story. The problem is (code in
src/appl/fmin.c) that at the first step symmetry (in both examples) gives
fu=fx, and the code has
if (fx <= fu) {
if (u < x)
a = u;
else
b = u;
}
if (fu <= fx) {
...
This appears to be an error in the C translation, for the original Fortran
does not do this.
On Thu, 4 Jan 2007, Dimitris Rizopoulos wrote:
> the issue here is a numerical one; for instance in your first example
> check:
>
> eps <- sqrt(.Machine$double.eps)
> opt1 <- optimise(ex1, lower = 0 - eps, upper = 0.5, maximum = TRUE)
>
> # or
>
> opt1 <- optimise(ex1, lower = 0 + eps, upper = 0.5, maximum = TRUE)
>
>
> which gives the correct results.
>
> I hope it helps.
>
> Best,
> Dimitris
>
>
> Dimitris Rizopoulos
> Ph.D. Student
> Biostatistical Centre
> School of Public Health
> Catholic University of Leuven
>
> Address: Kapucijnenvoer 35, Leuven, Belgium
> Tel: +32/(0)16/336899
> Fax: +32/(0)16/337015
> Web: http://med.kuleuven.be/biostat/
> http://www.student.kuleuven.be/~m0390867/dimitris.htm
>
>
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To:
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, January 04, 2007 11:24 AM
> Subject: [Rd] problem with function 'optimise' (PR#9438)
>
>
>> Full_Name: Karsten Krug
>> Version: 2.4.0
>> OS: Open Suse 10.0, Windows XP
>> Submission from: (NULL) (88.134.13.50)
>>
>>
>>
>> I found a problem in the 'optimise' function for one dimensional
>> optimisation.
>>
>>
>> Example 1:
>> Try to find a maximum of the function below with the use of
>> 'optimise' in the
>> interval [0,0.5]. The function follows a parabola and has two local
>> maxima
>> located at the margins of the interval [0,0.5]. Please try the
>> following code
>> which performs this optimisation, produces a plot of the function
>> within the
>> given interval and adds the computed maximum returned by
>> 'optimise()'
>>
>> ex1 <- function(x) log(4 * x^2 - 2 * x + 0.5)
>> opt1 <- optimise(ex1, lower=0, upper=0.5, maximum=T)
>> x <- seq(0,0.5,0.001)
>> plot(x, ex1(x), type="l")
>> abline(v=opt1$maximum, col="red")
>>
>> The returned value of the maximum is 0.309017 which is definitely
>> wrong.
>>
>>
>> Example 2:
>> The next function has also two equivalent maxima this time not
>> located at the
>> margins of the interval [0, 9/41]. Thus, the maxima are real
>> analytic extrema.
>> The function 'optimise()' again returns a wrong value.
>>
>> ex2 <- function(x) log((18/41) * x - 2 * x^2) + 16 * log(4 * x^2 -
>> (36/41) * x
>> + (9/41)) + 24 * log((23/82) + (18/41) * x - 2 * x^2)
>> opt2 <- optimise(ex2, lower=0, upper=(9/41), maximum=T)
>> x <- seq(0,9/41,0.001)
>> plot(x,ex2(x),type="l")
>> abline(v=opt2$maximum, col="red")
>>
>>
>> The two functions are not only of theoretical interest but have to
>> be optimised
>> as likelihood functions when dealing with SNP data.
>>
>> I observed this problem on Windows XP and Open Suse 10.0. Other
>> platforms have
>> to be tested.
>>
>>
>> Some informations:
>>
>> Open Suse 10.0
>>
>> platform i686-pc-linux-gnu
>> arch i686
>> os linux-gnu
>> system i686, linux-gnu
>> status
>> major 2
>> minor 4.0
>> year 2006
>> month 10
>> day03
>> svn rev39566
>> language R
>> version.string R version 2.4.0 (2006-10-03)
>>
>> Windows XP:
>>
>> platform i386-pc-mingw32
>> arch i386
>> os mingw32
>> system i386, mingw32
>> status
>> major 2
>> minor 4.0
>> year 2006
>> month 10
>> day03
>> svn rev39566
>> language R
>> version.string R version 2.4.0 (2006-10-03)
>>
>>
>>
>> With best regards,
>>
>> Karsten Krug
>> Student at University of Leipzig
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Which programming paradigm is the most used for make R packages?
A programming paradigm is a paradigmatic style of programming (compare
with a methodology, which is a paradigmatic style of doing software
engineering). I think , the programming paradigm most used for make R
packages is the functional programming , but I don't know this
statistic. I need this information in my thesis.
On 1/3/07, Ross Boylan <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 03, 2007 at 11:46:16AM -0600, Ricardo Rios wrote:
> > Hi wizards, does somebody know Which programming paradigm is the most
> > used for make R packages ? Thanks in advance.
> >
> You need to explain what you mean by the question, for example what
> paradigms you have in mind.
>
> R is a functional language; as I've discovered, this means some
> standard OO programming approaches don't carry over too naturally. In
> particular, functions don't really "belong" to classes. R purists
> would probably want that to say class-based 00 programming doesn't
> fit, since R is function-based OO.
>
> There is a package that permits a more traditional ("class-based") OO
> style; I think it's called R.oo.
>
> Ross Boylan
>
--
personal web site:
http://www.geocities.com/ricardo_rios_sv/index.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Which programming paradigm is the most used for make R packages?
Its object oriented in the sense of the Dylan language. It has
some functional elements but true functional languages have
better support for recursion, tail recursion and absence of side
effects whereas side effects are common in R.
On 1/4/07, Ricardo Rios <[EMAIL PROTECTED]> wrote:
> A programming paradigm is a paradigmatic style of programming (compare
> with a methodology, which is a paradigmatic style of doing software
> engineering). I think , the programming paradigm most used for make R
> packages is the functional programming , but I don't know this
> statistic. I need this information in my thesis.
>
> On 1/3/07, Ross Boylan <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 03, 2007 at 11:46:16AM -0600, Ricardo Rios wrote:
> > > Hi wizards, does somebody know Which programming paradigm is the most
> > > used for make R packages ? Thanks in advance.
> > >
> > You need to explain what you mean by the question, for example what
> > paradigms you have in mind.
> >
> > R is a functional language; as I've discovered, this means some
> > standard OO programming approaches don't carry over too naturally. In
> > particular, functions don't really "belong" to classes. R purists
> > would probably want that to say class-based 00 programming doesn't
> > fit, since R is function-based OO.
> >
> > There is a package that permits a more traditional ("class-based") OO
> > style; I think it's called R.oo.
> >
> > Ross Boylan
> >
>
>
> --
> personal web site:
> http://www.geocities.com/ricardo_rios_sv/index.html
>
> __
> 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
Re: [Rd] Which programming paradigm is the most used for make R packages?
On Thu, 4 Jan 2007, Ricardo Rios wrote: > engineering). I think , the programming paradigm most used for make R > packages is the functional programming , but I don't know this > statistic. I need this information in my thesis. Then you may be in trouble. R (and S before it) are not tidily classifiable. R supports functional programming, and object-oriented programming, but most large bodies of code would not satisfy a purist in either area. S3 classes are a very weak OOP mechanism, and R code usually has too much assignment to qualify as functional programming. It is also quite possible to write old-fashioned purely imperative code in R [a Real Programmer can write Fortran in any language], and some people do this. So, in order to find out what is most widely used you need some way to take a probability sample of R programs, and then some criteria for classifying them. All you can get from this list is information on what R supports, and a convenience sample of opinions on how programming should be done, which won't be sufficient if this really is an important issue in your thesis. If you were willing to take published packages as representative then CRAN and Bioconductor are available for sampling -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to execute R scripts simultaneously from multiple threads
On Thursday 04 January 2007 4:54 am, Erik van Zijst wrote: > Vladimir Dergachev wrote: > > On Wednesday 03 January 2007 3:47 am, Erik van Zijst wrote: > >>Appearantly the R C-API does not provide a mechanism for parallel > >>execution.. > >> > >>It is preferred that the solution is not based on multi-processing (like > >>C/S), because that would introduce IPC overhead. > > > > One thing to keep in mind is that IPC is very fast in Linux. So unless > > you are making lots of calls to really tiny functions this should not be > > an issue. > > Using pipes or shared memory to pass things around to other processes on > the same box is very fast indeed, but if we base our design around > something like RServe which uses TCP it could be significantly slower. > Our R-based system will be running scripts in response to high-volume > real-time stock exchange data, so we expect lots of calls to many tiny > functions indeed. Very interesting :) If you are running RServe on the other box you will need to send data over ethernet anyway (and will probably use TCP). If it is on the same box and you use "localhost" the packets will go over loopback - which would be significantly faster. At some point (years ago) there was even an argument on some mailiing list (xfree86-devel ?) about whether Xserver should support shared memory as unix socket was "fast enough" - with the other side arguing that when you pass megabyte images around (as in DVD playback) there is non-negligible overhead. best Vladimir Dergachev __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Am I missing something about debugging?
On Thu, 2007-01-04 at 17:06 +1100, [EMAIL PROTECTED] wrote:
> It is possible to do some of these things with the 'debug' package-- the
> article in R-news 2003 #3 shows a few of the tricks. Suppose 'b1' calls
> 'c1'. If 'c1' exists as "permanent" function defined outside 'b1' (which
> I generally prefer, for clarity), then you can call 'mtrace( c1)' and
> 'c1' will be invoked whenever it's called-- you don't have to first
> 'mtrace' 'b1' and then manually call 'mtrace(c1)' while inside 'b1'.
Is the effect of mtrace permanent? For example, if
b1 <- function() {
# stuff
c1()
# stuff
c1()
}
And you mtrace(c1), will both calls to c1, as well as any outside of b1,
bring up the debugger?
I ask because sometimes the normal "step" semantics in debugging is more
useful, i.e., debug into the next call to c1 only. As I understand it,
the debug package can put a one-time only breakpoint (with go), but only
in the body of the currently active function.
Am I correct that both the debug package and the regular debug require
explicitly removing debugging from a function to turn off debugging?
>
> Even if 'c1' is defined inside the body of 'b1', you can get something
> similar by using conditional breakpoints, like this
>
> > mtrace( b1)
> > # whatever you type to get 'b1' going
> D(17)> # now look at the code window for 'b1' and find the line just
> after the definition of 'c1'
> D(17)> # ... say that's on line 11
> D(17)> bp( 11, {mtrace( c1);FALSE})
> # which will auto-mtrace 'c1' without stopping; of course you could
> hardwire this in the code of 'b1' too
>
If you invoke b1 multiple times, will the previous procedure result in
wrapping c1 multiple times, e.g., first time through c1 is replaced by
mtrace(c1); second time rewrites the already rewritten fucntion? Is
that a problem?
> the point is that you can stick all sorts of code inside a conditional
> breakpoint to do other things-- if the expression returns FALSE then the
> breakpoint won't be triggered, but the side-effects will still happen.
> You can also use conditional breakpoints and 'skip' command to patch
> code on-the-fly, but I generally find it's too much trouble.
>
>
> Note also the trick of
> D(17)> bp(1,F)
>
> which is useful if 'b1' will be called again within the lifetime of the
> current top-level expression and you actually don't want to stop.
Is bp(1, FALSE) equivalent to mtrace(f, false), if one is currently
debugging in f?
>
> The point about context is subtle because of R's scoping rules-- should
> one look at lexical scope, or at things defined in calling functions?
> The former happens by default in the 'debug' package (ie if you type the
> name of something that can be "seen" from the current function, then the
> debugger will find it, even if it's not defined in the current frame).
> For the latter, though, if you are currently "inside" c1, then one way
> to do it is to use 'sys.parent()' or 'sys.parent(2)' or whatever to
> figure out the frame number of the "context" you want, then you could do
> e.g.
> D(18)> sp <- sys.frame( sys.parent( 2))
> D(18)> evalq( ls(), sp)
>
> etc which is not too bad. It's worth experimenting with sys.call etc
> while inside my debugger, too-- I have gone to some lengths to try to
> ensure that those functions work the way that might be expected (even
> though they actually don't... long story).
>
sys.parent and friends didn't seem to work for me in vanilla R
debugging, so this sounds really useful to me.
> If you are 'mtrace'ing one of the calling functions as well, then you
> can also look at the frame numbers in the code windows to work out where
> to 'evalq'.
I thought the frame numbers shown in the debugger are numbered
successively for the call stack, and that these are not necessarily the
same as the frame numbers in R. My understanding is that the latter are
not guaranteed to be consecutive (relative to the call stack). From the
description of sys.parent:
The parent frame of a function evaluation is the environment in
which the function was called. It is not necessarily numbered one
less than the frame number of the current evaluation,
>
> The current 'debug' package doesn't include a "watch window" (even
> though it's something I rely on heavily in Delphi, my main other
> language) mainly because R can get stuck figuring out what to display in
> that window.
Just out of curiosity, how does that problem arise? I'd expect showing
the variables in a frame to be straightforward.
> It's not that hard to do (I used ot have one in the Splus
> version of my debugger) and I might add one in future if demand is high
> enough. It would help if there was some way to "time-out" a
> calculation-- e.g. a 'time.try' function a la
>
> result <- time.try( { do.some.big.calculation}, 0.05)
>
> which would return an object of class "too-slow" if the calculation
> takes more than 0.05s.
>
> I'm certainly willing to consider adding other features to the 'debug'
> pa
Re: [Rd] How to execute R scripts simultaneously from multiple threads
Vladimir Dergachev wrote: > On Thursday 04 January 2007 4:54 am, Erik van Zijst wrote: >> Vladimir Dergachev wrote: >>> On Wednesday 03 January 2007 3:47 am, Erik van Zijst wrote: Appearantly the R C-API does not provide a mechanism for parallel execution.. It is preferred that the solution is not based on multi-processing (like C/S), because that would introduce IPC overhead. >>> One thing to keep in mind is that IPC is very fast in Linux. So unless >>> you are making lots of calls to really tiny functions this should not be >>> an issue. >> Using pipes or shared memory to pass things around to other processes on >> the same box is very fast indeed, but if we base our design around >> something like RServe which uses TCP it could be significantly slower. >> Our R-based system will be running scripts in response to high-volume >> real-time stock exchange data, so we expect lots of calls to many tiny >> functions indeed. > > Very interesting :) > > If you are running RServe on the other box you will need to send data over > ethernet anyway (and will probably use TCP). If it is on the same box and you > use "localhost" the packets will go over loopback - which would be > significantly faster. I haven't looked at RServe in awhile, but I think that it fires up an R interpreter in response to a client request and then sticks around for the same client to serve it additional requests. The question is how does it manage all the R interpreters with varying demand. This issue is solved when you embed R into Apache (using the prefork MPM), as the pool of apache child processes (each with their own R interpreter) expands and contracts on demand. Using this with the loopback device would be a nice solution: http://biostat.mc.vanderbilt.edu/RApacheProject Jeff -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to execute R scripts simultaneously from multiple threads
Vladimir, Jeff, et al., This is more pre-publicity than immediately available solution, but we've been working on the 'RWebServices' project. The R evaluator and user functions get wrapped in Java, and the Java exposed as web service. We use ActiveMQ to broker transactions between the front-end web service and persistent back-end R workers. The workers rely on SJava to wrap and evaluate R. Some of the features and opportunities of this system are: strongly typed functions in R (using the TypeInfo package); native R-Java translation (using SJava and our own converters); programmatic interface (i.e., as web services; this benefits from use of S4 as a formal class system); scalable computation (through addition of more / specialized workers in ActiveMQ); and access to Java-based tools available for web service deployment. Creating web services can be nearly automatic, once the R functions are appropriately typed. Mostly our focus has been on big-data computation, which might be orthogonal to the needs of the original post. We will provide more information at the Directions in Statistical Computing conference in mid-February, so please drop me a line if you'd like to be kept up-to-date. Martin -- Martin T. Morgan Bioconductor / Computational Biology http://bioconductor.org Jeffrey Horner <[EMAIL PROTECTED]> writes: > Vladimir Dergachev wrote: >> On Thursday 04 January 2007 4:54 am, Erik van Zijst wrote: >>> Vladimir Dergachev wrote: On Wednesday 03 January 2007 3:47 am, Erik van Zijst wrote: > Appearantly the R C-API does not provide a mechanism for parallel > execution.. > > It is preferred that the solution is not based on multi-processing (like > C/S), because that would introduce IPC overhead. One thing to keep in mind is that IPC is very fast in Linux. So unless you are making lots of calls to really tiny functions this should not be an issue. >>> Using pipes or shared memory to pass things around to other processes on >>> the same box is very fast indeed, but if we base our design around >>> something like RServe which uses TCP it could be significantly slower. >>> Our R-based system will be running scripts in response to high-volume >>> real-time stock exchange data, so we expect lots of calls to many tiny >>> functions indeed. >> >> Very interesting :) >> >> If you are running RServe on the other box you will need to send data over >> ethernet anyway (and will probably use TCP). If it is on the same box and >> you >> use "localhost" the packets will go over loopback - which would be >> significantly faster. > > I haven't looked at RServe in awhile, but I think that it fires up an R > interpreter in response to a client request and then sticks around for > the same client to serve it additional requests. The question is how > does it manage all the R interpreters with varying demand. > > This issue is solved when you embed R into Apache (using the prefork > MPM), as the pool of apache child processes (each with their own R > interpreter) expands and contracts on demand. Using this with the > loopback device would be a nice solution: > > http://biostat.mc.vanderbilt.edu/RApacheProject > > Jeff > -- > http://biostat.mc.vanderbilt.edu/JeffreyHorner > > __ > 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
Re: [Rd] pb in regular expression with the character "-" (PR#9437)
Let me detail a bit my bug report:
the two commands ("expected" vs "strange") should return the
same result, the objective of the commands is to test the presence
of several characters, '-'included.
The order in which we specify the different characters must not be
an issue, i.e., to test the presence of several characters, including
say char_1, the regular expressions [char_1|char_2|char_3] and
[char_2|char_1|char_3] should play the same role. Other softwares
work just like this.
What's reported is that R actually returns different result for the
character "-" (\- in a RE) regarding it's position in the regular
expression, and the "perl" option would not be relevant.
Prof Brian Ripley wrote:
> Why do you think this is a bug in R? You have not told us what you
> expected, but the character range |-| contains only | . Not agreeing
> with your expectations (unstated or otherwise) is not a bug in R.
>
> \- is the same as -, and - is special in character classes. (If it is
> first or last it is treated literally.) And | is not a metacharacter
> inside a character class. Also,
>
>> grep("[d\\-c]", c("a-a","b"))
>
> [1] 1 2
>
>> grep("[d\\-c]", c("a-a","b"), perl=TRUE)
>
> [1] 1
>
> shows that escaping - works only in perl (which you will find from the
> background references mentioned, e.g.
>
> The interpretation of an ordinary character preceded by a backslash
> ('\') is undefined.
>
> .)
>
> This is all carefully documented in ?regexp, e.g.
>
> Patterns are described here as they would be printed by 'cat': do
> remember that backslashes need to be doubled in entering R
> character strings from the keyboard.
>
>
> This is not the first time you have wasted our resources with false bug
> reports, so please show more respect for the R developers' time.
> You were also explicitly asked not to report on obselete versions of R.
>
> On Wed, 3 Jan 2007, [EMAIL PROTECTED] wrote:
>
>> Full_Name: FAN
>> Version: 2.4.0
>> OS: Windows
>> Submission from: (NULL) (159.50.101.9)
>>
>>
>> These are expected:
>>
>>> grep("[\-|c]", c("a-a","b"))
>>
>> [1] 1
>>
>>> gsub("[\-|c]", "&", c("a-a","b"))
>>
>> [1] "a&a" "b"
>>
>> but these are strange:
>>
>>> grep("[d|\-|c]", c("a-a","b"))
>>
>> integer(0)
>>
>>> gsub("[d|\-|c]", "&", c("a-a","b"))
>>
>> [1] "a-a" "b"
>>
>> Thanks
>>
>> __
>> 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] Parameter changes and segfault when calling C code through .Call
I am experiencing some odd behavior with the .Call interface, and I am hoping
someone out there can help me with it. Below is a simple example (in that
there are R packages that do exactly what I want), but this code illustrates
the problem. Thanks in advance for any help you can provide.
Suppose I want to compute the log density of a multivariate normal distribution
using C code and the gsl library. My R program is:
dyn.load("mvnorm-logpdf.so")
x<-c(0,0,0,0,0,0)
mu<-c(0,0,0,0,0,0)
sig<-diag(6)
print(sig)
w<-.Call("R_mvnorm_logpdf",as.double(x),as.double(mu),sig,
as.integer(6))
print(sig) # sig has changed after .Call
This code takes the SEXP's that were passed from R and converts them to gsl
objects, and then calls the logpdf function:
# include
# include
# include
# include
# include
# include
# include
# include
SEXP R_mvnorm_logpdf (SEXP xx, SEXP mux, SEXP sigmax, SEXP kx) {
int k = INTEGER(kx)[0];
double * xAr = REAL(xx);
double * muAr = REAL(mux);
double * sigmaAr = REAL(sigmax);
SEXP res;
gsl_vector_view xView = gsl_vector_view_array(xAr,k);
gsl_vector_view muView = gsl_vector_view_array(muAr,k);
gsl_matrix_view sigmaView = gsl_matrix_view_array(sigmaAr,k,k);
gsl_vector * x = &xView.vector;
gsl_vector * mu = &muView.vector;
gsl_matrix * sigma = &sigmaView.matrix;
1: double logans = gsl_MB_mvnorm_logpdf(x, mu, sigma, k); //
<-call logpdf here
PROTECT(res=allocVector(REALSXP,1));
REAL(res)[0] = logans;
UNPROTECT(1);
return(res);
}
The logpdf function is here
double gsl_MB_mvnorm_logpdf(gsl_vector * beta, gsl_vector * betaMean,
gsl_matrix * sigma, int k) {
// computes density of multivariate normal vector at vector
beta, with mean betaMean and cov sigma
double logdetSigma = 0;
double res;
double * kern;
int i, err;
// pointer to Cholesky decomp of sigma
gsl_matrix * sigmaChol = gsl_matrix_alloc(k, k); // define
matrix that will store Chol decomp
gsl_matrix_memcpy(sigmaChol, sigma);
gsl_linalg_cholesky_decomp(sigmaChol);
// compute logdet of sigma by 2*sum of log of diagomal elements
of chol decomp
for (i=0; i source("pdfTest.R")
[,1] [,2] [,3] [,4] [,5] [,6]
[1,]100000
[2,]010000
[3,]001000
[4,]000100
[5,]000010
[6,]000001
[,1] [,2] [,3] [,4] [,5] [,6]
[1,]000000
[2,]010000
[3,]001000
[4,]000100
[5,]000010
[6,]000001
Through some debugging, I do know that it occurs somewhere in the logpdf
function (line 1: in the first func). I should also note that this function
does compute the density correctly.
Here's some other, potentially relevant information. Note the print statement
in line 2 of the logpdf function. If that print were "uncommented" and placed
somewhere *earlier* in the function, the elements of the sigma matrix are as
they should be, and the program runs with no problem (except for the change in
sig as described above). However, if the print statement is at line 2: or
later, the correct matrix elements are printed, but then the .Call crashes with
the following message:
*** caught segfault ***
address 0x6, cause 'memory not mapped'
(If I change the size of the matrix to diag(k), the 0x6 becomes 0xk). So, for
some reason, k is interpreted as a memory address. I double-checked for places
where I may have confused pointers and values, but I can't see where that would
have happened. Also, after searching through the R-devel archives, I noticed
that others have had other odd 'memory not mapped' errors in totally different
scenarios.
So I am flummoxed, and don't really know where to go from here.
Best wishes,
MB
--
Michael Braun
Assistant Professor of Marketing
MIT Sloan School of Management
38 Memorial Drive, E56-329
Cambridge, MA 02139
[EMAIL PROTECTED]
(617) 253-3436
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pb in regular expression with the character "-" (PR#9437)
> "FanX" == Xiao Gang Fan <[EMAIL PROTECTED]>
> on Thu, 04 Jan 2007 21:52:07 +0100 writes:
FanX> Let me detail a bit my bug report: the two commands
FanX> ("expected" vs "strange") should return the same
FanX> result, the objective of the commands is to test the
FanX> presence of several characters, '-'included.
FanX> The order in which we specify the different characters
FanX> must not be an issue, i.e., to test the presence of
FanX> several characters, including say char_1, the regular
FanX> expressions [char_1|char_2|char_3] and
FanX> [char_2|char_1|char_3] should play the same
FanX> role. Other softwares work just like this.
FanX> What's reported is that R actually returns different
FanX> result for the character "-" (\- in a RE) regarding
FanX> it's position in the regular expression, and the
FanX> "perl" option would not be relevant.
Fan, it seems haven't understood what Brian Ripley explained to
you: Let me try to spell it out for you:
"\-" is *NOT* what you seem still to be thinking it is:
> "\-"
[1] "-"
> identical("\-", "-")
[1] TRUE
>
This is all in the R-FAQ entry
>>> 7.37 Why does backslash behave strangely inside strings?
and in several other places, and yes,
please do read the R FAQ and maybe more documentation
about R and "bug reporting" before your next bug report.
Consider my guesstimate:
For 99% of all R users, the amount of time they need working
pretty intensely with R before they find a bug in it,
is nowadays more than three years, and maybe even much more
-- such as their lifetime :-)
Martin Maechler, ETH Zurich
FanX> Prof Brian Ripley wrote:
>> Why do you think this is a bug in R? You have not told
>> us what you expected, but the character range |-|
>> contains only | . Not agreeing with your expectations
>> (unstated or otherwise) is not a bug in R.
>>
>> \- is the same as -, and - is special in character
>> classes. (If it is first or last it is treated
>> literally.) And | is not a metacharacter inside a
>> character class. Also,
>>
>>> grep("[d\\-c]", c("a-a","b"))
>> [1] 1 2
>>
>>> grep("[d\\-c]", c("a-a","b"), perl=TRUE)
>> [1] 1
>>
>> shows that escaping - works only in perl (which you will
>> find from the background references mentioned, e.g.
>>
>> The interpretation of an ordinary character preceded by a
>> backslash ('\') is undefined.
>>
>> .)
>>
>> This is all carefully documented in ?regexp, e.g.
>>
>> Patterns are described here as they would be printed by
>> 'cat': do remember that backslashes need to be doubled in
>> entering R character strings from the keyboard.
>>
>>
>> This is not the first time you have wasted our resources
>> with false bug reports, so please show more respect for
>> the R developers' time. You were also explicitly asked
>> not to report on obselete versions of R.
>>
>> On Wed, 3 Jan 2007, [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: FAN Version: 2.4.0 OS: Windows Submission
>>> from: (NULL) (159.50.101.9)
>>>
>>>
>>> These are expected:
>>>
grep("[\-|c]", c("a-a","b"))
>>> [1] 1
>>>
gsub("[\-|c]", "&", c("a-a","b"))
>>> [1] "a&a" "b"
>>>
>>> but these are strange:
>>>
grep("[d|\-|c]", c("a-a","b"))
>>> integer(0)
>>>
gsub("[d|\-|c]", "&", c("a-a","b"))
>>> [1] "a-a" "b"
>>>
>>> Thanks
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
FanX> __
FanX> R-devel@r-project.org mailing list
FanX> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Parameter changes and segfault when calling C code through .Call
"Michael Braun" <[EMAIL PROTECTED]> writes:
> Suppose I want to compute the log density of a multivariate normal
> distribution using C code and the gsl library. My R program is:
>
> dyn.load("mvnorm-logpdf.so")
>
> x<-c(0,0,0,0,0,0)
> mu<-c(0,0,0,0,0,0)
> sig<-diag(6)
> print(sig)
> w<-.Call("R_mvnorm_logpdf",as.double(x),as.double(mu),sig,
> as.integer(6))
> print(sig) # sig has changed after .Call
Arguments sent via the .Call interface are not copied. In almost all
cases, they should be treated as read-only data.
You can copy a given SEXP using duplicate. Something along these
lines (untested):
SEXP sigma_copy;
PROTECT(sigma_copy = duplicate(sigmax));
But it seems pretty clear that sigmaView is holding a pointer to
sigmaAr which in turn points to the data in sigmax.
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pb in regular expression with the character "-" (PR#9437)
Both Solaris 8 grep and GNU grep 2.5.1 give
gannet% cat > foo.txt
a-a
b
gannet% egrep '[d|-|c]' foo.txt
gannet% egrep '[-|c]' foo.txt
a-a
agreeing exactly with R (and the POSIX standard) and contradicting 'Fan'.
On Thu, 4 Jan 2007, Fan wrote:
> Let me detail a bit my bug report:
>
> the two commands ("expected" vs "strange") should return the
> same result, the objective of the commands is to test the presence
> of several characters, '-'included.
>
> The order in which we specify the different characters must not be
> an issue, i.e., to test the presence of several characters, including
> say char_1, the regular expressions [char_1|char_2|char_3] and
> [char_2|char_1|char_3] should play the same role. Other softwares
> work just like this.
>
> What's reported is that R actually returns different result for the
> character "-" (\- in a RE) regarding it's position in the regular
> expression, and the "perl" option would not be relevant.
As described in the relevant international standard and R's own
documentation.
> Prof Brian Ripley wrote:
>> Why do you think this is a bug in R? You have not told us what you
>> expected, but the character range |-| contains only | . Not agreeing with
>> your expectations (unstated or otherwise) is not a bug in R.
>>
>> \- is the same as -, and - is special in character classes. (If it is
>> first or last it is treated literally.) And | is not a metacharacter
>> inside a character class. Also,
>>
>>> grep("[d\\-c]", c("a-a","b"))
>>
>> [1] 1 2
>>
>>> grep("[d\\-c]", c("a-a","b"), perl=TRUE)
>>
>> [1] 1
>>
>> shows that escaping - works only in perl (which you will find from the
>> background references mentioned, e.g.
>>
>> The interpretation of an ordinary character preceded by a backslash
>> ('\') is undefined.
>>
>> .)
>>
>> This is all carefully documented in ?regexp, e.g.
>>
>> Patterns are described here as they would be printed by 'cat': do
>> remember that backslashes need to be doubled in entering R
>> character strings from the keyboard.
>>
>>
>> This is not the first time you have wasted our resources with false bug
>> reports, so please show more respect for the R developers' time.
>> You were also explicitly asked not to report on obselete versions of R.
>>
>> On Wed, 3 Jan 2007, [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: FAN
>>> Version: 2.4.0
>>> OS: Windows
>>> Submission from: (NULL) (159.50.101.9)
>>>
>>>
>>> These are expected:
>>>
grep("[\-|c]", c("a-a","b"))
>>>
>>> [1] 1
>>>
gsub("[\-|c]", "&", c("a-a","b"))
>>>
>>> [1] "a&a" "b"
>>>
>>> but these are strange:
>>>
grep("[d|\-|c]", c("a-a","b"))
>>>
>>> integer(0)
>>>
gsub("[d|\-|c]", "&", c("a-a","b"))
>>>
>>> [1] "a-a" "b"
>>>
>>> Thanks
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Am I missing something about debugging?
Hi Ross
> Suppose 'b1'
> > calls 'c1'. If 'c1' exists as "permanent" function defined outside
> > 'b1' (which I generally prefer, for clarity), then you can call
> > 'mtrace( c1)' and 'c1' will be invoked whenever it's called-- you
> > don't have to first 'mtrace' 'b1' and then manually call
> 'mtrace(c1)' while inside 'b1'.
> Is the effect of mtrace permanent? For example, if
> b1 <- function() {
> # stuff
> c1()
> # stuff
> c1()
> }
> And you mtrace(c1), will both calls to c1, as well as any
> outside of b1, bring up the debugger?
Yes. But there are a couple of tricks you could use to avoid it. First
(less neat), you could 'mtrace( b1)' and then set two fake conditional
breakpoints inside 'b1': one of '{mtrace( c1);F}' before the first call
to 'c1', and one of '{mtrace(c1,F);F}' just after. Second (neater), you
could avoid 'mtrace'ing 'b1' altogether, and instead replace the default
breakpoint at line 1 in 'c1' [SEE ** BELOW] with a conditional
breakpoint. The conditional breakpoint would have to be a bit clever--
it might have to inspect the value of a variable in 'b1' or something
like that. For example, suppose you wrote 'b1' like this:
c1.call.count <- 1
c1( ...)
repeat{
c1.call.count <- c1.call.count+1
blah.blah.blah()
c1(...)
}
Then you could 'mtrace( c1)' and do
'bp( 1, { get( 'c1.call.count', envir=sys.frame( mvb.sys.parent()))==1,
fname='c1')'
before running 'b1'. Lo & behold, it will only stop in 'c1' on the first
call, not on subsequent ones. [I guess I could add a pass count feature
to the debugger, to make this easier.]
Note that you can call 'bp' without actually being in debug mode, by
using the 'fname' parameter-- the problem is that it is not usually
obvious what line number to set the breakpoint at (though you can find
out by inspecting 'tracees$f'). You can alternatively just 'mtrace( c1)'
and then reset the breakpoint manually the first time it comes up.
One thing I noticed while trying the stuff above, is that you do need to
use 'mvb.sys.parent' instead of 'sys.parent' in the above.
'mvb.sys.parent' and friends are the "do what I mean, not what I say"
equivalents of 'sys.parent' etc for use inside the debugger. The 'debug'
package goes to some trouble to replace calls to 'sys.parent' with calls
to the 'mvb...' equivalents, both in user input and in the debuggee
function, but evidently doesn't do so inside breakpoint expressions.
Consider it a feature...
The frame stack is a thing of great weirdness, by the way; the same
frame can appear several times in the stack, especially when debugging.
I would not recommend trying to really understand it unless you really
have to; the 'debug' package makes efforts to avoid you having to!
>
> I ask because sometimes the normal "step" semantics in
> debugging is more useful, i.e., debug into the next call to
> c1 only. As I understand it, the debug package can put a
> one-time only breakpoint (with go), but only in the body of
> the currently active function.
>
> Am I correct that both the debug package and the regular
> debug require explicitly removing debugging from a function
> to turn off debugging?
True, for the debug package. Not sure about vanilla R debugging
(dissatisfaction with which drove me to write the 'debug' package-- so I
don't use the vanilla stuff these days!).
>
> >
> > Even if 'c1' is defined inside the body of 'b1', you can
> get something
> > similar by using conditional breakpoints, like this
> >
> > > mtrace( b1)
> > > # whatever you type to get 'b1' going
> > D(17)> # now look at the code window for 'b1' and find the
> line just
> > after the definition of 'c1'
> > D(17)> # ... say that's on line 11
> > D(17)> bp( 11, {mtrace( c1);FALSE})
> > # which will auto-mtrace 'c1' without stopping; of course you could
> > hardwire this in the code of 'b1' too
> >
> If you invoke b1 multiple times, will the previous procedure
> result in wrapping c1 multiple times, e.g., first time
> through c1 is replaced by mtrace(c1); second time rewrites
> the already rewritten fucntion? Is that a problem?
It won't cause a problem; the 'debug' package notices when a function
has already been 'mtrace'd (by inspecting the actual function body) and
doesn't add another "layer".
>
> > the point is that you can stick all sorts of code inside a
> conditional
> > breakpoint to do other things-- if the expression returns
> FALSE then
> > the breakpoint won't be triggered, but the side-effects
> will still happen.
> > You can also use conditional breakpoints and 'skip' command
> to patch
> > code on-the-fly, but I generally find it's too much trouble.
> >
> >
> > Note also the trick of
> > D(17)> bp(1,F)
> >
> > which is useful if 'b1' will be called again within the lifetime of
> > the current top-level expression and you actually don't
> want to stop.
> Is bp(1, FALSE) equivalent to mtrace(f, false), if one is
> currently debugging in f?
[**]
Not exactly-- but read on. If 'f' is
