Re: A shameless plug for string variables

[Juergen W. <wie...@fr...>]

Am Mittwoch, 13. Oktober 2004 19:39 schrieb Ethan Merritt:
> Issues that have been raised regarding the core code (#1043784)
>
> - The pre-defined function sprintf() requires some familiarity
> with C language formats. Harald doesn't like this. I see it as a
> feature, since the documentation is basically "see man page for
> sprintf"

I tried

  gnuplot> print sprintf("%i", 5)
  5
  gnuplot> print sprintf("%i", 5.)
  0
  gnuplot> print sprintf("%f", 5.)
  5.000000
  gnuplot> print sprintf("%f", 5)
  0.000000

Are the second and the fourth example meant not to work?  In this
short example, this would not be a problem; it's simply the fault of
the user.  But is there a way to find out if a variable is an int or
a double/complex (apart from "show var")?  I'd prefer not to have to
trigger what type my variable is -- at least as long as I know it is
numerical.

How difficult would it be to get gnuplot to do casts implicitly?


> - This new code supersedes the current special case hack for
>    formatting labels:
> 	old:    set label "foo %f %f",var1,var2
> 	new:    set label sprintf("foo %f %f",var1,var2)
>    If backwards-compatibilty for this specific case is required,
>    that may be a problem.  Right now the old syntax can cause
>    parsing errors, so I disabled it.
>
> - J=FCrgen Wieferink has pointed out that there may be problems
>   if a user defines a string variable that duplicates a gnuplot
>   keyword:
> 	lt =3D "foo"
> 	plot sin(x) with lines lt 3
>   The intention is that keyword parsing always happens first,
>   and certainly in this simple case it does and there is no
> problem. But it wouldn't surprise me if there are some
> pathological cases. I think we can just fix them as they are
> reported, or tell people "don't redefine 'with' and expect
> anything reasonable to happen".

You're probably right.  I think your idea
        gnuplot> tc =3D "label"
        gnuplot> set label n tc at 1, 1
        warning: ignoring user-defined variable tc=20
                 because it is also a keyword
                             ^
                 textcolor colorspec not recognized
is a good one.


Once more: I really like this patch.  Apart from the minor issues
above, I think it's really a great thing.  Eventually, I'll be able
to use dynamic filenames!  And the design seems to be quite mature.


Juergen