|
From: Petr M. <mi...@ph...> - 2009-12-04 16:19:54
|
An anonymous user "r/e-letter/inpost" reported different outputs of gnuplot from OpenSUSE and 4.4. Well it seems that the 3rd parameter of the gridding method changed between 4.2 and 4.4. Try any 4.2.x and 4.4 and these examples: set dgrid3d ,,1; show dgrid; splot '3.dat' with line set dgrid3d ,,8; show dgrid; splot '3.dat' with line 3.dat: 1 1 1 1 2 2 1 3 3 2 1 2 2 2 2 2 3 2 3 1 3 3 2 2 3 3 1 There is yet another error in 4.4 -- the following command fails: m=5; n=8; set dgrid3d m,m,n --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-12-04 21:26:52
|
On Friday 04 December 2009 08:19:43 Petr Mikulik wrote: > An anonymous user "r/e-letter/inpost" reported different outputs of gnuplot > from OpenSUSE and 4.4. Well it seems that the 3rd parameter of the gridding > method changed between 4.2 and 4.4. > > Try any 4.2.x and 4.4 and these examples: > > set dgrid3d ,,1; show dgrid; splot '3.dat' with line > set dgrid3d ,,8; show dgrid; splot '3.dat' with line I get identical results with 4.2.5 and 4.4.0-rc1. Perhaps you could post screenshots? > There is yet another error in 4.4 -- the following command fails: > m=5; n=8; set dgrid3d m,m,n I confirm this one. It looks like the "new" set_dgrid3d() routine is falsely assuming it can detect numerical values by calling isanumber(). <aside> We should rename that routine! It doesn't at all do what its name suggests. </aside> I'll have a quick go at fixing this. Ethan |
|
From: Ethan M. (sfeam) <eam...@gm...> - 2009-12-05 04:03:24
Attachments:
set_dgrid3d_04dec2009.patch
|
On Friday 04 December 2009, Ethan Merritt wrote: > On Friday 04 December 2009 08:19:43 Petr Mikulik wrote: > > > There is yet another error in 4.4 -- the following command fails: > > m=5; n=8; set dgrid3d m,m,n > > I'll have a quick go at fixing this. Patch attached. It turned out to be more involved than I expected, so please test. Ethan |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-12-04 22:41:48
|
On Friday 04 December 2009 13:25:18 Ethan Merritt wrote: > On Friday 04 December 2009 08:19:43 Petr Mikulik wrote: > > > There is yet another error in 4.4 -- the following command fails: > > m=5; n=8; set dgrid3d m,m,n > > I confirm this one. > It looks like the "new" set_dgrid3d() routine is falsely assuming > it can detect numerical values by calling isanumber(). > > <aside> > We should rename that routine! > It doesn't at all do what its name suggests. > </aside> > > I'll have a quick go at fixing this. Hmm. This is more complicated than I thought. Could someone please clarify: - The BNF description of syntax under "help set dgrid3d" shows only the "hann" option taking 2 additional parameters. But the text says that 5 options use these parameters. Which is correct? - Is there a difference between set dgrid3d <rows>, <cols>, <norm> # old syntax and set dgrid3d <rows>, <cols>, <norm> qnorm # is this legal? and set dgrid3d <rows>, <cols> qnorm <norm> # new syntax - Note that the current BNF description of syntax would not allow either of the first two commands above Ethan |
|
From: Philipp K. J. <ja...@ie...> - 2009-12-06 16:06:08
|
It was me who wrote the code for the "new" dgrid3d function, a couple of years back. I am just looking at the code and trying to get back into what I tried to do. > > Could someone please clarify: > > - The BNF description of syntax under "help set dgrid3d" shows > only the "hann" option taking 2 additional parameters. > But the text says that 5 options use these parameters. > Which is correct? All of the "new" smoothing kernels take the same number of parameters. There is a set of square brackets missing in the doc. (My bad.) > > - Is there a difference between > set dgrid3d <rows>, <cols>, <norm> # old syntax > and > set dgrid3d <rows>, <cols>, <norm> qnorm # is this legal? This should not be legal. (But it might work - got to try.) > and > set dgrid3d <rows>, <cols> qnorm <norm> # new syntax This should be identical to the first. > > - Note that the current BNF description of syntax would not allow > either of the first two commands above That is correct. The synopsis shows only the new form of the command, which makes the kernel explicit. According to the 2nd to last para in the doc, the first version is accepted for backward compatibility I'll look at Ethan's patch next. > > Ethan |