SCM

Forum: help

Monitor Forum | Start New Thread Start New Thread
RE: Grid for approxfun too wide [ Reply ]
By: Peter Ruckdeschel on 2016-08-10 17:44
[forum:43414]
Hi Tim,

thanks for your interest in distr and friends.

The important message right away is that you may indeed ignore the warning
(it is not an error!).

Details:

You can get your program run without any warning with

t1 <- Unif(2, 4)/25
t2 <- Unif(57, 59)/25
t <- t2 - t1
s <- Unif(67.5, 69.5)
x <- ((s/36)*t/10)*100

I admit that this must indeed be strange to you, but in fact, the warning is issued
by helper function

.discretizeP

which is used in any call to "+" (hence also to "-", "*", "/", "^") for two operands
in order to prevent the fact that you end up with a two coarse discretization.
A "too-coarse warning" is issued by .discretizeP whenever

h > h0

where h is determined in the calling function as

lower <- min(getLow(e1), getLow(e2))
upper <- max(getUp(e1) , getUp(e2))

### Step 2 : Discretizing

n <- getdistrOption("DefaultNrFFTGridPointsExponent")
h <- (upper-lower)/2^n

and getLow, getUp determine left and right endpoint of the distribution,
respectively the eps and 1-eps quantile for eps = getdistrOption("TruncQuantile")

and h0 for D=e1 and, subsequently, D=e2 is determined as

h0 <- 40*(getUp(D)-getLow(D)) /
2^getdistrOption("DefaultNrFFTGridPointsExponent")

This is to prevent the fact that the range of e1 and e2 is too different to obtain a "good" approximation by our FFT method.

In your case this simple scaling does the job; it would not if t or s were composed by several disjoint parts of the support each of different length...

Hope this helps, best regards, Peter

Grid for approxfun too wide [ Reply ]
By: Tim Bate on 2016-08-09 04:23
[forum:43413]
I'm having trouble understanding why I'm getting this, what leads to it, and how to avoid it. The full message is:

In .discretizeP(e1, lower, upper, h) :
Grid for approxfun too wide, increase DefaultNrFFTGridPointsExponent

I sometimes get it for e2 as well. I know, it appears self explanatory. But firstly, large increases in DefaultNrFFTGridPointsExponent do nothing, and secondly, I have noticed something interesting about the cause. This is easiest to explain with simple examples.

# Example 1
# Estimates distance (x) from time measurement (t) and speed estimate (s)
require ( distr )
require (distrEx )
t1 <- Unif(2, 4)/25
t2 <- Unif(57, 59)/25
t <- t2 - t1
s <- Unif(67.5, 69.5)/3.6
x <- s*t

This produces the error. Note the "25"s are the number of units per second (so t is in seconds) and "3.6" is used to go from km/h to m/s. Shifting these values inside the brackets makes no difference. I can use huge values for DefaultNrFFTGridPointsExponent and no effect except it takes minutes to run.

# Example 2
# Estimates distance (x) from time measurement (t) and speed estimate (s)
require ( distr )
require (distrEx )
t1 <- Unif(2, 4)
t2 <- Unif(57, 59)
t <- t2 - t1
s <- Unif(67.5, 69.5)
x <- s*t

Example 2 is the same except without the divisors. No errors. All that has changed is the scale. I am surprised this has an effect.

I really need to understand this better for an analysis I am writing, either to avoid the warnings, or to understand their importance (or lack of importance). I have tried the documents including the vignette, but can't seem to get enough detail. Any help would be appreciated.

Thanks to:
Vienna University of Economics and Business Powered By FusionForge