Menu
▾
▴
gnuplot-info
|
From: seb_kramm <seb...@ya...> - 2012-10-01 15:53:13
|
Hello gnuplot users, While trying to plot a sawtooth wave (with 4.6 on Ubuntu), I noticed that the following plot: plot [0:10] x-floor(x) produces some kind of vertical drifting, that gets magically reset at the end of the plot (whatever the x range, actually). (see attached png) I tried also plot [0:10] x-1.0*floor(x) to cast the int to floating-point, didn't change anything. This seems to be related to the number of samples. Indeed, 'set samples 1000' solves the problem. But I was wondering if such a behaviour is normal ? I understand that the number of samples can be changed to set the plot accuracy vs. computing time tradeoff, but I didn't expect that that parameter could produce "wrong" results if incorrectly set. I consider myself as a rather experienced gnuplot user, and it took me some time to fix this issue, a newbie might have struggled with this during hours on such a simple thing (and would probably have accused gnuplot of being buggy...) What do you think ? Is it worth fixing something (of course, in the case it *could* be fixed)? Or do you think it is okay this way ? Regards, |
|
From: BBands <bb...@gm...> - 2012-10-01 21:24:59
|
Not enough granularity.
Try 'set samples 1000'.
Best,
John
On Mon, Oct 1, 2012 at 8:33 AM, seb_kramm <seb...@ya...> wrote:
> Hello gnuplot users,
>
> While trying to plot a sawtooth wave (with 4.6 on Ubuntu), I noticed that
> the following plot:
> plot [0:10] x-floor(x)
> produces some kind of vertical drifting, that gets magically reset at the
> end of the plot (whatever the x range, actually).
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2012-10-01 22:11:55
|
On 01.10.2012 17:33, seb_kramm wrote: > While trying to plot a sawtooth wave (with 4.6 on Ubuntu), I noticed > that the following plot: > plot [0:10] x-floor(x) > produces some kind of vertical drifting, that gets magically reset at > the end of the plot (whatever the x range, actually). (see attached png) The attachment didn't make it past the mailing list processor. > This seems to be related to the number of samples. Indeed, 'set samples > 1000' solves the problem. But I was wondering if such a behaviour is > normal ? Yes, it is. Oh, and it's not the floor() function that's "drifting" here. To see what actually happens, I suggest you have a look at the output of set table plot [0:10] x - floor(x) and pay attention to both columns of data. And no, 'set samples 1000' didn't actually solve the problem. It just made it small enough so you no longer noticed it. The actual solution would have been more 'set samples 101'. To understand why. > I understand that the number of samples can be changed to set the plot > accuracy vs. computing time tradeoff, but I didn't expect that that > parameter could produce "wrong" results if incorrectly set. The thing to be learned here is that the result isn't actually wrong. It's just not what you expected. |
|
From: seb_kramm <seb...@ya...> - 2012-10-02 07:39:03
|
Hello, > The attachment didn't make it past the mailing list processor. It's ok, you got the point anyway. On 10/02/2012 12:11 AM, Hans-Bernhard Bröker wrote: > Yes, it is. Oh, and it's not the floor() function that's "drifting" here. To see > what actually happens, I suggest you have a look at the output of > > set table > plot [0:10] x - floor(x) Very good suggestion indeed, thanks, this way things are obvious! > And no, 'set samples 1000' didn't actually solve the problem. It just made it small > enough so you no longer noticed it. > The actual solution would have been more 'set samples 101'. To understand why. Yes, odd vs. even number of samples, I got the point. But then it is not very clear to me why the default number of samples is even, as the situation pointed out here can occur rather frequently. Is there some particular reason ? I assume there is, as you guys probably already ran into that issue, I'm just curious. At first, if I need to compute some function values, I'd compute them at the beginning and the end of the considered interval, and, say, one value in the middle. If given more time, I'd compute two other values in the "middle of the middle" (1/4 and 3/4). And so on. So, the default instinctive number of samples would be odd. But maybe there is a counterpart to this approach that I don't see ? Or is it really not that important ? >> I understand that the number of samples can be changed to set the plot >> accuracy vs. computing time tradeoff, but I didn't expect that that >> parameter could produce "wrong" results if incorrectly set. > > The thing to be learned here is that the result isn't actually wrong. It's just not > what you expected. Sure, this is why I quoted "wrong", I meant "apparently wrong". I'm confident enough with Gnuplot to know that it is a very good piece of software when it comes to numerical computation! Regards, and thanks again for your detailed answer. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2012-10-02 17:52:39
|
On 02.10.2012 09:38, seb_kramm wrote: > It's ok, you got the point anyway. Actually, I'm afraid you didn't. Not all of it, anyway. >> The actual solution would have been more 'set samples 101'. To understand why. > > Yes, odd vs. even number of samples, I got the point. Except that it isn't. An even number of points can be just as correct. The actual trick lies in the combination of the underlying function's periodicity, the ordinate range, and the number of samples: you want to have a sampling distance that is an integer fraction of the signal's period, i.e. function_period / (range_max - range_min) * (samples - 1) should be an integer. E.g. set samples 100 plot [0:9] x-floor(x) matches your expectations just fine, because 1.0/9.0*99 = 11.0 > But then it is not very clear to me why the default number of > samples is even, as the situation pointed out here can occur rather > frequently. And just as frequently, an odd number wouldn't be any better. It would just yield a different, equally unexpected result. |
|
From: seb_kramm <seb...@ya...> - 2012-10-02 20:43:09
|
On 10/02/2012 07:52 PM, Hans-Bernhard Bröker wrote: > Except that it isn't. An even number of points can be just as correct. The actual > trick lies in the combination of the underlying function's periodicity, the ordinate > range, and the number of samples: you want to have a sampling distance that is an > integer fraction of the signal's period, i.e. > function_period / (range_max - range_min) * (samples - 1) > should be an integer. E.g. > set samples 100 > plot [0:9] x-floor(x) > matches your expectations just fine, because 1.0/9.0*99 = 11.0 You are absolutely right, thanks for these clarifications. I indeed assumed that one would always want to plot on an even range, which can't always be the case. Regards, |
