From: Alan W. I. <ir...@be...> - 2002-10-15 01:23:15
|
On Mon, 14 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > > I will not make changes to python. Can someone please made the necessary > changes? OK, you aroused my curiosity, I wanted to encourage all the neat stuff you have been doing, and I also needed a quick break from my research in any case....;-) I just completed the python changes. The easy part was the API change usin= g swig. The tough part was tracking down the remaining inconsistencies between the C, tcl, and python examples 8. In both the C and python examples, the second plot (ifshade =3D=3D 1 which = uses the new plmesh) has a blue edge that should not be there. The tcl example = 8 does not have this problem. Other non-visual differences between the examples also show up for ifshade =3D=3D 5. All other ifshade values have = no differences. I suspected some memory management problem in the underlying plmesh code fo= r the ifshade =3D=3D 1 differences and sure enough valgrind ./x08c -dev xwin does show a lot of problems, e.g., Conditional jump or move depends on uninitialised value(s) Use of uninitialised value of size 8 which were not there before the last time I ran valgrind on example 8. Joao, could you follow up on this please? There is a nice mode in valgrind to leap right to a gdb session whenever a memory management problem occurs which saves an awful lot of gdb session time executing all the correct part= s of the code until the error is reached. The gdb hook from valgrind only works if you use the -g compile option (which you can get with the --with-debug option to ./configure). The -g option also allows valgrind to put line numbers in its output. The last time I used valgrind this way it only took me about 10 minutes to track down the problem, but I am leaving i= t to you (please), because again I am out of time, and not at all familiar with your recent code changes. Alan |
From: <jc...@fe...> - 2002-10-15 09:10:16
|
On Tuesday 15 October 2002 02:23, Alan W. Irwin wrote: | On Mon, 14 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > I will not make changes to python. Can someone please made the | > necessary changes? | | OK, you aroused my curiosity, I wanted to encourage all the neat | stuff you have been doing, and I also needed a quick break from my | research in any case....;-) | | I just completed the python changes. The easy part was the API | change using swig. The tough part was tracking down the remaining | inconsistencies between the C, tcl, and python examples 8. | | In both the C and python examples, the second plot (ifshade =3D=3D 1 | which uses the new plmesh) has a blue edge that should not be there.=20 | The tcl example 8 does not have this problem. So it must be a tcl problem :-)! I also noticed it but I have no clue on what is causing it. | Other non-visual | differences between the examples also show up for ifshade =3D=3D 5. What differences? | All | other ifshade values have no differences. | | I suspected some memory management problem in the underlying plmesh | code for the ifshade =3D=3D 1 differences and sure enough | | valgrind ./x08c -dev xwin | | does show a lot of problems, e.g., | | Conditional jump or move depends on uninitialised value(s) | Use of uninitialised value of size 8 | | which were not there before the last time I ran valgrind on example | 8. | | Joao, could you follow up on this please? OK, I will try to correct the problems as soon as I can. Joao | There is a nice mode in | valgrind to leap right to a gdb session whenever a memory management | problem occurs which saves an awful lot of gdb session time executing | all the correct parts of the code until the error is reached. The | gdb hook from valgrind only works if you use the -g compile option | (which you can get with the --with-debug option to ./configure). The | -g option also allows valgrind to put line numbers in its output.=20 | The last time I used valgrind this way it only took me about 10 | minutes to track down the problem, but I am leaving it to you | (please), because again I am out of time, and not at all familiar | with your recent code changes. | | Alan | | | | ------------------------------------------------------- | This sf.net email is sponsored by:ThinkGeek | Welcome to geek heaven. | http://thinkgeek.com/sf | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2002-10-15 15:22:41
|
On Tue, 15 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Tuesday 15 October 2002 02:23, Alan W. Irwin wrote: > | Other non-visual > | differences between the examples also show up for ifshade =3D=3D 5. > > What differences? They show up with the diff command on a psc files written with tcl, C, and python front ends, but (unlike the ifshade=3D=3D1 results where you see a b= lue edge for Python and C and no blue edge for tcl) I cannot spot anything visually. Once all the recently introduced memory management problems shown by valgrind are fixed, then I expect that running diff between the example 8 results for the various front ends should show no differences. Alan |
From: <jc...@fe...> - 2002-10-15 19:18:37
|
On Tuesday 15 October 2002 16:22, Alan W. Irwin wrote: | On Tue, 15 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Tuesday 15 October 2002 02:23, Alan W. Irwin wrote: | > | Other non-visual | > | differences between the examples also show up for ifshade =3D=3D 5. | > | > What differences? | | They show up with the diff command on a psc files written with tcl, | C, and python front ends, but (unlike the ifshade=3D=3D1 results where | you see a blue edge for Python and C and no blue edge for tcl) I | cannot spot anything visually. Hi, I don't' want to interrupt you now, but I might forget the subject. Tcl store values as strings, and there is some loss of precision with=20 this process. This issue has already been discussed in this list, but=20 unfortunately the mailing list archiver at sf.net does not have a=20 search facility to found the thread. As a matter of fact, x08.tcl already has a numeric problem, that I have=20 "fixed" by adding a small constant -- it is documented in the code. | Once all the recently introduced memory management problems shown by | valgrind are fixed, Well, I have identified the problem, and "hacked" plot3d.c in order to=20 correct it -- it is an index problem. But the problem is not really=20 solved, it is only not apparent visually :( Joao |
From: Alan W. I. <ir...@be...> - 2002-10-15 21:59:49
|
On Tue, 15 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > On Tuesday 15 October 2002 16:22, Alan W. Irwin wrote: > | On Tue, 15 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > | > On Tuesday 15 October 2002 02:23, Alan W. Irwin wrote: > | > | Other non-visual > | > | differences between the examples also show up for ifshade =3D=3D 5. > | > > | > What differences? > | > | They show up with the diff command on a psc files written with tcl, > | C, and python front ends, but (unlike the ifshade=3D=3D1 results where > | you see a blue edge for Python and C and no blue edge for tcl) I > | cannot spot anything visually. > > Hi, > > I don't' want to interrupt you now, but I might forget the subject. I don't mind short interruptions at all because they provide a welcome break. It is just I cannot afford to spend a long time at anything to do with PLplot at the moment. > > Tcl store values as strings, and there is some loss of precision with > this process. This issue has already been discussed in this list, but > unfortunately the mailing list archiver at sf.net does not have a > search facility to found the thread. > As a matter of fact, x08.tcl already has a numeric problem, that I have > "fixed" by adding a small constant -- it is documented in the code. As I recall the result of that thread, Maurice implemented something like 1= 2 (or 13?) significant digits as a stop-gap measure to the tcl precision problems. There was some reason why he did not want to increase the precision to 17 digits. In any case, he had a better solution in mind, which I don't think has been implemented yet. > > | Once all the recently introduced memory management problems shown by > | valgrind are fixed, > > Well, I have identified the problem, and "hacked" plot3d.c in order to > correct it -- it is an index problem. But the problem is not really > solved, it is only not apparent visually :( I checked again with valgrind (see my previous post), and there is an uninitialized variable in plot3d that is very likely the source of the remaining example 8 differences between the various front ends. I believe this uninitialized variable is recently introduced because I did not spot this problem when I ran valgrind extensively on example 8 right after Gary Bishop fixed the egregious example 8 bug that had been plaguing us for such a long time. Alan |
From: Maurice L. <mj...@ga...> - 2002-10-15 22:08:08
|
Alan W. Irwin writes: > As I recall the result of that thread, Maurice implemented something like 12 > (or 13?) significant digits as a stop-gap measure to the tcl precision > problems. There was some reason why he did not want to increase the > precision to 17 digits. In any case, he had a better solution in mind, > which I don't think has been implemented yet. Correct, not implmented yet (it will be a while). BTW here is my original commentary on the problem: | The story becomes more interesting. I believe the two representations | (variable or tclMatrix) would've given the same result in pre-Tcl8.0. The | reason being that in the old Tcl, "everything's a string". But no longer -- | the variable that you create with "set" is "dual-ported", meaning it has both | a binary and string representation. The binary one is used in expression | evaluations and so is more accurate. | | I've been poring over the documentation, and I think it's feasible to change | tclMatrix to emit objects instead of strings, which seems to be the right way | to really fix this. Also will help a lot with performance. The object is | equipped with procedure calls to convert it to strings when necessary. | Unfortunately this is a pretty major undertaking, and not one I care to get | into right now. | | So as for a stopgap measure, I'll change it to carry 12 digits of precision, | both internally and externally. I tried 17 but didn't like the result. E.g. | | pltcl> matrix c f 3 = {3.2 4.5 5.7} | c | pltcl> puts [c *] | 3.2000000000000002 4.5 5.7000000000000002 | | which the tclvars man page warns about. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Joao C. <jc...@fe...> - 2002-10-16 00:57:10
|
On Tuesday 15 October 2002 23:07, Maurice LeBrun wrote: > Alan W. Irwin writes: > > As I recall the result of that thread, Maurice implemented something > > like 12 (or 13?) significant digits as a stop-gap measure to the tcl > > precision problems. There was some reason why he did not want to > > increase the precision to 17 digits. In any case, he had a better > > solution in mind, which I don't think has been implemented yet. > > Correct, not implmented yet (it will be a while). BTW here is my origi= nal > > commentary on the problem: > | The story becomes more interesting. I believe the two representation= s > | (variable or tclMatrix) would've given the same result in pre-Tcl8.0.= =20 > | The reason being that in the old Tcl, "everything's a string". But n= o > | longer -- the variable that you create with "set" is "dual-ported", > | meaning it has both a binary and string representation. The binary o= ne > | is used in expression evaluations and so is more accurate. But this means that it is single precision, doesn't it? Tcl is build with= =20 floats or doubles? So, if the default is float, as I supose, we shouldn't= =20 compare plots made with the tcl front-ends with plots made from frontends= =20 compiled with doubles. It is not the device driver that matters, but the=20 origin of the data -- floats in, say, x08.tcl with doubles in x08c. And I= =20 think to remember from Alan's e-mail (that I dont have at the moment) tha= t he=20 was using plplot compiled with doubles. > | > | I've been poring over the documentation, and I think it's feasible to > | change tclMatrix to emit objects instead of strings, which seems to b= e > | the right way to really fix this. Also will help a lot with performa= nce. > | The object is equipped with procedure calls to convert it to strings > | when necessary. Unfortunately this is a pretty major undertaking, and= not > | one I care to get into right now. > | > | So as for a stopgap measure, I'll change it to carry 12 digits of > | precision, both internally and externally. I tried 17 but didn't lik= e > | the result. E.g. > | > | pltcl> matrix c f 3 =3D {3.2 4.5 5.7} > | c > | pltcl> puts [c *] > | 3.2000000000000002 4.5 5.7000000000000002 > | > | which the tclvars man page warns about. OK. So I think that the source of some problems are the x??.tcl examples=20 themselfs. E.g., when I do: set zmin [z min [ expr $xpts * $ypts]] set zmax [z max [ expr $xpts * $ypts]] set nlev 10 matrix clev f $nlev set step [expr ($zmax-$zmin)/$nlev] for {set i 0} {$i < $nlev} {incr i} { =09# odd, there seems to be some floating point problems here, I have to =09# add a small number, else I get the runtime error: =09# "plcol1: Invalid color map position: -0.000000, aborting operation" =09# humm, I remember to see something about tcl precision -- numbers are= stored =09# as strings with a small default precision? =09clev $i =3D [expr $zmin + $i * $step + 0.000001] } I'm using 12 bits of precision, according to you. I can't compare it with= the=20 C version using either floats or doubles. floats are perhaps closer. Joao |
From: Maurice L. <mj...@ga...> - 2002-10-16 03:03:21
|
Joao Cardoso writes: > On Tuesday 15 October 2002 23:07, Maurice LeBrun wrote: > > | The story becomes more interesting. I believe the two representations > > | (variable or tclMatrix) would've given the same result in pre-Tcl8.0. > > | The reason being that in the old Tcl, "everything's a string". But no > > | longer -- the variable that you create with "set" is "dual-ported", > > | meaning it has both a binary and string representation. The binary one > > | is used in expression evaluations and so is more accurate. > > But this means that it is single precision, doesn't it? Tcl is build with > floats or doubles? So, if the default is float, as I supose, we shouldn't > compare plots made with the tcl front-ends with plots made from frontends > compiled with doubles. It is not the device driver that matters, but the > origin of the data -- floats in, say, x08.tcl with doubles in x08c. And I > think to remember from Alan's e-mail (that I dont have at the moment) that he > was using plplot compiled with doubles. Tcl uses double internally. But the precision when printing them out defaults to 12. From the tclvars man page: tcl_precision This variable controls the number of digits to generate when | converting floating-point values to strings. It defaults to | 12. 17 digits is ``perfect'' for IEEE floating-point in that | it allows double-precision values to be converted to strings | and back to binary with no loss of information. However, | using 17 digits prevents any rounding, which produces longer, | less intuitive results. For example, expr 1.4 returns | 1.3999999999999999 with tcl_precision set to 17, vs. 1.4 if | tcl_precision is 12. | -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Joao C. <jc...@fe...> - 2002-10-16 22:20:37
|
On Wednesday 16 October 2002 04:02, Maurice LeBrun wrote: > Joao Cardoso writes: > > On Tuesday 15 October 2002 23:07, Maurice LeBrun wrote: > > > | The story becomes more interesting. I believe the two > > > | representations (variable or tclMatrix) would've given the same > > > | result in pre-Tcl8.0. The reason being that in the old Tcl, > > > | "everything's a string". But no longer -- the variable that you > > > | create with "set" is "dual-ported", meaning it has both a binary= and > > > | string representation. The binary one is used in expression > > > | evaluations and so is more accurate. > > > > But this means that it is single precision, doesn't it? Tcl is build > > with floats or doubles? So, if the default is float, as I supose, we > > shouldn't compare plots made with the tcl front-ends with plots made > > from frontends compiled with doubles. It is not the device driver th= at > > matters, but the origin of the data -- floats in, say, x08.tcl with > > doubles in x08c. And I think to remember from Alan's e-mail (that I = dont > > have at the moment) that he was using plplot compiled with doubles. > > Tcl uses double internally. But the precision when printing them out > defaults to 12. Thanks. Joao |
From: Vince D. <vi...@sa...> - 2002-10-16 07:52:02
|
In general, this: [expr $zmin + $i * $step + 0.000001] should be: [expr {$zmin + $i * $step + 0.000001}] to gain advantage of the internal representations (this is for rather technical reasons I won't go into here), and this may help your problem with -0.0000 As for the 'floats or doubles' question, Tcl is a full programming language and contains internal support for ints, longs, floats, doubles, and even long longs. Note: somewhere in the old 'tea' branch there may be some code which helps to turn tclMatrix.c into what Maurice wanted. Really the whole plplot TclAPI should be changed to use the Tcl_Obj based methods... cheers, -- Vince <http://www.santafe.edu/~vince> |
From: Maurice L. <mj...@ga...> - 2002-10-16 08:41:38
|
Vince Darley writes: > Note: somewhere in the old 'tea' branch there may be some code which helps > to turn tclMatrix.c into what Maurice wanted. Really the whole plplot > TclAPI should be changed to use the Tcl_Obj based methods... Thanks for the info, when I get the time (ha ha) I'll take a look and see where I can go from there. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Joao C. <jc...@fe...> - 2002-10-16 22:20:37
|
On Wednesday 16 October 2002 08:51, Vince Darley wrote: > In general, this: > > [expr $zmin + $i * $step + 0.000001] > > should be: > > [expr {$zmin + $i * $step + 0.000001}] > > to gain advantage of the internal representations (this is for rather > technical reasons I won't go into here), and this may help your problem > with -0.0000 Thanks, it did. > > As for the 'floats or doubles' question, Tcl is a full programming > language and contains internal support for ints, longs, floats, doubles= , > and even long longs. Sure, I was speaking how numbers are internaly stored. Maurice said they = are=20 as doubles. Thanks, Joao |