gnuplot-beta — Developers and beta testers of new gnuplot code

Re: user-defined function & string file name

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

Hans-Bernhard Broeker wrote:
> Juergen Wieferink wrote:
> > Enabling strings in this special case would be to define "STRING"
> > and to extend the union within "struct value" by "string_val".  This
> > itself should not lead to additional code in the executable.
>
> That would only be true if we were certain that all usages of the union
> are already fully decoded, i.e. the switch(value.type) all have cases
> for each of the allowed values, and there are no if(value.type == INTGR)
> or similar.  That's not quite true right now, even though we're
> surprisingly close to that goal.

I don't understand this, and I feel really should.  Is there really
a problem with "if (value.type == INTGR)", or would it be the "else"
part that makes problems?

But I have to admit that it is quite inelegant to do what I
proposed.  The function I gave the not completely suitable name
"is_dummy_func()" should also return a "char*", which is NULL if the
expression is to be interpreted as a function.


Juergen

Re: user-defined function & string file name

[Hans-Bernhard B. <br...@ph...>]

Juergen Wieferink wrote:
> Ethan Merritt wrote:

>>By the time you do that, I don't see that you've saved much
>>over just enabling string variables. There's just not that much
>>code involved in handling string variables per se.  Any increase in
>>overall size comes from the addition of built-in string functions
>>like sprintf().

> Enabling strings in this special case would be to define "STRING"
> and to extend the union within "struct value" by "string_val".  This
> itself should not lead to additional code in the executable.

That would only be true if we were certain that all usages of the union 
are already fully decoded, i.e. the switch(value.type) all have cases 
for each of the allowed values, and there are no if(value.type == INTGR)
or similar.  That's not quite true right now, even though we're 
surprisingly close to that goal.

Re: Key layout and exterior X window patches

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:

> But, isn't there some memory in gnuplot options?  That is,
> 
>   set key left
>   set key center
> 
> has an end state of
>   set key left center

It may have that effect.  Or one option may override the default 
specified by another, if it comes after that.   The memory is in the 
internal status variables, not necessarily in the syntax seen by the user.

Re: Replot in epslatex terminal

[James R. V. Z. <jr...@co...>]

Ethan Merritt <merritt@u.washington.edu> wrote:
>My normal mode of generating and viewing png output is
>	set term png
>	set output '| display png;-'
>
>Then I can view the output from successive plot commands interactively
>by hitting <space> in the display window.  If I want to save a particular
>one to disk, then I hit "save" instead.

Nice!  Also non-obvious, I think, so I've checked in the documentation
change below.  Piping to display works for some formats other than PNG
and GIF, but I didn't find any others where <space> shows the next
plot.

	       - Jim Van Zandt

Index: gd.trm
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/term/gd.trm,v
retrieving revision 1.71
diff -r1.71 gd.trm
1919a1920,1928
> " PNG plots may be conveniently viewed by piping the output to the",
> " 'display' program from the ImageMagick package as follows:",
> "                set term png",
> "                set output '| display png:-'",
> "",
> " View the output from successive plot commands interactively by hitting",
> " <space> in the display window.  To save a particular one to disk, left",
> " click in the display window and choose `save`.",
> "",
2243a2253,2261
> " GIF plots may be conveniently viewed by piping the output to the",
> " 'display' program from the ImageMagick package as follows:",
> "                set term gif",
> "                set output '| display gif:-'",
> "",
> " View the output from successive plot commands interactively by hitting",
> " <space> in the display window.  To save a particular one to disk, left",
> " click in the display window and choose `save`.",
> "",

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 30 June 2005 10:03 pm, Daniel J Sebald wrote:
> 
>>How about
>>
>>Syntax:
>>      set key {on|off} {default}
>>              {{inside | tmargin | bmargin | lmargin | rmargin} | {at <position>}}
>>              {left | right | center} {top | bottom | center}
>>
>>where
>>
>>"above" = "tmargin"
>>"below" = "bmargin"
>>"outside" = "rmargin" + "top"
> 
> 
> Looks reasonable.

Oh yeah, "under" = "outside".

Why not take this one step further and cover all bases?  Having corner position influenced by "vert/horiz" may be a nice feature, for those people who don't want to think to much.  How about the slight variation on the above:

Syntax:
      set key {on|off} {default}
              {{inside | outside} | {at <position>}
                | {tmargin | bmargin | lmargin | rmargin}}
              {left | right | center} {top | bottom | center}
              {vertical | horizontal} {Left | Right}
[...]

where

"above" = "tmargin"
"below" = "bmargin"
"below" without left/right appearing on line = "bmargin" + "center"
"under" = "below"
"outside" without left/right = "rmargin" (can use top/bottom/center
  for positioning)
"outside" with left/right determines corner positions based
  upon "vertical/horizontal"
 
The groupings of {inside|outside} {at } and {tmargin|bmargin...} are very natural, I think.  Backward compatibility is maintained.  There is a slight
problem that

set key left
set key outside

or

set key right
set key below

might not work as expected, but I think that is minor.

Sorry for having gone around in circles here a bit.  [I think all I've done is propose adding {tmargin|bmargin|...}.]  I'll create a version with the above syntax tomorrow.

Dan

Re: user-defined function & string file name

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

Ethan Merritt wrote:
> On Thursday 30 June 2005 03:49 am, Juergen Wieferink wrote:
> > This is possible without evaluating anything twice.  The major
> > drawback is that this doesn't work well with GP_STRING_VARS being
> > optional.  [Could STRINGs be allowed without GP_STRING_VARS for this
> > special case?]
>
> Yes, but that isn't sufficient.  The expression evaluation
> code would have to be modified so that const_express() will
> do something reasonable if the next token on the command line
> is a string literal.

Of course.  But this is quite trivial.  Should probably be done in a
wrapper, though.

> By the time you do that, I don't see that you've saved much
> over just enabling string variables. There's just not that much
> code involved in handling string variables per se.  Any increase in
> overall size comes from the addition of built-in string functions
> like sprintf().

Enabling strings in this special case would be to define "STRING"
and to extend the union within "struct value" by "string_val".  This
itself should not lead to additional code in the executable.
"value.v.string_val" would be used only within the wrapper and at
the calling sites.

> I don't see much down-side to permanently enabling string variables.

Fine.

I'll prepare a small patch this or next weekend to show more in
detail what I mean.  The main work will have to wait for a few
weeks.


Juergen

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> 
>>    c) A variation on b that might have more obvious
>>       meaning?
> 
> 
> I may have a syntax solution here.  If you think "vert/horiz" shouldn't 
> have influence on placement, how about:
> 
> Syntax:
>       set key {on|off} {default}
>               {{inside | margin | above | below} | {at <position>}}
>               {left | right | center} {top | bottom | center}

Ehh... the above may be a confusing dud as well.  Now that I think about it,

"right margin top"

would be equivalent to

"top margin right"

and top margin is a concept that will cause confusion as being equal to "above".

How about

Syntax:
      set key {on|off} {default}
              {{inside | tmargin | bmargin | lmargin | rmargin} | {at <position>}}
              {left | right | center} {top | bottom | center}

where

"above" = "tmargin"
"below" = "bmargin"
"outside" = "rmargin" + "top"

?

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Thursday 30 June 2005 06:24 pm, Daniel J Sebald wrote:
>>
>>1)  Should there be that flexibility?
> 
> 
> I don't think so.  If you want to put the key in strange places, 
> you still have the manual placement mode.

OK.  I've posed a different scheme in another email.  I'm completely flexible, but I just worry a bit that vert/horiz having influence on position is a lingering confusion users will never get used to, and fixing syntax after the fact is not good...  It's up to the list.

Dan

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
>    c) A variation on b that might have more obvious
>       meaning?

I may have a syntax solution here.  If you think "vert/horiz" shouldn't have influence on placement, how about:

 Syntax:
       set key {on|off} {default}
               {{inside | margin | above | below} | {at <position>}}
               {left | right | center} {top | bottom | center}
[...]

WITH the backward compatible "outside" meaning the same as "right margin"?  I like this idea.

If one says "inside", then left/right/center/top/bottom can pick out positions  as represented pictorially as

1 2 3
4 5 6
7 8 9

Now the tricky part, the outside positions.  As I said, there are twelve; pictorially:

   10 11 12
21          13
20          14
19          15
   18 17 16

We can choose these positions as follows:

"above" combined with left/center/right:  10 11 12
"right margin" combined with top/center/bottom:  13 14 15
"below" combined with right/center/left:  16 17 18
"left margin" combined with bottom/center/top: 19 20 21

I know the documentation would suggest typing "margin right", but if users want to think more naturally as "right margin", fine.

Aside from the errors inherent in the syntax brace placement, the following will give warnings:

"above" combined with top/bottom
"below" combined with top/bottom

You'll notice that in the current scheme, "outside" is position number (unlucky) 13, i.e., the right margin.

Dan

Re: Key layout and exterior X window patches

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 30 June 2005 06:24 pm, Daniel J Sebald wrote:
> You'll see that one can't (without manual placement) have a vertical
> element key under and to the left or right.  I assumed no one would want
> to do such a thing because it wastes space.  (The same holds for putting
> a horizontal element key to the side of a plot.)  But who knows? 
> Perhaps there is a non-obvious reason to want to do that.
>
> 1)  Should there be that flexibility?

I don't think so.  If you want to put the key in strange places, 
you still have the manual placement mode.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I overlooked that.  Yes, "under" alone should be centered.
>=20
>=20
> Yes.
>=20
>> Should "under" by a synonym for "outside bottom center", or just=20
>> "outside bottom" so that "under left" is valid?
>=20
>=20
> Both ;-)
>=20
> I.e. both "below" and "below left" should be valid, with the former=20
> being equivalent to "below center".

But, isn't there some memory in gnuplot options?  That is,

   set key left
   set key center

has an end state of=20

   set key left center

not

   set key below center

It may not be apparent what the issue is until attempting to use this.

>=20
>> Should I add a series of conflicting keyword error messages?  E.g.,=20
>> should "under inside" complain or simply override the "outside"=20
>> inherent in "under"?
>=20
>=20
> An error might be too harsh.  An int_warn() should do.

OK.  Basically the same code.  No problem.

Dan

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> I think this is almost ready for inclusion,

OK, one last question; a real specific one.  Basically, do people think there is enough control of key placement for "outside", or should there be slightly more independent control?

That is, in the case of "inside" there are 9 positions for placement, regardless of vertical or horizontal key elements.  On the other hand, in the case of "outside" there are 12 positions for placement.  Have a look at demo plots 3 and 4 of 

http://acer-access.com/~ds...@ac.../gnuplot/key.pdf

You'll see that one can't (without manual placement) have a vertical element key under and to the left or right.  I assumed no one would want to do such a thing because it wastes space.  (The same holds for putting a horizontal element key to the side of a plot.)  But who knows?  Perhaps there is a non-obvious reason to want to do that.

1)  Should there be that flexibility?

2)  If so, what is a good syntax for achieving that?  (Note that this means "vert|horiz" no longer have any influence on placement.)

    a) Order of options?  That is, "outside left top" is
       different from "outside top left"?

    b) Add a third option for {above|below|side}?  Then,
       for example "outside above right" and
       "outside side right top" can pinpoint placement.

    c) A variation on b that might have more obvious
       meaning?

Dan

Re: Key layout and exterior X window patches

[<br...@ph...>]

Daniel J Sebald wrote:

> I overlooked that.  Yes, "under" alone should be centered.

Yes.

> Should "under" by a synonym for "outside bottom center", or just 
> "outside bottom" so that "under left" is valid?

Both ;-)

I.e. both "below" and "below left" should be valid, with the former 
being equivalent to "below center".

> Should I add a series of conflicting keyword error messages?  E.g., 
> should "under inside" complain or simply override the "outside" inherent 
> in "under"?

An error might be too harsh.  An int_warn() should do.

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> I think this is almost ready for inclusion, barring some extraneous
> messages from time-travellers like the one below:

:)  I'll take that out.  It can always be gotten from CVS.

> The only other glitch I notice is that the default placement of 
> "set key below" seems to have changed from "below center" to
> "below right". E.g.
> 	set key below
> 	plot sin(x)
> now places the key at the bottom right corner of the page, rather
> than centering it under the plot.  Please fix that, because I'm
> sure this will be triggered by a *lot* of existing scripts.

I overlooked that.  Yes, "under" alone should be centered.

Should "under" by a synonym for "outside bottom center", or just "outside bottom" so that "under left" is valid?

Should I add a series of conflicting keyword error messages?  E.g., should "under inside" complain or simply override the "outside" inherent in "under"?

Dan

Re: user-defined function & string file name

[Ethan M. <merritt@u.washington.edu>]

On Thursday 30 June 2005 03:49 am, Juergen Wieferink wrote:
> This is possible without evaluating anything twice.  The major
> drawback is that this doesn't work well with GP_STRING_VARS being
> optional.  [Could STRINGs be allowed without GP_STRING_VARS for this
> special case?]

Yes, but that isn't sufficient.  The expression evaluation 
code would have to be modified so that const_express() will
do something reasonable if the next token on the command line
is a string literal.

By the time you do that, I don't see that you've saved much
over just enabling string variables. There's just not that much
code involved in handling string variables per se.  Any increase in
overall size comes from the addition of built-in string functions
like sprintf().

I don't see much down-side to permanently enabling string variables.
There have been no reports of string variables breaking existing
scripts or usage.  There are some desireable un-implemented
features, like the current discussion about using string-valued
functions as arguments "plot/splot/fit". But other than that the
feedback has been to point out places where the older test
isstring() should be replaced by the new, more general, code.
So far this has usually simplified the call site, rather than
complicating it. It's just kind of tedious inspecting and
revising the remaining 50+ instances of isstring() one by one.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Key layout and exterior X window patches

[Ethan M. <merritt@u.washington.edu>]

I think this is almost ready for inclusion, barring some extraneous
messages from time-travellers like the one below:

+#if 0 /* 29jul2005 Seems like outdated cruft.  Keybox computations are done later. */
+           /* we divide into columns, then centre in column by
+            * considering ratio of * key_left_size to
+            * key_right_size
+            *
+            * key_size_left/(key_size_left+key_size_right) *
+            * (xright-xleft)/key_cols do one integer division to
+            * maximise accuracy (hope we don't overflow !)
+            */
+           keybox.xl = xleft - key_size_left
+               + ((xright - xleft) * key_size_left)
+               / (key_cols * (key_size_left + key_size_right));
+           keybox.xr = keybox.xl + key_col_wth * (key_cols - 1)
+               + key_size_left + key_size_right;
+           keybox.yb = t->ymax * yoffset;
+           keybox.yt = keybox.yb + key_rows * key_entry_height
+               + ktitl_lines * t->v_char;
+           keybox.yt += (int) (key->height_fix * t->v_char);
+#endif

The only other glitch I notice is that the default placement of 
"set key below" seems to have changed from "below center" to
"below right". E.g.
	set key below
	plot sin(x)
now places the key at the bottom right corner of the page, rather
than centering it under the plot.  Please fix that, because I'm
sure this will be triggered by a *lot* of existing scripts.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: user-defined function & string file name

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

Hans-Bernhard Br=F6ker wrote:
> > Consider that the following is a legal function definition:
> >
> > f(plot,x) =3D  (plot =3D=3D 0) ? sin(x) : sprintf("datafile.%d",plot)
>
> I think it shouldn't be.  It's an invitation for utter confusion to
> reign in users' heads.  If it's any help: even C, in all its
> carelessness for types, forbids the two expressions surrounding the : of
> a ternay expression being of incompatible type.
>
> We really have to take a decision here:  either we have a typing system,
> or we go the Perl way, which would imply a need for type-punning
> functions or hacks like ''.<expressio> to work around unexpectedly wrong
> types.
>
> > The only alternative I see to trial evaluation is to add an
> > infrastructure for type-checking and type-propagation to the
> > temp_at() code, and use it to reject any function definition that
> > propagates both string and non-string types to the top of the
> > evaluation tree.

This is especially the case for "f(x)=3Dx?a:b" or even "f(x)=3Dx" and
"f(x)=3Da".  As long as variables don't need to be declared, we are
stuck to the "perl way", I fear.

It may be possible to mimic execute_at() to obtain the resulting
type without actually executing the action table.  This is quite a
lot of work and not very elegant.

> Exactly my point.
>
> > At worst you end up evaluating a non-string expression twice, once to
> > find out it's not a string and a second time to store the numerical
> > result instead.
>
> And if that expression has side-effects (like the recently proposed
> system(<string>) or rand()), this is "at worst" can indeed be quite
> bad.
>
>  > If this is seen as a serious inefficiency, then at
> >
> > critical call sites the code in try_to_get_string could be replicated
> >  in-line, keeping the returned value for immediate use in either the
> > string or non-string case.
>
> In-line expansion wouldn't be needed.  A simple ptr argument where
> try_to_get_string() can store the result of its attempted evaluation
> would be quite enough --- it may have to be renamed then, though, to
> evaluate_expression_of_as_yet_unknown_type() or something like that :-)

Am I right on this:

If the next token on the command line is either a key word [or any
other token with a special meaning like '('], or it is an
expression.  In the latter case, numerical and string values are
often treated in a different way.  But either way, the expression
has to be evaluated.  I am aware of the three exceptions "plot",
"splot" and "fit".  Well, and possibly a function definition.  :-)
And the cases where STRING_RESULT_ONLY is used, but in these cases,
a numerical value at that point is illegal.=20

I'd say, the conditional should generally be done after
const_express().  The expression is needed anyhow.  Only the three
dummyexpression/filename cases (s?plot|fit) need to be treated
slightly different.

This is possible without evaluating anything twice.  The major
drawback is that this doesn't work well with GP_STRING_VARS being
optional.  [Could STRINGs be allowed without GP_STRING_VARS for this
special case?]


Juergen

Re: help exit

[<br...@ph...>]

Daniel J Sebald wrote:

> It sounds as though this patch should be put on SourceForge for further 
> consideration.

Either that, or put it into CVS right away --- and let the users tell us 
how they like it.  Experience so far has been that we will get 
essentially zero feedback for patches until they are in CVS, and full 
feedback only after the eventual release.

Re: Key layout and exterior X window patches

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 29 June 2005 10:01 pm, Daniel J Sebald wrote:
\>
>  Syntax:
>        set label {<tag>} {"<label text>"} {at <position>}
>
> Either way is fine with me.  Which do list members prefer?

Document it as requiring "at", but for backwards-compatibility
it must also accept the old syntax.

> > cd tutorial; make clean; make
> >
> > set key 15,-10
> >         ^
> > "eg3.plt", line 7: unknown key option
>
> Oh yeah, I see... eg6.plt (tutorial.tex), bivariat.dem and electron.dem
> also have this.  I will fix these if the list thinks "at" should be
> required.

Yes, if the new syntax requires "at" then the tutorial and the demos
should use it.  But changing the demos will not magically change people's
existing scripts, so the code still must accept the at-less form also.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: help exit

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>> Then you didn't look in the right place.  Here's the end of "help fit"
>> in a .gih-based version, as an example:
>>
>> Subtopics available for fit:
>>    adjustable_parameters               beginners_guide   control
>>    error             error_estimate    errors            guide
>>    multi-branch      parameters        starting_values   tips
>>
>> Subtopic for fit:  <input cursor here>
>>
>> If you type "tips" here, it'll put you to the same node otherwise 
>> reached by "help fit tips".
> 
> 
> Yes, but this table is for few items, and it appers on the button, as an 
> inherent part of the particular help text. This cannot be considered as 
> a common header what Daniel has proposed.

It sounds as though this patch should be put on SourceForge for further consideration.

Dan

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 29 June 2005 02:42 am, Daniel J Sebald wrote:
> 
>>And with that, I think now is as good a time as any to consider the key layout patch
> 
> 
> Looks basically OK.  I'm fine with it.
> But there are some compile-time warnings,

Aee, I keep forgetting to turn on warnings.  Can we turn warnings on by default?  :)

 and at least part of
> the original syntax seems to have broken:  set key <position>

Well, this is what Petr suggested the other day, i.e., that it should be

set key at <position>

His point was that the position alone didn't give enough indication that it in fact meant position; whereas "at" inherently suggests position.  Furthermore, "at" is consistent with

 Syntax:
       set label {<tag>} {"<label text>"} {at <position>}

Either way is fine with me.  Which do list members prefer?

> 
> 
> graphics.c:1108: warning: unused variable `keybox_half_height'
> graphics.c:1109: warning: unused variable `keybox_half_width'
> save.c:321: warning: enumeration value `CENTRE' not handled in switch
> save.c:329: warning: enumeration value `JUST_CENTRE' not handled in switch

I'll fix those.

> 
> cd tutorial; make clean; make
> 
> set key 15,-10
>         ^
> "eg3.plt", line 7: unknown key option

Oh yeah, I see... eg6.plt (tutorial.tex), bivariat.dem and electron.dem also have this.  I will fix these if the list thinks "at" should be required.

Dan

Re: user-defined function & string file name

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 29 June 2005 04:49 pm, Hans-Bernhard Br=F6ker wrote:
> In-line expansion wouldn't be needed.  A simple ptr argument where
> try_to_get_string() can store the result of its attempted evaluation
> would be quite enough --- it may have to be renamed then, though, to
> evaluate_expression_of_as_yet_unknown_type() or something like that :-)

We have such a function now. Its name is const_express().
try_to_get_string() is a just wrapper that allows it to work even
if you configure without support for string variables.  Using
const_express() directly and checking the returned value is exactly
what I meant by "in-line expansion".  So I think we are both on=20
the same page.

[and yes, I've always wondered why it was called const_express(),
 rather than evaluate_expression or the like]=20


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: user-defined function & string file name

[<br...@ph...>]

> Consider that the following is a legal function definition:
> 
> f(plot,x) =  (plot == 0) ? sin(x) : sprintf("datafile.%d",plot)

I think it shouldn't be.  It's an invitation for utter confusion to
reign in users' heads.  If it's any help: even C, in all its
carelessness for types, forbids the two expressions surrounding the : of
a ternay expression being of incompatible type.

We really have to take a decision here:  either we have a typing system,
or we go the Perl way, which would imply a need for type-punning
functions or hacks like ''.<expressio> to work around unexpectedly wrong
types.

> The only alternative I see to trial evaluation is to add an 
> infrastructure for type-checking and type-propagation to the 
> temp_at() code, and use it to reject any function definition that 
> propagates both string and non-string types to the top of the 
> evaluation tree.

Exactly my point.

> At worst you end up evaluating a non-string expression twice, once to
> find out it's not a string and a second time to store the numerical 
> result instead.  

And if that expression has side-effects (like the recently proposed 
system(<string>) or rand()), this is "at worst" can indeed be quite
bad.

 > If this is seen as a serious inefficiency, then at
> critical call sites the code in try_to_get_string could be replicated
>  in-line, keeping the returned value for immediate use in either the 
> string or non-string case.

In-line expansion wouldn't be needed.  A simple ptr argument where 
try_to_get_string() can store the result of its attempted evaluation 
would be quite enough --- it may have to be renamed then, though, to 
evaluate_expression_of_as_yet_unknown_type() or something like that :-)

Re: Key layout and exterior X window patches

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 29 June 2005 02:42 am, Daniel J Sebald wrote:
> And with that, I think now is as good a time as any to consider the key layout patch

Looks basically OK.  I'm fine with it.
But there are some compile-time warnings, and at least part of
the original syntax seems to have broken:  set key <position>


graphics.c:1108: warning: unused variable `keybox_half_height'
graphics.c:1109: warning: unused variable `keybox_half_width'
save.c:321: warning: enumeration value `CENTRE' not handled in switch
save.c:329: warning: enumeration value `JUST_CENTRE' not handled in switch

cd tutorial; make clean; make

set key 15,-10
        ^
"eg3.plt", line 7: unknown key option



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: user-defined function & string file name

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 29 June 2005 05:10 am, Hans-Bernhard Br=F6ker wrote:
> Juergen Wieferink wrote:
>=20
>  > Such a function must not be called if the next token can be a key word=
=2E=20
>  > An invalid expression would lead to an int_error().=20
>=20
> This, however, seems deeply wrong.  A simple parsing helper function has=
=20
> no business bailing out to the command line.

This is a false concern.  int_error() will not happen, because it is=20
trivial to check whether the next token is a user-defined function or not.
The missing part is to how to check the return type of that udf.

Consider that the following is a legal function definition:

	f(plot,x) =3D  (plot =3D=3D 0) ? sin(x) : sprintf("datafile.%d",plot) =20

So `plot f(0,x), f(1,x)` should be equivalent to
   plot sin(x), "datafile.1"

The only alternative I see to trial evaluation is to add an infrastructure
for type-checking and type-propagation to the temp_at() code, and use it=20
to reject any function definition that propagates both string and non-string
types to the top of the evaluation tree.=20

I hasten to point out that so far as I know, the only place this is a real
issue is for the arguments to the `plot`, `splot`, and `fit` commands.
In all other cases it is safe to call try_to_get_string(), and then test
whether a string was actually returned or not.  At worst you end up
evaluating a non-string expression twice, once to find out it's not a=20
string and a second time to store the numerical result instead.  If this
is seen as a serious inefficiency, then at critical call sites the
code in try_to_get_string could be replicated in-line, keeping the
returned value for immediate use in either the string or non-string case.


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195