From: Alan W. I. <ir...@be...> - 2002-10-16 01:45:17
|
On Wed, 16 Oct 2002, Joao Cardoso wrote: > On Tuesday 15 October 2002 22:43, Alan W. Irwin wrote: > > I have just been checking Joao's recent change using valgrind. The only > > *PLplot* memory management problem that it finds now is > > > > ==9658== Use of uninitialised value of size 8 > > ==9658== at 0x4025DECC: plP_draw3d (plot3d.c:1451) > > ==9658== by 0x4025DD7A: plnxtvhi_draw (plot3d.c:1400) > > ==9658== by 0x4025D968: plnxtvhi (plot3d.c:1244) > > ==9822== by 0x4025D7D9: plnxtv (plot3d.c:1174) > > ==9822== by 0x4025C40E: plt3zz (plot3d.c:947) > > ==9822== by 0x4025BAFC: c_plot3d (plot3d.c:729) > > ==9822== by 0x40259611: c_plmesh (plot3d.c:100) > > ==9822== by 0x8049046: main (x08c.c:176) > > > > Line 1451 of plot3d.c is > > > > if (c != NULL && c[--j] >= 0. && c[j] <= 1.) > > > > Under gdb for some reason I cannot print out c or j for the plP_draw3d > > stack frame, but if I use "up" to get to the plnxtvhi_draw stack frame j is > > 37 and c has reasonable values in it up c[35]. However, c[36] is 0. > > strongly suggesting that may be the uninitialized value that is causing the > > valgrind warning. > > > > Can you have a further look at this, Joao, to see why that c value is > > uninitialized? > > The source of the problem is in plnxtvhi_draw() and plnxtvlo(), where > plP_draw3d() is called. > The problem is to "find" the correct value "j" to pass to plP_draw3d(), as > both plnxtvhi_draw() and plnxtvlo() are complex, dealing with hidden line > removal and maintaining two closely coupled indexes. > c[] by itself is correctly initialized in plt3zz() and contains the amplitude > values of the (redimensioned) "z" matrix. > > The original > if (c != NULL && c[j] >= 0. && c[j] <= 1.) > visually failed because, as you say above, sometimes c[j] contains garbage, as > "j" goes after the end of the "c" array. > The "--j" version does not fails visually, as it uses initialized values of > the "c" array, but I think it fails because sometimes "j" is "0". > Well, I do know the origin of the problem, but not the cure. > > And if you notice the "&& c[j] >= 0. && c[j] <= 1." you would understand that > I was aware of some possible problems, else I wouldn't check for it... Actually, I had no clue this was a line you had been working with. (I know, I could have looked at the diffs of your version compared to previous, but instead I was just following what valgrind told me.) There is one misunderstanding that should be cleared up here. valgrind warns of an uninitialized variable for your current version when j = 27. Your c[--j] then looks at c[26] as does the c[j] after it. But that is still uninitialized (according to valgrind and also gdb shows its value is 0.) As I said in my post the last initialized value is c[25]. The obvious solution is to constrain j so that the references to c always stay within the initialized bounds. Can that be done? Also, referring to your next post about tcl precision I agree it is possible that could be the cause of the difference with C and python. But that cannot explain the python -- C difference (both our double precision). So my working hypothesis remains the same. Once C and python agree, then it will be most interesting to see whether tcl falls into line or whether its 12 digits or precision will make a difference. Typically, it does not make a difference on other examples, but we will see once the uninitialized variable is taken care of. Alan |
From: Alan W. I. <ir...@be...> - 2002-10-16 02:42:34
|
On Tue, 15 Oct 2002, Alan W. Irwin wrote: > Also, referring to your next post about tcl precision I agree it is possible > that could be the cause of the difference with C and python. But that ARRGH. That should have read C and *tcl*. Alan |
From: Joao C. <jc...@fe...> - 2002-10-16 22:20:37
|
On Wednesday 16 October 2002 02:45, Alan W. Irwin wrote: > On Wed, 16 Oct 2002, Joao Cardoso wrote: > > On Tuesday 15 October 2002 22:43, Alan W. Irwin wrote: =2E.. > Also, referring to your next post about tcl precision I agree it is > possible that could be the cause of the difference with C and python [t= cl]. Vince and Maurice stated that it does not explain the differences. > But > that cannot explain the python -- C difference (both our double precisi= on). > So my working hypothesis remains the same. Sure. Me too. I did know there was problems in the code. The tcl precisio= n was=20 just another possible route to explain differences. Now the code is OK, and I will commit it soon--after all I missed one poi= nt on=20 it :( But without your prompt attention the bug would probably be left around.=20 Thanks. Joao |
From: Alan W. I. <ir...@be...> - 2002-10-17 01:57:27
|
On Wed, 16 Oct 2002, Joao Cardoso wrote: > Now the code is OK, and I will commit it soon Thanks very much for your efforts to (a) add beautiful features like the new plsurf3d, and (b) respond to my bug reports. Here are my testing results for your updated code. The valgrind report seems fine again. diff of C and python postscript results for example 8 revealed some small differences which I tracked down to extraneous cmap1 changes. Once those were removed the two interfaces produce identical example 8 results again which is an additional confirmation beyond the valgrind report that everything is working correctly. The tcl example 8 result is different from the C and python result. I will look further at that since it may be something simple. Alan |
From: Alan W. I. <ir...@be...> - 2002-10-17 04:17:00
|
On Wed, 16 Oct 2002, Alan W. Irwin wrote: > The tcl example 8 result is different from the C and python result. I > will look further at that since it may be something simple. ifshade==2 was creating some differences, and that was due to a bug in tclAPI.c (clev = NULL rather than *clev = NULL) which I have now fixed. The results of the diff command for various combinations of ifshade range indicate the only remaining differences are for ifshade==5. This is the page that uses contours where Joao created the levels following Vince's suggestion for preserving as much precision as possible for the current 12-digit rounding scheme. Probably the only solution here is to use tcl native double precision (or single precision when appropriate) rather than converting strings to double and back rounded to 12 digits. I am looking forward to Maurice implementing this just so we don't continue to have these minor but still somewhat lame tcl differences compared to every other front end. Joao, I have noticed one final plsurf3d core bug that shows up for all front ends and which detracts from the appearance of the surface contours; those contour lines are sometimes broken (page 6 for example). You comment in the code that the surface contours are simple minded. Does that mean it will be difficult to fix the broken surface contour problem? Alan |
From: <jc...@fe...> - 2002-10-17 17:28:39
|
On Thursday 17 October 2002 05:16, Alan W. Irwin wrote: | On Wed, 16 Oct 2002, Alan W. Irwin wrote: | > The tcl example 8 result is different from the C and python result. | > I will look further at that since it may be something simple. | | ifshade=3D=3D2 was creating some differences, and that was due to a bug | in tclAPI.c (clev =3D NULL rather than *clev =3D NULL) which I have now | fixed. | | The results of the diff command for various combinations of ifshade | range indicate the only remaining differences are for ifshade=3D=3D5. | This is the page that uses contours where Joao created the levels | following Vince's suggestion for preserving as much precision as | possible for the current 12-digit rounding scheme. Probably the only | solution here is to use tcl native double precision (or single | precision when appropriate) rather than converting strings to double | and back rounded to 12 digits. I am looking forward to Maurice | implementing this just so we don't continue to have these minor but | still somewhat lame tcl differences compared to every other front | end. | | Joao, I have noticed one final plsurf3d core bug that shows up for | all front ends and which detracts from the appearance of the surface | contours; those contour lines are sometimes broken (page 6 for | example). I supose you are refering to the contour drawn at the surface, using the=20 rosenbrock function? If you mean the sombrero like function, than try to magnify the broken=20 contour line using the tk driver. The contour is there! If you mean the rosenbrock function, and you mean that some contour=20 lines in the deep valeys are broken, remember that you are watching=20 just the face of the valey that is visible... thus you can only see=20 part of the contour. To make the valeys more visible, you can try to increase the number of=20 points, XPTS and YPTS. I did it and got a core dump!!! One more bug to=20 solve. Joao | You comment in the code that the surface contours are | simple minded. Does that mean it will be difficult to fix the broken | surface contour problem? | | Alan | | | | ------------------------------------------------------- | This sf.net email is sponsored by: viaVerio will pay you up to | $1,000 for every account that you consolidate with us. | http://ad.doubleclick.net/clk;4749864;7604308;v? | http://www.viaverio.com/consolidator/osdn.cfm | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: <jc...@fe...> - 2002-10-17 18:30:27
|
On Thursday 17 October 2002 18:27, Jo=E3o Cardoso wrote: | On Thursday 17 October 2002 05:16, Alan W. Irwin wrote: | | On Wed, 16 Oct 2002, Alan W. Irwin wrote: =2E.. | | Joao, I have noticed one final plsurf3d core bug that shows up for | | all front ends and which detracts from the appearance of the | | surface contours; those contour lines are sometimes broken (page 6 | | for example). | | I supose you are refering to the contour drawn at the surface, using | the rosenbrock function? | | If you mean the sombrero like function, than try to magnify the | broken contour line using the tk driver. The contour is there! | | If you mean the rosenbrock function, and you mean that some contour | lines in the deep valeys are broken, remember that you are watching | just the face of the valey that is visible... thus you can only see | part of the contour. | | To make the valeys more visible, you can try to increase the number | of points, XPTS and YPTS. I did it and got a core dump!!! One more | bug to solve. That was easy. But one can't see better the deep valeys from the top=20 (shouldn't we call them "holes" instead of valleys?). Anyway they are there. Joao | | You comment in the code that the surface contours are | | simple minded. Does that mean it will be difficult to fix the | | broken surface contour problem? As I said , I don't think they are broken. When I said the algorithm was=20 simple minded (and it is, but it does not mean it is not effective), I=20 meant that the contour lines could be jagged, as there is no=20 interpolation nor smoothing done... It is possible to use the information from the countour lines drawn at=20 the base xy plane, but that would make the plot much more lengthy than=20 it already is; I think, I didn't tried it. Joao |
From: Alan W. I. <ir...@be...> - 2002-10-17 19:11:09
|
On Thu, 17 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > As I said , I don't think they are broken. I think you are right. For page 6 of the normal sombrero function (which is what triggered this report initially) some of the upper surface contours do look broken even under tk zoom. But I find entering coordinate ranges by hand a really bad interface to zoom in on a trouble spot so I didn't pursue it perhaps to as high a magnification as I should have. I abandoned that approach and tried gv on the corresponding psc file. At ordinary magnification the upper surface contours look broken, but if you use either anti-aliasing or higher magnification without antialiasing they look okay. Since the psc device gives good results, I conclude there is nothing wrong with the contour drawing in the plsurf3d core. Sorry for the "wild goose chase", but apparently you found and fixed anothe= r bug so at least it wasn't a waste of time. As far as I am concerned your beautiful new features are ready for release. Thanks very much for this effort. Will you please do the honors on the PROBLEMS and NEWS files? Alan |