Forum: help
Monitor Forum | Start New ThreadRE: 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. |