3

Could anyone suggest why the following example code does not work:

require(biwavelet)
t <- seq(1/24, 365, 1/24)
A <- 2
fs <- 1/24
y <- A + sin(2*pi*fs*t)
d = cbind(t,y)
wt.t1 <- wt(d)
plot(wt.t1)

It generates an error stating:

Error in image.default(x$t, yvals, t(zvals), zlim = zlims, ylim = rev(range(yvals)),  : 
  invalid z limits

How would I fix this problem?

Additional:

In response to Gavin Simpsons answer: If I keep the data to only include one frequency but alter the time vector, the code works fine. 

require(biwavelet)
A <- 2
fs <- 1/24
y <- A + sin(2*pi*fs*t)
d <- cbind(seq(1,8760), y) 
wt.t1 <- wt(d)
plot(wt.t1)
MichaelChirico
  • 33,841
  • 14
  • 113
  • 198
KatyB
  • 3,920
  • 7
  • 42
  • 72
  • If you could help by verifying you've got the correct inputs to `wt` (since `biwavelet` is not a common package), and taking a look at the values in your output `wt.t1` , it may help explain why the `plot` method for whatever class `wt` generates is not working. – Carl Witthoft Aug 14 '12 at 13:22

2 Answers2

5

You discovered a bug in the wt.R function (errant parentheses). The bug has been fixed in version 0.12 of the biwavelet package, so both versions of your code above should now work.

Thanks for spotting the error. Please don't hesitate to email the maintainer of the package (i.e., me) about bugs in the future.

Tarik
  • 61
  • 1
3

I suspect this is due to the fact that you have only a single frequency here and the function isn't set up for that. I can get a plot by adding white noise to y:

require(biwavelet)
t <- seq(1/24, 365, 1/24)
A <- 2
fs <- 1/24
y <- A + sin(2*pi*fs*t)
d <- cbind(t, y + rnorm(length(y))) ## add some white noise to y
wt.t1 <- wt(d)
plot(wt.t1)

You might wish to contact the maintainers to report the issue. I got the plot to do something when I debugged it and reversed zlim so that diff(zlim) was positive, so it might be that the author of the plot() method was making an assumption that doesn't hold in all cases.

Gavin Simpson
  • 170,508
  • 25
  • 396
  • 453
  • I dont know if this is the problem. Please see the additional details added to the question. – KatyB Aug 15 '12 at 06:48
  • Then it is a bug or an infelicity in the code. I know why the code fails - it passes to the image argument zlim a vector of axis limits, the first of which is positive the second of which is negative. This is because of the way the function is coded though it is not intended. So like I said, speak to the package maintainer and show them your example. – Gavin Simpson Aug 15 '12 at 07:00