Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0

[baptiste auguie]

Hi,

I was recently given some interesting tips on a similar issue, see
R-help "puzzle with integrate over infinite range"


Maybe "fails" can be a bit misleading here (fails to produce the
actual result vs. returning an error message). As a result of this
previous discussion, I don't think it would be possible to return an
error: as far as the algorithm knows, the value it calculated is 0
because the integrand was 0 everywhere. To know better, the program
would need to sample the integrand at more points (which can be
achieved by changing the interval, or better, by setting the tolerance
to a lower value).

baptiste



On 7 December 2010 00:32, Spencer Graves
 wrote:
> Hello:
>
>
>      The example "integrate(dnorm,0,2)" says it "fails on many systems".
>  I just got 0 from it, when I should have gotten either an error or
> something close to 0.5.  I got this with R 2.12.0 under both Windows
> Vista_x64 and Linux (Fedora 13);  see the results from Windows below.  I
> thought you might want to know.
>
>
>      Thanks for all your work in creating and maintaining R.
>
>
>      Best Wishes,
>      Spencer Graves
> ###
>
> integrate(dnorm,0,2) ## fails on many systems
> 0 with absolute error < 0
>> sessionInfo()
> R version 2.12.0 (2010-10-15)
> Platform: i386-pc-mingw32/i386 (32-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> __
> 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] 0.5 != integrate(dnorm,0,20000) = 0

[Martin Maechler]

> Prof Brian Ripley 
> on Tue, 7 Dec 2010 07:41:16 + (GMT) writes:

> On Mon, 6 Dec 2010, Spencer Graves wrote:
>> Hello:
>> 
>> 
>> The example "integrate(dnorm,0,2)" says it "fails on many systems". 
>> I just got 0 from it, when I should have gotten either an error or 
something 
>> close to 0.5.  I got this with R 2.12.0 under both Windows Vista_x64 and 
>> Linux (Fedora 13);  see the results from Windows below.  I thought you 
might 
>> want to know.

> Well, isn't that exactly what the help page says happens?  That 
> example is part of a section entitled

> ## integrate can fail if misused

> and is part of the illustration of

> If the function is
> approximately constant (in particular, zero) over nearly all its
> range it is possible that the result and error estimate may be
> seriously wrong.

yes, of course, 
and the issue has been known for ``ages''  ..
..
..
but it seems that too many useRs are not reading the help
page carefully, but only browse it quickly.
I think we (R developers) have to live with this fact
and should consider adapting to it a bit more, particularly in
this case (see below)

>> 
>> Thanks for all your work in creating and maintaining R.
>> 
>> 
>> Best Wishes,
>> Spencer Graves
>> ###

>> 
>> integrate(dnorm,0,2) ## fails on many systems

>> 0 with absolute error < 0

and this is particularly unsatisfactory for another reason:

"absolute error < 0"   
is *always* incorrect, so I think we should change *some*thing.

We could just use "<=" (and probably should in any case, or  
"< ~= x" which would convey ``is less than about x'' which I
think is all we can say),
but could consider giving a different message when the integral
evaluates to 0 or, rather actually,
only when the error bound ('abs.error') is 0 *and* 'subdivisions == 1'
as the latter indicates that the algorithm treated the integrand
f(.) as if f() was a linear function.

But in my quick experiments, even for linear (incl. constant)
functions, the 'abs.error' returned is never 0.

If we want to be cautious,
such a warning could be made explicitly suppressable by an argument
  .warn.if.doubtful = TRUE

An additional possibility I'd like to try, is a new argument
   'min.subdivisions = 3' which specifies the *minimal* number
of subdivisions to be used in addition to the already present
   'subdivisions = 100' (= the maximum number of subintervals.)

Martin Maechler,
ETH Zurich

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

Re: [Rd] Wait for user input with readline()

[Alexandre]

Hi,

I have a similar problem as the one of Nate. The point is that I want to
design an interactive script that need the value of two variables (x and y).

So my script as designed for the moment is :

x <- as.numeric (readline(prompt="What is the value of x? "))
y <- as.numeric (readline(prompt="What is the value of y? "))

x
y 

But the problem is that if I run this script, values returned for x and y
will be "NA" like you can see below :

> x <- as.numeric (readline(prompt="What is the value of x? "))
What is the value of x? 
> y <- as.numeric (readline(prompt="What is the value of y? "))
What is the value of y? 
> x
[1] NA
> y
[1] NA

I have no problem to understand why, because R software does not let the
time to enter the value for each variable. So Nate and I want to know if
there is a way, to "force" R to wait the entrance of the value of each
variable like written below:

First step of the script : 

> x <- as.numeric (readline(prompt="What is the value of x? "))
What is the value of x? 5

Second step of the script :

> y <- as.numeric (readline(prompt="What is the value of y? "))
What is the value of y? 9

Finally :

> x
[1] 5
> y
[1] 9

I hope that my english is not to bad and that you've understand what I mean.

Regards

Alexandre

-- 
View this message in context: 
http://r.789695.n4.nabble.com/Wait-for-user-input-with-readline-tp3054517p3074781.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] Terminology clarification (Re: GPL and R Community Policies (Rcpp)

[Michael Sumner]

Well, I'm very sorry for the outburst, it was completely inappropriate.

I don't actually mind the inconvenience - it's rather instructive as
to how badly things can go. I was lasshing out as it's really just
ironic that you want to stamp out references to yourself in a package
(how many on this list really knew the details before, or cared?) but
have now immortalized your contribution in the loudest way here on a
list where it's really not relevant.

Cheers, Mike.


On Sun, Dec 5, 2010 at 2:17 AM, Dominick Samperi  wrote:
>
>
> On Sat, Dec 4, 2010 at 8:11 AM, Michael Sumner  wrote:
>>
>> Christ, can we remove all references from the mailing lists while we're at
>> it?
>
> Look, I want to release software to CRAN, and I would like to
> do it without having to explain those remarks in Rcpp. I understand
> your frustration, but the authors of Rcpp have made it clear that
> private emails will be ignored. I think I have the right to decline
> the kind of "acknowledgement" that appears in Rcpp, and there
> is no rule that says it must be retained.
>
> This is a very simple resolution that would end this thread (to
> the delight of many readers I am sure).
>
> Sorry for the inconvenience,
> Dominick
>
>>
>>
>>
>> On Sat, Dec 4, 2010 at 7:49 AM, Dominick Samperi 
>> wrote:
>> > Dirk,
>> >
>> > Please let me know whether or not you will comply with my request to
>> > remove
>> > references to my name in Rcpp (except copyright notices).
>>
>> >
>> > Thanks,
>> > Dominick
>> >
>> > On Thu, Dec 2, 2010 at 6:28 PM, Dominick Samperi
>> > wrote:
>> >
>> >>
>> >>
>> >> On Thu, Dec 2, 2010 at 5:58 PM, Dirk Eddelbuettel 
>> >> wrote:
>> >>
>> >>>
>> >>> On 2 December 2010 at 17:23, Dominick Samperi wrote:
>> >>> | OK, since you are so accomodating, then please remove all reference
>> >>> to
>> >>> | my name from Rcpp as I do not want to be subject to arbitrary
>> >>> revisions
>> >>> of
>> >>> | my status. I may not have the right to say how my prior work will be
>> >>> used,
>> >>> | but I think I have the right to ask that my name not be used in the
>> >>> way
>> >>> | it is used in the recent update.
>> >>>
>> >>> As I pointed out, you change your mind on this every 12 months,
>> >>> limiting
>> >>> my
>> >>> patience and willingness for these dances.  It has also been suggested
>> >>> by
>> >>> other than attribution is clearer if you listed as the maintainer of
>> >>> the
>> >>> 2005/2006 code that we started from in 2008.
>> >>>
>> >>
>> >> The change that this thread is a reaction to happened a few days ago,
>> >> not
>> >> 12 months ago. If I wavered in the past it was because I was being
>> >> forced to compete with my own work, not a pleasant place to be.
>> >>
>> >> Are you telling me that you refuse to stop using my name
>> >> in Rcpp (except in copyright notices)?
>> >>
>> >> Are you telling me that you will continue to use my name and
>> >> update the associated status as you see fit, whether or not I
>> >> approve or consent to those changes?
>> >>
>> >> Please answer yes or no.
>> >>
>> >> Thanks,
>> >> Dominick
>> >>
>> >>
>> >>
>> >
>> >        [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>>
>> --
>> Michael Sumner
>> Institute for Marine and Antarctic Studies, University of Tasmania
>> Hobart, Australia
>> e-mail: mdsum...@gmail.com
>
>



-- 
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com

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

Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0

[John Nolan]

I have wrestled with this problem before.  I think correcting
the warning to "absolute error ~<= 0" is a good idea, and printing 
a warning if subdivisions==1 is also helpful.  Also, including
a simple example like the one that started this thread on the
help page for integrate might make the issue more clear to users.

But min.subdivisions is probably not.  On the example with dnorm( ),
I doubt 3 subdivisions would work.  The problem isn't that
we aren't sudividing enough, the problem is that the integrand
is 0 (in double precision) on most of the region and the
algorithm isn't designed to handle this.  There is no way to
determine how many subdivisions are necessary to get a reasonable
answer without a detailed analysis of the integrand.

I've gotten useful results with integrands that are monotonic on
the tail with a "self-triming integration" routine
like the following:

>right.trimmed.integrate <- function( f, lower, upper, epsilon=1e-100, 
>min.width=1e-10, ... ) {
+ # trim the region of integration on the right until f(x) > epsilon
+ 
+ a <- lower; b <- upper
+ while ( (b-a>min.width) && (f(b) right.trimmed.integrate( dnorm, 0, 2 )  # test
0.5 with absolute error < 9.2e-05

This can be adapted to left trim or (left and right) trim, abs(f(x)-c)>epsilon,
etc.  Setting the tolerances epsilon and min.width is an issue,
but an explicit discussion of these values could encourage people to
think about the problem in their specific case.  And of course, none
of this guarantees a correct answer, especially if someone tries this
on non-monotonic integrands with complicated 0 sets.  One could write 
a somewhat more user-friendly version where the user has to specify 
some property (or set of properties) of the integrand, e.g. "right-tail 
decreasing to 0", etc. and have the algorithm try to do smart
trimming based on this.  But perhaps this getting too involved.

In the end, there is no general solution because any solution
depends on the specific nature of the integrand.  Clearer messages,
warnings in suspicious cases like subdivisions==1, and a simple
example explaining what the issue is in the help page would help
some people.

John
 
 ...

 John P. Nolan
 Math/Stat Department
 227 Gray Hall
 American University
 4400 Massachusetts Avenue, NW
 Washington, DC 20016-8050

 jpno...@american.edu
 202.885.3140 voice
 202.885.3155 fax
 http://academic2.american.edu/~jpnolan
 ...

-r-devel-boun...@r-project.org wrote: - 
To: r-devel@r-project.org, Prof Brian Ripley 
From: Martin Maechler 
Sent by: r-devel-boun...@r-project.org
Date: 12/07/2010 03:29AM
Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0

> Prof Brian Ripley 
> on Tue, 7 Dec 2010 07:41:16 + (GMT) writes:

> On Mon, 6 Dec 2010, Spencer Graves wrote:
>> Hello:
>> 
>> 
>> The example "integrate(dnorm,0,2)" says it "fails on many systems". 
>> I just got 0 from it, when I should have gotten either an error or 
something 
>> close to 0.5.  I got this with R 2.12.0 under both Windows Vista_x64 and 
>> Linux (Fedora 13);  see the results from Windows below.  I thought you 
might 
>> want to know.

> Well, isn't that exactly what the help page says happens?  That 
> example is part of a section entitled

> ## integrate can fail if misused

> and is part of the illustration of

> If the function is
> approximately constant (in particular, zero) over nearly all its
> range it is possible that the result and error estimate may be
> seriously wrong.

yes, of course, 
and the issue has been known for ``ages''  ..
..
..
but it seems that too many useRs are not reading the help
page carefully, but only browse it quickly.
I think we (R developers) have to live with this fact
and should consider adapting to it a bit more, particularly in
this case (see below)

>> 
>> Thanks for all your work in creating and maintaining R.
>> 
>> 
>> Best Wishes,
>> Spencer Graves
>> ###

>> 
>> integrate(dnorm,0,2) ## fails on many systems

>> 0 with absolute error < 0

and this is particularly unsatisfactory for another reason:

"absolute error < 0"   
is *always* incorrect, so I think we should change *some*thing.

We could just use "<=" (and probably should in any case, or  
"< ~= x" which would convey ``is less than about x'' which I
think is all we can say),
but could consider giving a different message when the integral
evaluates to 0 or, rather actually,
only when the error bound ('abs.error') is 0 *and* 'subdivisions == 1'
as the latter indicates that the algorithm treated the integrand
f(.) as if f() was a linear function.

But in my quick experiments, even for linear (incl. constant)
functions, the 'abs.error' returned is never 0.

If we want to

Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0

[Pierre Chausse]

  The warning about "absolute error == 0" would not be sufficient 
because if you do
 > integrate(dnorm, 0, 5000)
2.326323e-06 with absolute error < 4.6e-06

We get reasonable absolute error and wrong answer. For very high upper 
bound, it seems more stable to use "Inf". In that case, another 
.External is used which seems to be optimized for high or low bounds:

 > integrate(dnorm, 0,Inf)
0.5 with absolute error < 4.7e-05


On 10-12-07 8:38 AM, John Nolan wrote:
> I have wrestled with this problem before.  I think correcting
> the warning to "absolute error ~<= 0" is a good idea, and printing
> a warning if subdivisions==1 is also helpful.  Also, including
> a simple example like the one that started this thread on the
> help page for integrate might make the issue more clear to users.
>
> But min.subdivisions is probably not.  On the example with dnorm( ),
> I doubt 3 subdivisions would work.  The problem isn't that
> we aren't sudividing enough, the problem is that the integrand
> is 0 (in double precision) on most of the region and the
> algorithm isn't designed to handle this.  There is no way to
> determine how many subdivisions are necessary to get a reasonable
> answer without a detailed analysis of the integrand.
>
> I've gotten useful results with integrands that are monotonic on
> the tail with a "self-triming integration" routine
> like the following:
>
>> right.trimmed.integrate<- function( f, lower, upper, epsilon=1e-100, 
>> min.width=1e-10, ... ) {
> + # trim the region of integration on the right until f(x)>  epsilon
> +
> + a<- lower; b<- upper
> + while ( (b-a>min.width)&&  (f(b) +
> + return( integrate(f,a,b,...) ) }
>
>> right.trimmed.integrate( dnorm, 0, 2 )  # test
> 0.5 with absolute error<  9.2e-05
>
> This can be adapted to left trim or (left and right) trim, 
> abs(f(x)-c)>epsilon,
> etc.  Setting the tolerances epsilon and min.width is an issue,
> but an explicit discussion of these values could encourage people to
> think about the problem in their specific case.  And of course, none
> of this guarantees a correct answer, especially if someone tries this
> on non-monotonic integrands with complicated 0 sets.  One could write
> a somewhat more user-friendly version where the user has to specify
> some property (or set of properties) of the integrand, e.g. "right-tail
> decreasing to 0", etc. and have the algorithm try to do smart
> trimming based on this.  But perhaps this getting too involved.
>
> In the end, there is no general solution because any solution
> depends on the specific nature of the integrand.  Clearer messages,
> warnings in suspicious cases like subdivisions==1, and a simple
> example explaining what the issue is in the help page would help
> some people.
>
> John
>
>   ...
>
>   John P. Nolan
>   Math/Stat Department
>   227 Gray Hall
>   American University
>   4400 Massachusetts Avenue, NW
>   Washington, DC 20016-8050
>
>   jpno...@american.edu
>   202.885.3140 voice
>   202.885.3155 fax
>   http://academic2.american.edu/~jpnolan
>   ...
>
> -r-devel-boun...@r-project.org wrote: -
> To: r-devel@r-project.org, Prof Brian Ripley
> From: Martin Maechler
> Sent by: r-devel-boun...@r-project.org
> Date: 12/07/2010 03:29AM
> Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0
>
>> Prof Brian Ripley
>>  on Tue, 7 Dec 2010 07:41:16 + (GMT) writes:
>  >  On Mon, 6 Dec 2010, Spencer Graves wrote:
>  >>  Hello:
>  >>
>  >>
>  >>  The example "integrate(dnorm,0,2)" says it "fails on many 
> systems".
>  >>  I just got 0 from it, when I should have gotten either an error or 
> something
>  >>  close to 0.5.  I got this with R 2.12.0 under both Windows Vista_x64 
> and
>  >>  Linux (Fedora 13);  see the results from Windows below.  I thought 
> you might
>  >>  want to know.
>
>  >  Well, isn't that exactly what the help page says happens?  That
>  >  example is part of a section entitled
>
>  >  ## integrate can fail if misused
>
>  >  and is part of the illustration of
>
>  >  If the function is
>  >  approximately constant (in particular, zero) over nearly all its
>  >  range it is possible that the result and error estimate may be
>  >  seriously wrong.
>
> yes, of course,
> and the issue has been known for ``ages''  ..
> ..
> ..
> but it seems that too many useRs are not reading the help
> page carefully, but only browse it quickly.
> I think we (R developers) have to live with this fact
> and should consider adapting to it a bit more, particularly in
> this case (see below)
>
>  >>
>  >>  Thanks for all your work in creating and maintaining R.
>  >>
>  >>
>  >>  Best Wishes,
>  >>  Spencer Graves
>  >>  ###
>
>  >>
>  >>  integrate(dnorm,0,2

Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0

[John Nolan]

Putting in Inf for the upper bound does not work in general:
all 3 of the following should give 0.5

> integrate( dnorm, 0, Inf )
0.5 with absolute error < 4.7e-05

> integrate( dnorm, 0, Inf, sd=10 )
Error in integrate(dnorm, 0, Inf, sd = 1e+05) : 
  the integral is probably divergent

> integrate( dnorm, 0, Inf, sd=1000 )
5.570087e-05 with absolute error < 0.00010

Numerical quadrature methods look at a finite number of
points, and you can find examples that will confuse any
algorithm.  Rather than hope a general method will solve
all problems, users should look at their integrand and
pick an appropriate region of integration.

John Nolan, American U.


-r-devel-boun...@r-project.org wrote: - 
To: r-devel@r-project.org
From: Pierre Chausse 
Sent by: r-devel-boun...@r-project.org
Date: 12/07/2010 09:46AM
Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0

  The warning about "absolute error == 0" would not be sufficient 
because if you do
 > integrate(dnorm, 0, 5000)
2.326323e-06 with absolute error < 4.6e-06

We get reasonable absolute error and wrong answer. For very high upper 
bound, it seems more stable to use "Inf". In that case, another 
.External is used which seems to be optimized for high or low bounds:

 > integrate(dnorm, 0,Inf)
0.5 with absolute error < 4.7e-05


On 10-12-07 8:38 AM, John Nolan wrote:
> I have wrestled with this problem before.  I think correcting
> the warning to "absolute error ~<= 0" is a good idea, and printing
> a warning if subdivisions==1 is also helpful.  Also, including
> a simple example like the one that started this thread on the
> help page for integrate might make the issue more clear to users.
>
> But min.subdivisions is probably not.  On the example with dnorm( ),
> I doubt 3 subdivisions would work.  The problem isn't that
> we aren't sudividing enough, the problem is that the integrand
> is 0 (in double precision) on most of the region and the
> algorithm isn't designed to handle this.  There is no way to
> determine how many subdivisions are necessary to get a reasonable
> answer without a detailed analysis of the integrand.
>
> I've gotten useful results with integrands that are monotonic on
> the tail with a "self-triming integration" routine
> like the following:
>
>> right.trimmed.integrate<- function( f, lower, upper, epsilon=1e-100, 
>> min.width=1e-10, ... ) {
> + # trim the region of integration on the right until f(x)>  epsilon
> +
> + a<- lower; b<- upper
> + while ( (b-a>min.width)&&  (f(b) +
> + return( integrate(f,a,b,...) ) }
>
>> right.trimmed.integrate( dnorm, 0, 2 )  # test
> 0.5 with absolute error<  9.2e-05
>
> This can be adapted to left trim or (left and right) trim, 
> abs(f(x)-c)>epsilon,
> etc.  Setting the tolerances epsilon and min.width is an issue,
> but an explicit discussion of these values could encourage people to
> think about the problem in their specific case.  And of course, none
> of this guarantees a correct answer, especially if someone tries this
> on non-monotonic integrands with complicated 0 sets.  One could write
> a somewhat more user-friendly version where the user has to specify
> some property (or set of properties) of the integrand, e.g. "right-tail
> decreasing to 0", etc. and have the algorithm try to do smart
> trimming based on this.  But perhaps this getting too involved.
>
> In the end, there is no general solution because any solution
> depends on the specific nature of the integrand.  Clearer messages,
> warnings in suspicious cases like subdivisions==1, and a simple
> example explaining what the issue is in the help page would help
> some people.
>
> John
>
>   ...
>
>   John P. Nolan
>   Math/Stat Department
>   227 Gray Hall
>   American University
>   4400 Massachusetts Avenue, NW
>   Washington, DC 20016-8050
>
>   jpno...@american.edu
>   202.885.3140 voice
>   202.885.3155 fax
>   http://academic2.american.edu/~jpnolan
>   ...
>
> -r-devel-boun...@r-project.org wrote: -
> To: r-devel@r-project.org, Prof Brian Ripley
> From: Martin Maechler
> Sent by: r-devel-boun...@r-project.org
> Date: 12/07/2010 03:29AM
> Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0
>
>> Prof Brian Ripley
>>  on Tue, 7 Dec 2010 07:41:16 + (GMT) writes:
>  >  On Mon, 6 Dec 2010, Spencer Graves wrote:
>  >>  Hello:
>  >>
>  >>
>  >>  The example "integrate(dnorm,0,2)" says it "fails on many 
> systems".
>  >>  I just got 0 from it, when I should have gotten either an error or 
> something
>  >>  close to 0.5.  I got this with R 2.12.0 under both Windows Vista_x64 
> and
>  >>  Linux (Fedora 13);  see the results from Windows below.  I thought 
> you might
>  >>  want to know.
>
>  >  Well, isn't that exactly what the help page says happens?  That
>  >  example is part of a section en

Re: [Rd] Wait for user input with readline()

[Petr Savicky]

On Mon, Dec 06, 2010 at 08:25:39AM -0800, Alexandre wrote:
> 
> Hi,
> 
> I have a similar problem as the one of Nate. The point is that I want to
> design an interactive script that need the value of two variables (x and y).
> 
> So my script as designed for the moment is :
> 
> x <- as.numeric (readline(prompt="What is the value of x? "))
> y <- as.numeric (readline(prompt="What is the value of y? "))
> 
> x
> y 
> 
> But the problem is that if I run this script, values returned for x and y
> will be "NA" like you can see below :

How do you call your code? Function readline() does not wait for
user input in a non-interactive session, for example R CMD BATCH
or Rscript.

Another situation, when readline() does not wait is, when you copy
a block of code and paste it to a running session, even if it is
interactive. If readline() is not the last line of the code, then
the next line of code is used instead of the user input.

Petr Savicky.

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

Re: [Rd] Wait for user input with readline()

[Simon Urbanek]

On Dec 7, 2010, at 12:19 PM, Petr Savicky wrote:

> On Mon, Dec 06, 2010 at 08:25:39AM -0800, Alexandre wrote:
>> 
>> Hi,
>> 
>> I have a similar problem as the one of Nate. The point is that I want to
>> design an interactive script that need the value of two variables (x and y).
>> 
>> So my script as designed for the moment is :
>> 
>> x <- as.numeric (readline(prompt="What is the value of x? "))
>> y <- as.numeric (readline(prompt="What is the value of y? "))
>> 
>> x
>> y 
>> 
>> But the problem is that if I run this script, values returned for x and y
>> will be "NA" like you can see below :
> 
> How do you call your code? Function readline() does not wait for
> user input in a non-interactive session, for example R CMD BATCH
> or Rscript.
> 
> Another situation, when readline() does not wait is, when you copy
> a block of code and paste it to a running session, even if it is
> interactive. If readline() is not the last line of the code, then
> the next line of code is used instead of the user input.
> 

You can't tell R code and input apart in cases like
R < myScript.R
but you can if you use source() or Rscript -- and you can treat them 
differently.

I assume what Alexandre wants is something like:
input=file("stdin")
print(readLines(input,1))
which works both in interactive and non-interactive setting and expects input 
in both cases (if you use Rscript or R -e 'source("...")' ).

Cheers,
Simon

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

Re: [Rd] Wait for user input with readline()

[Greg Snow]

Part of the problem seems to be that R is set up to run in 1 of 2 modes (I may 
be over generalizing or over simplifying here), the modes are interactive where 
you type in a command, R processes it and gives results, you type in another 
command, etc.  The other is Batch mode where everything is processed without 
user interaction.

You (and others) seem to want some combination of the 2, but it is not clear 
exactly how to merge the 2 modes for general.  You are asking the computer to 
try to read your mind about when to use the next line of the script as input 
and when to wait for the user.

Some possibilities for you being able to tell the computer what to do:

Convert your script to a function with the readlines inside the function, then 
run the function from the prompt (then the readlines will expect user input).

Use tcltk (or other GUI tools) to have a separate box pop-up to get the input 
(this will not allow the entry to ever be automated, the script will wait until 
the entry is submitted).

You could combine these using if statements on the results of the interactive() 
function to help decide whether to pop up the boxes or not.

Hope this helps,

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Alexandre
> Sent: Monday, December 06, 2010 9:26 AM
> To: r-devel@r-project.org
> Subject: Re: [Rd] Wait for user input with readline()
> 
> 
> Hi,
> 
> I have a similar problem as the one of Nate. The point is that I want
> to
> design an interactive script that need the value of two variables (x
> and y).
> 
> So my script as designed for the moment is :
> 
> x <- as.numeric (readline(prompt="What is the value of x? "))
> y <- as.numeric (readline(prompt="What is the value of y? "))
> 
> x
> y
> 
> But the problem is that if I run this script, values returned for x and
> y
> will be "NA" like you can see below :
> 
> > x <- as.numeric (readline(prompt="What is the value of x? "))
> What is the value of x?
> > y <- as.numeric (readline(prompt="What is the value of y? "))
> What is the value of y?
> > x
> [1] NA
> > y
> [1] NA
> 
> I have no problem to understand why, because R software does not let
> the
> time to enter the value for each variable. So Nate and I want to know
> if
> there is a way, to "force" R to wait the entrance of the value of each
> variable like written below:
> 
> First step of the script :
> 
> > x <- as.numeric (readline(prompt="What is the value of x? "))
> What is the value of x? 5
> 
> Second step of the script :
> 
> > y <- as.numeric (readline(prompt="What is the value of y? "))
> What is the value of y? 9
> 
> Finally :
> 
> > x
> [1] 5
> > y
> [1] 9
> 
> I hope that my english is not to bad and that you've understand what I
> mean.
> 
> Regards
> 
> Alexandre
> 
> --
> View this message in context: http://r.789695.n4.nabble.com/Wait-for-
> user-input-with-readline-tp3054517p3074781.html
> Sent from the R devel mailing list archive at Nabble.com.
> 
> __
> 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] Suggested change to integrate.Rd (was: Re: 0.5 != integrate(dnorm, 0, 20000) = 0)

[Spencer Graves]

  What do you think about changing the verbiage with that example 
in "integrate.Rd" from "fails on many systems" to something like

"gives wrong answer without warning on many systems"?


  If I had write access to the core R code, I'd change this 
myself:  I'm probably not the only user who might think that saying 
something "fails" suggest it gives an error message.  Many contributions 
on this thread make it clear that it will never be possible to write an 
integrate function that won't give a "wrong answer without warning" in 
some cases.



  Thanks,
  Spencer


#
On 12/7/2010 7:02 AM, John Nolan wrote:

Putting in Inf for the upper bound does not work in general:
all 3 of the following should give 0.5


integrate( dnorm, 0, Inf )

0.5 with absolute error<  4.7e-05


integrate( dnorm, 0, Inf, sd=10 )

Error in integrate(dnorm, 0, Inf, sd = 1e+05) :
   the integral is probably divergent


integrate( dnorm, 0, Inf, sd=1000 )

5.570087e-05 with absolute error<  0.00010

Numerical quadrature methods look at a finite number of
points, and you can find examples that will confuse any
algorithm.  Rather than hope a general method will solve
all problems, users should look at their integrand and
pick an appropriate region of integration.

John Nolan, American U.


-r-devel-boun...@r-project.org wrote: -
To: r-devel@r-project.org
From: Pierre Chausse
Sent by: r-devel-boun...@r-project.org
Date: 12/07/2010 09:46AM
Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0

   The warning about "absolute error == 0" would not be sufficient
because if you do
  >  integrate(dnorm, 0, 5000)
2.326323e-06 with absolute error<  4.6e-06

We get reasonable absolute error and wrong answer. For very high upper
bound, it seems more stable to use "Inf". In that case, another
.External is used which seems to be optimized for high or low bounds:

  >  integrate(dnorm, 0,Inf)
0.5 with absolute error<  4.7e-05


On 10-12-07 8:38 AM, John Nolan wrote:

I have wrestled with this problem before.  I think correcting
the warning to "absolute error ~<= 0" is a good idea, and printing
a warning if subdivisions==1 is also helpful.  Also, including
a simple example like the one that started this thread on the
help page for integrate might make the issue more clear to users.

But min.subdivisions is probably not.  On the example with dnorm( ),
I doubt 3 subdivisions would work.  The problem isn't that
we aren't sudividing enough, the problem is that the integrand
is 0 (in double precision) on most of the region and the
algorithm isn't designed to handle this.  There is no way to
determine how many subdivisions are necessary to get a reasonable
answer without a detailed analysis of the integrand.

I've gotten useful results with integrands that are monotonic on
the tail with a "self-triming integration" routine
like the following:


right.trimmed.integrate<- function( f, lower, upper, epsilon=1e-100, 
min.width=1e-10, ... ) {

+ # trim the region of integration on the right until f(x)>   epsilon
+
+ a<- lower; b<- upper
+ while ( (b-a>min.width)&&   (f(b)
right.trimmed.integrate( dnorm, 0, 2 )  # test

0.5 with absolute error<   9.2e-05

This can be adapted to left trim or (left and right) trim, abs(f(x)-c)>epsilon,
etc.  Setting the tolerances epsilon and min.width is an issue,
but an explicit discussion of these values could encourage people to
think about the problem in their specific case.  And of course, none
of this guarantees a correct answer, especially if someone tries this
on non-monotonic integrands with complicated 0 sets.  One could write
a somewhat more user-friendly version where the user has to specify
some property (or set of properties) of the integrand, e.g. "right-tail
decreasing to 0", etc. and have the algorithm try to do smart
trimming based on this.  But perhaps this getting too involved.

In the end, there is no general solution because any solution
depends on the specific nature of the integrand.  Clearer messages,
warnings in suspicious cases like subdivisions==1, and a simple
example explaining what the issue is in the help page would help
some people.

John

   ...

   John P. Nolan
   Math/Stat Department
   227 Gray Hall
   American University
   4400 Massachusetts Avenue, NW
   Washington, DC 20016-8050

   jpno...@american.edu
   202.885.3140 voice
   202.885.3155 fax
   http://academic2.american.edu/~jpnolan
   ...

-r-devel-boun...@r-project.org wrote: -
To: r-devel@r-project.org, Prof Brian Ripley
From: Martin Maechler
Sent by: r-devel-boun...@r-project.org
Date: 12/07/2010 03:29AM
Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0


Prof Brian Ripley
  on Tue, 7 Dec 2010 07:41:16 + (GMT) writes:

  >   On Mon, 6 Dec 2010, Spencer Graves wrote:
  >>   Hello:
  >>
  >>
 

Re: [Rd] Suggested change to integrate.Rd (was: Re: 0.5 != integrate(dnorm, 0, 20000) = 0)

[John Nolan]

R developers understand intimately how things work, and terse
descriptions are sufficient.  However, most typical R users 
would benefit from clearer documentation.  In multiple places 
I've found the R documentation to be correct and understandable 
AFTER I've figured a function out.  

And to be fair, this problem with integrate( ) isn't really R's 
fault: the QUADPACK routines that R uses are very good algorithms, 
but neither they nor any other package can handle all cases.  

I would support reasonable changes in the documentation for
integrate( ).   Just saying it "gives wrong answer without 
warning on many systems" seems misleading (it works fine in
many cases) and it doesn't help a user understand how to use
integrate( ) correctly/carefully.  IMO a simple example like 
this one w/ dnorm would catch peoples attention and a couple 
lines of explanation/warning would then make more sense.  

John Nolan, American U


-Spencer Graves  wrote: - 
To: John Nolan 
From: Spencer Graves 
Date: 12/07/2010 07:58PM
Cc: pchau...@uwaterloo.ca, r-devel@r-project.org
Subject: Suggested change to integrate.Rd (was: Re: [Rd] 0.5 != 
integrate(dnorm,0,2) = 0)

   What do you think about changing the verbiage with that example 
in "integrate.Rd" from "fails on many systems" to something like
"gives wrong answer without warning on many systems"?


   If I had write access to the core R code, I'd change this 
myself:  I'm probably not the only user who might think that saying 
something "fails" suggest it gives an error message.  Many contributions 
on this thread make it clear that it will never be possible to write an 
integrate function that won't give a "wrong answer without warning" in 
some cases.


   Thanks,
   Spencer


#
On 12/7/2010 7:02 AM, John Nolan wrote:
> Putting in Inf for the upper bound does not work in general:
> all 3 of the following should give 0.5
>
>> integrate( dnorm, 0, Inf )
> 0.5 with absolute error<  4.7e-05
>
>> integrate( dnorm, 0, Inf, sd=10 )
> Error in integrate(dnorm, 0, Inf, sd = 1e+05) :
>the integral is probably divergent
>
>> integrate( dnorm, 0, Inf, sd=1000 )
> 5.570087e-05 with absolute error<  0.00010
>
> Numerical quadrature methods look at a finite number of
> points, and you can find examples that will confuse any
> algorithm.  Rather than hope a general method will solve
> all problems, users should look at their integrand and
> pick an appropriate region of integration.
>
> John Nolan, American U.
>
>
> -r-devel-boun...@r-project.org wrote: -
> To: r-devel@r-project.org
> From: Pierre Chausse
> Sent by: r-devel-boun...@r-project.org
> Date: 12/07/2010 09:46AM
> Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0
>
>The warning about "absolute error == 0" would not be sufficient
> because if you do
>   >  integrate(dnorm, 0, 5000)
> 2.326323e-06 with absolute error<  4.6e-06
>
> We get reasonable absolute error and wrong answer. For very high upper
> bound, it seems more stable to use "Inf". In that case, another
> .External is used which seems to be optimized for high or low bounds:
>
>   >  integrate(dnorm, 0,Inf)
> 0.5 with absolute error<  4.7e-05
>
>
> On 10-12-07 8:38 AM, John Nolan wrote:
>> I have wrestled with this problem before.  I think correcting
>> the warning to "absolute error ~<= 0" is a good idea, and printing
>> a warning if subdivisions==1 is also helpful.  Also, including
>> a simple example like the one that started this thread on the
>> help page for integrate might make the issue more clear to users.
>>
>> But min.subdivisions is probably not.  On the example with dnorm( ),
>> I doubt 3 subdivisions would work.  The problem isn't that
>> we aren't sudividing enough, the problem is that the integrand
>> is 0 (in double precision) on most of the region and the
>> algorithm isn't designed to handle this.  There is no way to
>> determine how many subdivisions are necessary to get a reasonable
>> answer without a detailed analysis of the integrand.
>>
>> I've gotten useful results with integrands that are monotonic on
>> the tail with a "self-triming integration" routine
>> like the following:
>>
>>> right.trimmed.integrate<- function( f, lower, upper, epsilon=1e-100, 
>>> min.width=1e-10, ... ) {
>> + # trim the region of integration on the right until f(x)>   epsilon
>> +
>> + a<- lower; b<- upper
>> + while ( (b-a>min.width)&&   (f(b)> +
>> + return( integrate(f,a,b,...) ) }
>>
>>> right.trimmed.integrate( dnorm, 0, 2 )  # test
>> 0.5 with absolute error<   9.2e-05
>>
>> This can be adapted to left trim or (left and right) trim, 
>> abs(f(x)-c)>epsilon,
>> etc.  Setting the tolerances epsilon and min.width is an issue,
>> but an explicit discussion of these values could encourage people to
>> think about the problem in their specific case.  And of course, none
>> of this guarantees a correct answer, especially if someone tries this
>> on non-monotonic integrands with

Re: [Rd] Suggested change to integrate.Rd (was: Re: 0.5 != integrate(dnorm, 0, 20000) = 0)

[David Scott]

If changes are to be made to integrate it would be nice if the following 
was fixed:

> integrate(dnorm, -Inf, -Inf)
1 with absolute error < 9.4e-05

Note that integrate manages ok when not dealing with Inf or -Inf:
> integrate(dnorm, -500, -500)
0 with absolute error < 0

David Scott




On 8/12/2010 5:08 p.m., John Nolan wrote:

R developers understand intimately how things work, and terse
descriptions are sufficient.  However, most typical R users
would benefit from clearer documentation.  In multiple places
I've found the R documentation to be correct and understandable
AFTER I've figured a function out.

And to be fair, this problem with integrate( ) isn't really R's
fault: the QUADPACK routines that R uses are very good algorithms,
but neither they nor any other package can handle all cases.

I would support reasonable changes in the documentation for
integrate( ).   Just saying it "gives wrong answer without
warning on many systems" seems misleading (it works fine in
many cases) and it doesn't help a user understand how to use
integrate( ) correctly/carefully.  IMO a simple example like
this one w/ dnorm would catch peoples attention and a couple
lines of explanation/warning would then make more sense.

John Nolan, American U


-Spencer Graves  wrote: -
To: John Nolan
From: Spencer Graves
Date: 12/07/2010 07:58PM
Cc: pchau...@uwaterloo.ca, r-devel@r-project.org
Subject: Suggested change to integrate.Rd (was: Re: [Rd] 0.5 != 
integrate(dnorm,0,2) = 0)

What do you think about changing the verbiage with that example
in "integrate.Rd" from "fails on many systems" to something like
"gives wrong answer without warning on many systems"?


If I had write access to the core R code, I'd change this
myself:  I'm probably not the only user who might think that saying
something "fails" suggest it gives an error message.  Many contributions
on this thread make it clear that it will never be possible to write an
integrate function that won't give a "wrong answer without warning" in
some cases.


Thanks,
Spencer


#
On 12/7/2010 7:02 AM, John Nolan wrote:

Putting in Inf for the upper bound does not work in general:
all 3 of the following should give 0.5


integrate( dnorm, 0, Inf )

0.5 with absolute error<   4.7e-05


integrate( dnorm, 0, Inf, sd=10 )

Error in integrate(dnorm, 0, Inf, sd = 1e+05) :
the integral is probably divergent


integrate( dnorm, 0, Inf, sd=1000 )

5.570087e-05 with absolute error<   0.00010

Numerical quadrature methods look at a finite number of
points, and you can find examples that will confuse any
algorithm.  Rather than hope a general method will solve
all problems, users should look at their integrand and
pick an appropriate region of integration.

John Nolan, American U.


-r-devel-boun...@r-project.org wrote: -
To: r-devel@r-project.org
From: Pierre Chausse
Sent by: r-devel-boun...@r-project.org
Date: 12/07/2010 09:46AM
Subject: Re: [Rd] 0.5 != integrate(dnorm,0,2) = 0

The warning about "absolute error == 0" would not be sufficient
because if you do
   >   integrate(dnorm, 0, 5000)
2.326323e-06 with absolute error<   4.6e-06

We get reasonable absolute error and wrong answer. For very high upper
bound, it seems more stable to use "Inf". In that case, another
.External is used which seems to be optimized for high or low bounds:

   >   integrate(dnorm, 0,Inf)
0.5 with absolute error<   4.7e-05


On 10-12-07 8:38 AM, John Nolan wrote:

I have wrestled with this problem before.  I think correcting
the warning to "absolute error ~<= 0" is a good idea, and printing
a warning if subdivisions==1 is also helpful.  Also, including
a simple example like the one that started this thread on the
help page for integrate might make the issue more clear to users.

But min.subdivisions is probably not.  On the example with dnorm( ),
I doubt 3 subdivisions would work.  The problem isn't that
we aren't sudividing enough, the problem is that the integrand
is 0 (in double precision) on most of the region and the
algorithm isn't designed to handle this.  There is no way to
determine how many subdivisions are necessary to get a reasonable
answer without a detailed analysis of the integrand.

I've gotten useful results with integrands that are monotonic on
the tail with a "self-triming integration" routine
like the following:


right.trimmed.integrate<- function( f, lower, upper, epsilon=1e-100, 
min.width=1e-10, ... ) {

+ # trim the region of integration on the right until f(x)>epsilon
+
+ a<- lower; b<- upper
+ while ( (b-a>min.width)&&(f(b)
right.trimmed.integrate( dnorm, 0, 2 )  # test

0.5 with absolute error<9.2e-05

This can be adapted to left trim or (left and right) trim, abs(f(x)-c)>epsilon,
etc.  Setting the tolerances epsilon and min.width is an issue,
but an explicit discussion of these values could encourage people to
think about the problem in their specific case.  And of