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