plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] valgrind warning generated by this line, why?

[Alan W. I. <ir...@be...>]

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

Re: [Plplot-devel] valgrind warning generated by this line, why?

[Alan W. I. <ir...@be...>]

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

Re: [Plplot-devel] valgrind warning generated by this line, why?

[Joao C. <jc...@fe...>]

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

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Joao C. <jc...@fe...>]

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

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Joao C. <jc...@fe...>]

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

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Maurice L. <mj...@ga...>]

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)

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Vince D. <vi...@sa...>]

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>

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Maurice L. <mj...@ga...>]

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)

Re: [Plplot-devel] valgrind warning generated by this line, why?

[Alan W. I. <ir...@be...>]

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

Re: [Plplot-devel] valgrind warning generated by this line, why?

[Alan W. I. <ir...@be...>]

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

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Joao C. <jc...@fe...>]

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

Re: [Plplot-devel] valgrind warning generated by this line, why?

[Joao C. <jc...@fe...>]

On Tuesday 15 October 2002 22:43, Alan W. Irwin wrote:
> I have just been checking Joao's recent change using valgrind.  The onl=
y
> *PLplot* memory management problem that it finds now is
>
> =3D=3D9658=3D=3D Use of uninitialised value of size 8
> =3D=3D9658=3D=3D    at 0x4025DECC: plP_draw3d (plot3d.c:1451)
> =3D=3D9658=3D=3D    by 0x4025DD7A: plnxtvhi_draw (plot3d.c:1400)
> =3D=3D9658=3D=3D    by 0x4025D968: plnxtvhi (plot3d.c:1244)
> =3D=3D9822=3D=3D    by 0x4025D7D9: plnxtv (plot3d.c:1174)
> =3D=3D9822=3D=3D    by 0x4025C40E: plt3zz (plot3d.c:947)
> =3D=3D9822=3D=3D    by 0x4025BAFC: c_plot3d (plot3d.c:729)
> =3D=3D9822=3D=3D    by 0x40259611: c_plmesh (plot3d.c:100)
> =3D=3D9822=3D=3D    by 0x8049046: main (x08c.c:176)
>
> Line 1451 of plot3d.c is
>
> if (c !=3D NULL && c[--j] >=3D 0. && c[j] <=3D 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=20
plP_draw3d() is called.
The problem is to "find" the correct value "j" to pass to plP_draw3d(), a=
s=20
both plnxtvhi_draw() and plnxtvlo() are complex, dealing with hidden line=
=20
removal and maintaining two closely coupled indexes.
c[] by itself is correctly initialized in  plt3zz() and contains the ampl=
itude=20
values of the (redimensioned) "z" matrix.

The original=20
   if (c !=3D NULL && c[j] >=3D 0. && c[j] <=3D 1.)
visually failed because, as you say above, sometimes c[j] contains garbag=
e, as=20
"j" goes after the end of the "c" array.
The "--j" version does not fails visually, as it uses initialized values =
of =20
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] >=3D 0. && c[j] <=3D 1." you would underst=
and that=20
I was aware of some possible problems, else I wouldn't check for it...

Anyway, there are several ways to color each line segment that makes up t=
he=20
mesh. Currently, I use the color of the end point. But this makes two lin=
e=20
segments that make a "V" have different colors: the lower arm, "\" is col=
ored=20
with the color of the lower end point, which is different of the color of=
 the=20
upper end point of the "/" arm; this makes the "V" have two different col=
ors,=20
which is odd -- this effect can be observed in the pronounced minimums of=
 the=20
rosenbrock function.
The mean color of each arm only works if the arms are of equal length, wh=
ich=20
is not guaranteed.

Well, work in progress... is in progress..

Joao

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Maurice L. <mj...@ga...>]

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)

Re: Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[Alan W. I. <ir...@be...>]

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

[Plplot-devel] valgrind warning generated by this line, why?

[Alan W. I. <ir...@be...>]

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?

There continue to be large diffs between the postscript files produced by
./x08c -dev psc -o x08c.ps
../test/test_single_tcl.sh 08
../test/test_single_python.sh 08

Note the uninitialized value could be anything for the various front ends
and indeed could change depending on the history of the memory that is
malloced for c. Thus, my working hypothesis is this uninitialized value is
the source of the C, tcl, and python example 8 differences.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Tcl precision [was: Re: [Plplot-devel] Java changes to support plsurf3d()]

[<jc...@fe...>]

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

Re: [Plplot-devel] Java changes to support plsurf3d()

[Alan W. I. <ir...@be...>]

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

Re: [Plplot-devel] Moving Octave demos directory to examples/octave

[Maurice L. <mj...@ga...>]

Jo=E3o Cardoso writes:
 > I need to move files around without losing revision history
 > ...
 > Can anyone with the rihgt rights please do it?
 > I want to move
 >=20
 >     bindings/octave/misc
 > and
 >     bindings/octave/demos
 >=20
 > to a new directory,
 >    examples/octave/
 >=20
 > so it will look like this:
 >    examples/octave/demos/
 >    examples/octave/misc/

AFAIK we don't have direct access to the cvs repository.  It can be don=
e
nevertheless, but is a chore.  The procedure I followed before was:
 - check out the CVSROOT dir, using the standard plplot $CVSROOT settin=
g.
 - modify the script used for sending out the log messages (mfpipe.pl) =
to do
it.  Best to test it using an existing local cvs repository, else you c=
ould
really screw things up.
 - check in mfpipe.pl
 - make a dummy commit to trigger the action
 - see if it worked
 - revert the changes to mfpipe.pl and commit it again

Have fun. :)

--=20
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (=
RIST)

Re: [Plplot-devel] Java changes to support plsurf3d()

[<jc...@fe...>]

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

Re: [Plplot-devel] Java changes to support plsurf3d()

[Alan W. I. <ir...@be...>]

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

Re: [Plplot-devel] My e-mail retrieval is down until further notice

[Alan W. I. <ir...@be...>]

OK.  I can receive e-mail again.  Our sysadmin is the best!

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] My e-mail retrieval is down until further notice

[Alan W. I. <ir...@be...>]

The astrogroup's sysadmin just told me he is dealing with a crash of a new
60GB HD that was the heart (NIS server, plus many user's home directories,
wouldn't you know) of our whole system of Linux PC's so that nobody will be
able to retrieve their e-mail (or do anything else) for a while.

However, I fortunately don't use that system much other than to retrieve my
e-mail so I can still continue to do my usual research on my home Linux PC
as well as send e-mail from there....;-)

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] Moving Octave demos directory to examples/octave

[<jc...@fe...>]

Hi,

For a long time the Octave demos (and misc) directories are an exception=20
to the PLplot tree, so I decided to move them to a new examples/octave=20
directory.
This imply cvs manipulation that I'm not allowed to do, I think, so I=20
ask your kind cooperation.

=46rom the "cvs book",=20
http://cvsbook.red-bean.com/cvsbook.html#I_need_to_move_files_around_with=
out_losing_revision_history
the following recipe is given:

I need to move files around without losing revision history

In the repository, copy (don't move) the RCS files to the desired new=20
location in the project. They must remain in their old locations as=20
well. Then, in a working copy, do:

floss$ rm oldfile1 oldfile2 ...
floss$ cvs remove oldfile1 oldfile2 ...
floss$ cvs commit -m =81=D2removed from here=81=D3 oldfile1 oldfile2 ...

When people do updates after that, CVS correctly removes the old files=20
and brings the new files into the working copies just as though they=20
had been added to the repository in the usual way (except that they'll=20
be at unusually high revision numbers for supposedly new files).=20

Can anyone with the rihgt rights please do it?
I want to move

    bindings/octave/misc
and
    bindings/octave/demos

to a new directory,
   examples/octave/

so it will look like this:
   examples/octave/demos/
   examples/octave/misc/

After the changes, I will edit the build/install configuration files=20
accordingly.

Thanks,
Joao

[Plplot-devel] Java changes to support plsurf3d()

[<jc...@fe...>]

Hi,

I have commited changes to javabind.c, PLStream.java and x08.java to=20
implement and show the new plsurf3d() API.

There are still problems! I *don't* know java, so someone (Maurice?)=20
must revise/correct my changes!

I will not make changes to python. Can someone please made the necessary=20
changes? I will make the necessary changes to Octave later.

Thanks,
Joao

Re: [Plplot-devel] Prescriptions for running tkdemos.tcl under wish and tcldemos.tcl under tclsh

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Sat, 12 Oct 2002, Joao Cardoso wrote:
 > 
 > > The tk driver does not work if PL_LIBRARY is not set to "." in the tmp build
 > > directory:
 > >
 > > ~/plplot/tmp> ./plserver
 > > (*AppInit) failed: can't read "pllibrary": no such variable
 > > ~/plplot/tmp> export PL_LIBRARY=.
 > > ~/plplot/tmp> ./plserver
 > > OK
 > 
 > I confirm this, but only in the case when plplot is not installed.  Thus, I
 > guess plserver is always attempting to access the installed version of the
 > library rather than the plplot/tmp one.

It was a bug in the newly revamped search logic, fixed now.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)