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

Re: Trouble with contours and binary arrays

[Ethan A M. <me...@uw...>]

On Monday, 16 May 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
[snip]
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface

I was focused on explaining why normal using specifiers don't work for
binary array data.

What I didn't think to point out was that for the specific case of a
constant offset, as in your example, you don't need a using specifier:

  splot "sincos.float32" binary array=(90,100) format="%float" origin=(0,0,100) with lines 

	Ethan

Re: Trouble with contours and binary arrays

[Ethan A M. <me...@uw...>]

On Monday, 16 May 2022 15:39:25 PDT Dima Kogμan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image


[snip]


> Second issue. I'd like to plot boxed contour labels. This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?


This second issue is a simple bug.  The default number of input columns is taken as 2
(z value + label text) but for contour labels there is no separate second input column.
You can work around this by giving an explicit "using <foo>" in the splot command:

   splot "sincos.float32" binary array=(90,100) format="%float" using ("foo") with labels boxed nosurface

That gets you auto-generated labels that correspond to the input binary z values.
As before, however, those values are taken as-is.
You still cannot modify the z values via a using specifier.

	Ethan

Re: Trouble with contours and binary arrays

[Ethan A M. <me...@uw...>]

(apologies if you see this twice)

On Monday, 16 Mμay 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image
> 
> I can also transform the data and plot:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image


Image data is treated as a special case, so keep that in mind as we continue through this.


> This all works. Without the transform, I can also plot contours:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't
> work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface
> 
> There's no error message. It just produces the untransformed data.


Let's simplify by  just plotting the surface rather than contouring.
We find that
*     splot "sincos.float32" binary array=(90,100) format="%float" with lines*
works as expected.


However
*     splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100)*
seemingly ignores the using spec.  This is the same thing you ran into with contouring.


Why?  
The handling of binary array/matrix data is really weird.  
I hate it, but what happens is this:


1) The program uses the "binary array=(x,y)" clause to fill in the x and y coordinates


2) The program uses the plot type to fill in the z coordinate directly from the data
    provided by the format specifier "%float".


Now it gets weird


3) The program advances the count of data columns consumed by 2 ("plot") or 3 ("splot").


4) Only now does the program look at the using specifier.  But since it advanced the 
    column count in step (3), the column numbers in the using spec are now off by either
    2 or 3 depending on whether it's a "plot" or "splot" command.   
    This means that the operation ($1+100) is actually used to stuff data value 4
     rather than data value 1 (which is x) or z (which was stuffed in data value 3).


5) If there are additional using specs, they are used for data values 5, 6, ... and so on.


The upshot is that the using specifiers _can_ affect the plot, but not as x/y/z coordinates.
For instance you could do:


*    splot "sincos.float32" binary array=(90,100) format="%float" using ($1*$1) lc variable*


The x/y/z coordinates of the surface will be exactly the same as before.
However the variable color is taken from data value 4 so the using spec can now be seen
to have an actual effect.


Where does that leave us?
If we were designing the binary input code starting now, I would argue for
doing it very differently.  But redesign of the existing commands would completely
break backwards compatibility so I don't think that's an option.
Introducing a new binary input syntax in parallel while keeping the old 
one sounds just as unattractive.  So I am at a loss how to improve things.


The image handling code also plays fast and loose with the data columns,
although that is a separate code path.  It is not currently possible, for example,
to make a 3D histogram plot of the Green component of a color image.
Exactly analogous to your matrix contouring case, you cannot re-assign the
x/y/z coordinates based on image pixel values.


> Second issue. I'd like to plot boxed contour labels. 


I have not looked at this one yet.
It may or may not come down to the same thing.


    Ethan


> This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?
> 
> Thanks!
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Trouble with contours and binary arrays

[Ethan M. <eam...@gm...>]

On Monday, 16 Mμay 2022 15:39:25 PDT Dima Kogan wrote:
> Hi. I'm having trouble with contoured plots, and I'm guessing there's at
> least one gnuplot bug here. Can I please get some pointers?
> 
> I make a binary data file. This is an regular matrix of 32-bit floats:
> 
>   perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32
> 
> For convenience I'm attaching this data.
> 
> I can successfully plot a heatmap:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with image
> 
> I can also transform the data and plot:
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image

Image data is treated as a special case, so keep that in mind as we continue through this.

> This all works. Without the transform, I can also plot contours:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface
> 
> But if I add the transform, it is ignored by the contours. THIS doesn't
> work:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface
> 
> There's no error message. It just produces the untransformed data.

Let's simplify by  just plotting the surface rather than contouring.
We find that
*     splot "sincos.float32" binary array=(90,100) format="%float" with lines*
works as expected.

However
*     splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100)*
seemingly ignores the using spec.  This is the same thing you ran into with contouring.

Why?  
The handling of binary array/matrix data is really weird.  
I hate it, but what happens is this:

1) The program uses the "binary array=(x,y)" clause to fill in the x and y coordinates

2) The program uses the plot type to fill in the z coordinate directly from the data
    provided by the format specifier "%float".

Now it gets weird

3) The program advances the count of data columns consumed by 2 ("plot") or 3 ("splot").

4) Only now does the program look at the using specifier.  But since it advanced the 
    column count in step (3), the column numbers in the using spec are now off by either
    2 or 3 depending on whether it's a "plot" or "splot" command.   
    This means that the operation ($1+100) is actually used to stuff data value 4
     rather than data value 1 (which is x) or z (which was stuffed in data value 3).

5) If there are additional using specs, they are used for data values 5, 6, ... and so on.

The upshot is that the using specifiers _can_ affect the plot, but not as x/y/z coordinates.
For instance you could do:

*    splot "sincos.float32" binary array=(90,100) format="%float" using ($1*$1) lc variable*

The x/y/z coordinates of the surface will be exactly the same as before.
However the variable color is taken from data value 4 so the using spec can now be seen
to have an actual effect.

Where does that leave us?
If we were designing the binary input code starting now, I would argue for
doing it very differently.  But redesign of the existing commands would completely
break backwards compatibility so I don't think that's an option.
Introducing a new binary input syntax in parallel while keeping the old 
one sounds just as unattractive.  So I am at a loss how to improve things.

The image handling code also plays fast and loose with the data columns,
although that is a separate code path.  It is not currently possible, for example,
to make a 3D histogram plot of the Green component of a color image.
Exactly analogous to your matrix contouring case, you cannot re-assign the
x/y/z coordinates based on image pixel values.


> Second issue. I'd like to plot boxed contour labels. 

I have not looked at this one yet.
It may or may not come down to the same thing.

	Ethan

> This works OK with
> ASCII matrix data, but with binary data it doesn't work. I run this
> gunplot script:
> 
>   set view map
>   set contour base
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
> 
> And I see this:
> 
>   "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)
> 
>   splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
>                                                                                           ^
>   "cmd" line 3: All points x value undefined
> 
> For whatever reason it's trying to read 8 bytes per point instead of 4.
> Some brief debugging tells me it thinks there're two values to read from
> each point, when in reality there's just one.
> 
> Thoughts?
> 
> Thanks!
> 
> 

Trouble with contours and binary arrays

[Dima K. <gn...@di...>]

Hi. I'm having trouble with contoured plots, and I'm guessing there's at
least one gnuplot bug here. Can I please get some pointers?

I make a binary data file. This is an regular matrix of 32-bit floats:

  perl -E 'for $i (0..99) { for $j (0..89) { $f=sin($i/30.)+cos($j/5.); print pack("f",$f); }}' > /tmp/sincos.float32

For convenience I'm attaching this data.

I can successfully plot a heatmap:

  splot "sincos.float32" binary array=(90,100) format="%float" with image

I can also transform the data and plot:

  splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with image

This all works. Without the transform, I can also plot contours:

  set view map
  set contour base
  splot "sincos.float32" binary array=(90,100) format="%float" with lines nosurface

But if I add the transform, it is ignored by the contours. THIS doesn't
work:

  set view map
  set contour base
  splot "sincos.float32" binary array=(90,100) format="%float" using ($1+100) with lines nosurface

There's no error message. It just produces the untransformed data.



Second issue. I'd like to plot boxed contour labels. This works OK with
ASCII matrix data, but with binary data it doesn't work. I run this
gunplot script:

  set view map
  set contour base
  splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface

And I see this:

  "cmd" line 3: warning: Couldn't slurp 72000 bytes (return was 36000)

  splot "sincos.float32" binary array=(90,100) format="%float" with labels boxed nosurface
                                                                                          ^
  "cmd" line 3: All points x value undefined

For whatever reason it's trying to read 8 bytes per point instead of 4.
Some brief debugging tells me it thinks there're two values to read from
each point, when in reality there's just one.

Thoughts?

Thanks!

Re: Weirdness in column specifications, column() vs dollar

[Juhász P. <pet...@gm...>]

On Thu, 2022-03-10 at 20:42 -0800, Ethan A Merritt wrote:
> On Friday, 4 March 2022 00:17:15 PST Ethan A Merritt wrote:
> 
> > I dislike the idea of going back to either the original behaviour
> > (always skip input line if a column is NaN or missing) or the
> > version 5.2
> > behaviour (see Bug #2042).  
> > 
> > You have now pointed out the very real bug that one cannot use 
> > valid(N) in an expression containing $N because the entire
> > expression
> > will be skipped.
> > So I dislike the way it is now, also.
> > 
> > Possible options:
> > 
> > - Revert commit b8304eaf.  That would re-introduce Bug #2042 but
> > would
> >   allow use of valid() to avoid it.
> > 
> > - Better documentation. Trying to explain all this is probably much
> > too
> >   difficult, but we could at least warn that if you use valid(N)
> > then
> >   you must also use column(N) rather than $N.
> > 
> > - At the cost of some hackery, I could add a check for the valid()
> > function
> >   itself immediately before the check for $N added by the commit
> > shown above.
> >   The logic would be "if we see the user is doing their own
> > validity checks,
> >   we will not use the known-imperfect check that looks for $
> > signs".
> >   I could cook up a patch for that if you want to test it.
> 
> Eventually I realized that the valid() function goes all the way back
> to gnuplot version 3.something, and it always had the property that
> it couldn't catch "missing" values because they were discarded at an
> earlier stage of the input.
> 
> I have come around to thinking that the only major issue here
> is the one that Peter originally pointed out: that $N and column(N)
> are documented as being identical but they were not.
> 
> So commit c8d468de adds the same initial check to column(N) that
> already exists for $N.  In both cases if column N contains a 
> missing value flag then the data point is skipped prior to
> evaluation of the expression in the "using" specifier.
> So you cannot in practice catch such points by using 
>     valid(N) ? $N : <foo>

I still think that this behavior is hostile to the user - at least it's
consistently hostile now, I guess.

Maybe I'm overreacting, and for most use cases this is the sensible and
expected behavior. What prompted me to send in the original report is
that in my application the missing column was used deep inside a
sprintf for  a hypertext label, only visible on mouseover, and for the
longest time I couldn't understand why such an inconsequential part of
the using spec was causing part of the input to be silently dropped.

Anyway, thanks for looking into this.

best regards,
Peter Juhasz

Re: Weirdness in column specifications, column() vs dollar

[Ethan A M. <me...@uw...>]

On Friday, 4 March 2022 00:17:15 PST Ethan A Merritt wrote:

> I dislike the idea of going back to either the original behaviour
> (always skip input line if a column is NaN or missing) or the version 5.2
> behaviour (see Bug #2042).  
> 
> You have now pointed out the very real bug that one cannot use 
> valid(N) in an expression containing $N because the entire expression
> will be skipped.
> So I dislike the way it is now, also.
> 
> Possible options:
> 
> - Revert commit b8304eaf.  That would re-introduce Bug #2042 but would
>   allow use of valid() to avoid it.
> 
> - Better documentation. Trying to explain all this is probably much too
>   difficult, but we could at least warn that if you use valid(N) then
>   you must also use column(N) rather than $N.
> 
> - At the cost of some hackery, I could add a check for the valid() function
>   itself immediately before the check for $N added by the commit shown above.
>   The logic would be "if we see the user is doing their own validity checks,
>   we will not use the known-imperfect check that looks for $ signs".
>   I could cook up a patch for that if you want to test it.

Eventually I realized that the valid() function goes all the way back
to gnuplot version 3.something, and it always had the property that
it couldn't catch "missing" values because they were discarded at an
earlier stage of the input.

I have come around to thinking that the only major issue here
is the one that Peter originally pointed out: that $N and column(N)
are documented as being identical but they were not.

So commit c8d468de adds the same initial check to column(N) that
already exists for $N.  In both cases if column N contains a 
missing value flag then the data point is skipped prior to
evaluation of the expression in the "using" specifier.
So you cannot in practice catch such points by using 
    valid(N) ? $N : <foo>

There is a secondary issue as pointed out earlier in this thread
that if the "missing" column is referenced only indirectly then
the pre-evaluation check doesn't catch it.  I.e.
    N = 2
    filter(i) = (valid(i) ? column(i) : 0)
    plot FOO using 1:(filter(N))

This is way too complex for the parser to recognize that column 2
is special prior to evaluation (filter(N)), so in this case the
valid(i) test would do something.  But given that it would not do
anything on the less convoluted cases it would probably be a bad
idea to use it in a script.   Better to disable any "missing"
flag and then use "set datafile missing NaN" instead.

The same commit c8d468de replaces the internal handling of this
case to make it (I hope) more robust.

	Ethan

 









> 
> - Your notion of setting a default value for missing data is interesting.
>   I don't know quite where that would go.  A uniform default could be
>   done by something like
> 	set datafile missing "?" default FOO
>   But that is probably too global to be useful. You might want different
>   defaults for different columns and for different intput files.
> 
> 	still thinking
> 
> 		Ethan
> 
> On Thursday, 3 March 2022 14:41:50 PST Juhász Péter wrote:
> > On Wed, 2022-03-02 at 14:36 -0800, Ethan A Merritt wrote:
> > > On Wednesday, 2 March 2022 06:37:26 PST Peter Juhasz wrote:
> > > > On Wed, Mar 2, 2022 at 5:22 AM Ethan A Merritt <me...@uw...>
> > > > wrote:
> > > > 
> > > > > > Observations:
> > > > > > - it's as if the mere presence of a $X in the specification
> > > > > > causes the
> > > > > > datum to be marked as invalid, and dropped entirely, if column
> > > > > > X
> > > > > > doesn't contain data, no matter what the rest of the
> > > > > > specification is.
> > > 
> > > This is intentional.
> > > 
> > [... detailed explanation snipped ...]
> > 
> > This all sounds eminently horrible. I admit I never had to think into
> > the various edge cases like `column($2)` and so on, but even
> > acknowledging these, it seems to me that peeking ahead in the
> > expression and just throwing away the datum if a column happens to be
> > empty/invalid is an overly zealous, and in the end, suboptimal,
> > approach, because it throws away that datum even if the invalid value
> > ends up not influencing the result.
> > 
> > If I understand you correctly, my use case (plotting a dataset with a
> > potentially null column with a default value, so that a point is
> > plotted for every row) is supposed to be impossible, and the method
> > I've eventually stumbled on (`valid(N) ? column(N) : 0`) only works
> > because of an implementation detail (that peeking ahead for `column()`
> > was deemed too hard).
> > 
> > And even accepting all this, the fact remains that there is an
> > undocumented discrepancy in the user interface (`column(N)` vs `$N`
> > behaves differently, even though the documentation states that the
> > latter is just a shortcut to the former), and that all of this is not
> > easily discoverable and confusing to the user.
> > 
> > > 
> > > Any suggestions for improvement are welcome.
> > 
> > To try to be constructive:
> > 
> > - the state of affairs should be documented somewhere (though I'm not
> > sure under which keyword does it belong)
> > 
> > - perhaps there could be a separate, explicit function for plotting a
> > column with a default value. My subconcious is trying to suggest a
> > defined-or operator like perl's `//`, but I realise that that would not
> > help much with the problems that already exist on the level of
> > expression parsing. But perhaps a two-argument alternative to
> > `column(X)` could be added, one that allows a default value to be
> > specified, e.g. `defaultcolumn(1, 3.14)`, or just make `column` accept
> > an optional second argument, like `timecolumn` does.
> > 
> > I'm not sure how much value this second proposal would add, though,
> > since the `valid ? column : default` syntax does work, but perhaps a
> > separate explicit function would be useful if `column` was ever "fixed"
> > to behave like the dollar operator.
> > 
> > 
> > > 
> > >    cheers,
> > >            Ethan
> > > 
> > > 
> > 
> > best regards,
> > Peter Juhasz
> > 
> > 
> > 
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Weirdness in column specifications, column() vs dollar

[Jeremy N. - ml g. <jn....@wi...>]

On 2022-03-04 08:17, Ethan A Merritt wrote:

> Possible options:

> - Your notion of setting a default value for missing data is 
> interesting.
>   I don't know quite where that would go.  A uniform default could be
>   done by something like
> 	set datafile missing "?" default FOO
>   But that is probably too global to be useful. You might want 
> different
>   defaults for different columns and for different intput files.

There must come a point where it's not sensible to try to make gnuplot
cope with data that's not in a wholely-valid consistent format.

I'd say it'd be better for people whose data has missing elements to use
some sort of scripting language to fix the data, the way they want it to
look, before passing it to gnuplot.

-- 
Jeremy Nicoll - my opinions are my own

Re: Weirdness in column specifications, column() vs dollar

[Ethan A M. <me...@uw...>]

I think, or hope anyway, that discussion will lead to at least
a partial solution going forward.

More history follows.  Skip down to the TL;DNR line if you like.

    Going back at least as far as gnuplot version 3.7.1
there is a mechanism using "set datafile missing <foo>" to
flag data points that should be ignored during input.
As originally implemented this mechanism worked as intended
for commands of the form
	plot FOO using 1:2

But in those days the program rejected any input that evaluated
to NaN (not-a-number). Some time in version 5.2 gnuplot gained the
flexibility to return all requested columns to the user even if
one of them contained NaN. For instance NaN in the color field of
palette-color or image data can be handled as "don't draw this pixel",
but dropping the pixel from the input stream altogether would
mess up the image raster.

Unfortunately this led to an new class of errors.
Basically if the using spec contains an expression that can't
handle NaN then *not* skipping that input line is bad also.
See Bug #2042.

In commit b8304eaf I tried to handle this case also
(so feel free to blame me for ensuing complications).
Here is the commit message:
>   skip evaluation of using spec expression that depends on a missing value
>     
>   The presence of a "missing" flag in an input data field is easy to detect
>   if it is encountered in place of a bare number ('using N'), but if it is
>   encountered during evaluation of an expression ('using (func($N))') then the
>   function evaluation may exit via int_error() before the missing value can be
>   flagged for the calling code.  Now we pre-screen expressions in a using spec
>   for the presence of "$N" and note the dependence on column N in a new field
>   use_spec.depends_on_column.  During data input, if this field is non-zero
>   the content can be checked for a missing value flag before trying to
>   evaluate the expression is was found in.
>   Bug #2042

This first appeared in version 5.4.0
No one at the time raised the issue of the breaking the valid(N) function.
That was clearly something we missed.

TL;DNR   

I dislike the idea of going back to either the original behaviour
(always skip input line if a column is NaN or missing) or the version 5.2
behaviour (see Bug #2042).  

You have now pointed out the very real bug that one cannot use 
valid(N) in an expression containing $N because the entire expression
will be skipped.
So I dislike the way it is now, also.

Possible options:

- Revert commit b8304eaf.  That would re-introduce Bug #2042 but would
  allow use of valid() to avoid it.

- Better documentation. Trying to explain all this is probably much too
  difficult, but we could at least warn that if you use valid(N) then
  you must also use column(N) rather than $N.

- At the cost of some hackery, I could add a check for the valid() function
  itself immediately before the check for $N added by the commit shown above.
  The logic would be "if we see the user is doing their own validity checks,
  we will not use the known-imperfect check that looks for $ signs".
  I could cook up a patch for that if you want to test it.

- Your notion of setting a default value for missing data is interesting.
  I don't know quite where that would go.  A uniform default could be
  done by something like
	set datafile missing "?" default FOO
  But that is probably too global to be useful. You might want different
  defaults for different columns and for different intput files.

	still thinking

		Ethan

On Thursday, 3 March 2022 14:41:50 PST Juhász Péter wrote:
> On Wed, 2022-03-02 at 14:36 -0800, Ethan A Merritt wrote:
> > On Wednesday, 2 March 2022 06:37:26 PST Peter Juhasz wrote:
> > > On Wed, Mar 2, 2022 at 5:22 AM Ethan A Merritt <me...@uw...>
> > > wrote:
> > > 
> > > > > Observations:
> > > > > - it's as if the mere presence of a $X in the specification
> > > > > causes the
> > > > > datum to be marked as invalid, and dropped entirely, if column
> > > > > X
> > > > > doesn't contain data, no matter what the rest of the
> > > > > specification is.
> > 
> > This is intentional.
> > 
> [... detailed explanation snipped ...]
> 
> This all sounds eminently horrible. I admit I never had to think into
> the various edge cases like `column($2)` and so on, but even
> acknowledging these, it seems to me that peeking ahead in the
> expression and just throwing away the datum if a column happens to be
> empty/invalid is an overly zealous, and in the end, suboptimal,
> approach, because it throws away that datum even if the invalid value
> ends up not influencing the result.
> 
> If I understand you correctly, my use case (plotting a dataset with a
> potentially null column with a default value, so that a point is
> plotted for every row) is supposed to be impossible, and the method
> I've eventually stumbled on (`valid(N) ? column(N) : 0`) only works
> because of an implementation detail (that peeking ahead for `column()`
> was deemed too hard).
> 
> And even accepting all this, the fact remains that there is an
> undocumented discrepancy in the user interface (`column(N)` vs `$N`
> behaves differently, even though the documentation states that the
> latter is just a shortcut to the former), and that all of this is not
> easily discoverable and confusing to the user.
> 
> > 
> > Any suggestions for improvement are welcome.
> 
> To try to be constructive:
> 
> - the state of affairs should be documented somewhere (though I'm not
> sure under which keyword does it belong)
> 
> - perhaps there could be a separate, explicit function for plotting a
> column with a default value. My subconcious is trying to suggest a
> defined-or operator like perl's `//`, but I realise that that would not
> help much with the problems that already exist on the level of
> expression parsing. But perhaps a two-argument alternative to
> `column(X)` could be added, one that allows a default value to be
> specified, e.g. `defaultcolumn(1, 3.14)`, or just make `column` accept
> an optional second argument, like `timecolumn` does.
> 
> I'm not sure how much value this second proposal would add, though,
> since the `valid ? column : default` syntax does work, but perhaps a
> separate explicit function would be useful if `column` was ever "fixed"
> to behave like the dollar operator.
> 
> 
> > 
> >    cheers,
> >            Ethan
> > 
> > 
> 
> best regards,
> Peter Juhasz
> 
> 
> 


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Weirdness in column specifications, column() vs dollar

[Juhász P. <pet...@gm...>]

On Wed, 2022-03-02 at 14:36 -0800, Ethan A Merritt wrote:
> On Wednesday, 2 March 2022 06:37:26 PST Peter Juhasz wrote:
> > On Wed, Mar 2, 2022 at 5:22 AM Ethan A Merritt <me...@uw...>
> > wrote:
> > 
> > > > Observations:
> > > > - it's as if the mere presence of a $X in the specification
> > > > causes the
> > > > datum to be marked as invalid, and dropped entirely, if column
> > > > X
> > > > doesn't contain data, no matter what the rest of the
> > > > specification is.
> 
> This is intentional.
> 
[... detailed explanation snipped ...]

This all sounds eminently horrible. I admit I never had to think into
the various edge cases like `column($2)` and so on, but even
acknowledging these, it seems to me that peeking ahead in the
expression and just throwing away the datum if a column happens to be
empty/invalid is an overly zealous, and in the end, suboptimal,
approach, because it throws away that datum even if the invalid value
ends up not influencing the result.

If I understand you correctly, my use case (plotting a dataset with a
potentially null column with a default value, so that a point is
plotted for every row) is supposed to be impossible, and the method
I've eventually stumbled on (`valid(N) ? column(N) : 0`) only works
because of an implementation detail (that peeking ahead for `column()`
was deemed too hard).

And even accepting all this, the fact remains that there is an
undocumented discrepancy in the user interface (`column(N)` vs `$N`
behaves differently, even though the documentation states that the
latter is just a shortcut to the former), and that all of this is not
easily discoverable and confusing to the user.

> 
> Any suggestions for improvement are welcome.

To try to be constructive:

- the state of affairs should be documented somewhere (though I'm not
sure under which keyword does it belong)

- perhaps there could be a separate, explicit function for plotting a
column with a default value. My subconcious is trying to suggest a
defined-or operator like perl's `//`, but I realise that that would not
help much with the problems that already exist on the level of
expression parsing. But perhaps a two-argument alternative to
`column(X)` could be added, one that allows a default value to be
specified, e.g. `defaultcolumn(1, 3.14)`, or just make `column` accept
an optional second argument, like `timecolumn` does.

I'm not sure how much value this second proposal would add, though,
since the `valid ? column : default` syntax does work, but perhaps a
separate explicit function would be useful if `column` was ever "fixed"
to behave like the dollar operator.


> 
>    cheers,
>            Ethan
> 
> 

best regards,
Peter Juhasz

Re: Weirdness in column specifications, column() vs dollar

[Ethan A M. <me...@uw...>]

On Wednesday, 2 March 2022 06:37:26 PST Peter Juhasz wrote:
> On Wed, Mar 2, 2022 at 5:22 AM Ethan A Merritt <me...@uw...> wrote:
> 
> > > Observations:
> > > - it's as if the mere presence of a $X in the specification causes the
> > > datum to be marked as invalid, and dropped entirely, if column X
> > > doesn't contain data, no matter what the rest of the specification is.

This is intentional.
It may not be ideal but so far as I can see a better solution 
would be unreasonably difficult.

Here's what is going on.

$DATA << EOD
1 1
2 ? 
3 3
EOD

First consider
  set datafile missing "?"
  plot FOO using 1:2 with points

The intent is to cleanly skip any lines where the value is "missing",
and it is easy for the program to see that it should check column 2
for a missing value when data is being read in.

Now let's make it a bit more complicated
  plot FOO using 1:(1./($1+$2))

The intent is again to skip any lines where the value is "missing".
But now the program has to evaluate an expression to generate that
value.  Evaluating the expression first and then testing against
"missing" cannot work and in fact the evaluation may blow up on
divide-by-zero. So the input code tries to peek into the expression
and see if any column values are needed in order to evaluate it,
and  if so whether those column values are actually present.
This is really hard to do in general, but detecting "$<number>" in
the expression is easy and that is a common case.  So in the
example here it can still easily detect that both columns 1 and 2 are
needed for evaluation and it checks whether either of them is missing.

Can't we do the same for column(N)?  Not really. Perhaps for
the very simple case "column(2)" but anything beyond that
totally falls apart.
Consider:
  plot for [i=1:N] FOO using 1:(column(i))

The evaluation table on input looks like this
gnuplot> show at (column(i))
        push i
        column
We could detect the "column" function, but then what?
What is i?  Is it missing?
And that's not the worst! An example that comes up from time to
time in user queries is how to do what amounts to

  plot FOO using 1:(F(column($1)))

Now it depends not only on column 1 (which yes we can detect easily)
but also on some function of column whatever-column-1-points-to.
I.e. if column 1 is missing we know to skip the line,
but if column 1 contains "7" and column 7 is missing. Will F() blow up?
The only thing saving us is that if it does blow up, that probably
ends up with NaN as the y value, and we can check for that separately.
"set datafile missing NaN" tries to do this behind the scenese.

That leaves us with several problems.

(1) It is easy to detect $<column> without actually evaluating
    and expression.  So we do that and if it's missing, skip that line.

(2) It is hard to detect indirect references to a column so that its
    status could be checked before trying to evaluate an expression
    it appears in.

(3) The function valid() trips over problem (1)
    If your expression includes "valid($2)" then the pre-check will
    notice that evaluation requires column 2 and if it's missing the
    evaluation (including invocation of valid()) never happens.

Any suggestions for improvement are welcome.

   cheers,
           Ethan

Re: Weirdness in column specifications, column() vs dollar

[Peter J. <pet...@gm...>]

On Wed, Mar 2, 2022 at 5:22 AM Ethan A Merritt <me...@uw...> wrote:

> On Tuesday, 1 March 2022 10:48:41 PST Juhász Péter wrote:
> > Dear gnuplot list members,
> >
> > today I tried to modify a plot so that it applies a default value if
> > one of the columns was empty, and for the longest time I couldn't
> > understand why it didn't work. I managed to make it work in the end,
> > but I still don't understand it. There are strange differences in
> > behavior, depending on whether `column(x)` or `$x` is used, and it even
> > depends on the datafile separator. I've distilled the issues I've found
> > into the following minimal example:
>
> I will explain what I can, but I may not be noticing what it is
> that you are calling strange.
>
> 1) Difference between whitespace and csv files.
>    There is only one instance of this, right? and it shows what happens
>    when there is only one number on the line of data.
>    This is a real difference and I think the reason is clear.
>    In a csv file you can count field separators and know for certain
>    that if there are N separators there are N+1 fields.
>    If fields are separated only by whitespace you cannot distinguish
>    between a field that is present, but empty, from a field that is
>    missing altogether.  The former is handled by whatever is in place
>    to catch zero or missing data entries, the latter is considered an
>    error that invalidates the entire line.  You might think that marking
>    the entire line invalid because the 2nd of two numbers is blank is
>    excessive, but what if there were supposedly 5 fields and the 2nd
>    was blank? - fields 3-5 would be misinterpreted as 2-4; bad.
>

OK, this is reasonable, thanks.


>
> 2) I see only one test case where there is a difference in output
>    between $2 and column(2).  Is there another one that I missed?
>
> > # Curve 0 of 1, 3 points
> > # Curve title: "$data_with_whitespace u 1:(column(2)>0?column(2):0)"
> > # x y type
> >  1  1  i
> >  2  NaN  u
> >  3  3  i
>
> The 'u' in the table output tells you that this point is undefined
> (as opposed to "missing", in which case it would not appear at all).
> I am uncertain why $2 doesn't behave identically, but in any case
> if you set the property
>    set datafile missing NaN
> then both $2 and column(2) are treated as missing data.
> The difference is worth investigating.  I'll see what I can find.
>

Actually, the presence of the NaN is explained by what you wrote in the
previous point.


>
> > Observations:
> > - it's as if the mere presence of a $X in the specification causes the
> > datum to be marked as invalid, and dropped entirely, if column X
> > doesn't contain data, no matter what the rest of the specification is.
>
> Which piece of output shows this?
>

Uh, all of them that have $2 in the command? But compare just these two:

# Curve 0 of 1, 2 points
# Curve title: "$data_with_semicolons u 1:(valid(2)?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 3 points
# Curve title: "$data_with_semicolons u 1:(valid(2)?column(2):0)"
# x y type
 1  1  i
 2  0  i
 3  3  i

The only difference in the command is `column(2)` vs `$2`. From the $2
table, line 2 is missing.

I'd argue that this is a bug, but even if it isn't, it's not documented (or
if it is, documented poorly, because I couldn't find it), and even if it
were a documented feature, it would be a confusing, unjustifiable and
undiscoverable one at that.



>
> > Bonus:
> > `reset` doesn't reset `set table`. The documentation of `reset` doesn't
> > mention that as an exception.
>
> The help description is
>   The `reset` command causes all graph-related options that can be set
>   with the `set` command to return to their default values.
>
> It is only expected to affect the settings for graphics state.
> It doesn't affect file output (set loadpath, set print, set table,
> set output, ...).  It also doesn't affect "set datafile columnheaders"
> although maybe it should, or maybe that should be added to the explicit
> list of exceptions.
>

OK, this is acceptable - but perhaps the documentation could be amended to
be clearer, by mentioning that it doesn't affect output options, or have a
complete list of exceptions.


>
>     cheers,
>                 Ethan
>
>
>
In any case, thanks for looking into this.
best regards,

Peter

Re: Weirdness in column specifications, column() vs dollar

[Ethan A M. <me...@uw...>]

On Tuesday, 1 March 2022 10:48:41 PST Juhász Péter wrote:
> Dear gnuplot list members,
> 
> today I tried to modify a plot so that it applies a default value if
> one of the columns was empty, and for the longest time I couldn't
> understand why it didn't work. I managed to make it work in the end,
> but I still don't understand it. There are strange differences in
> behavior, depending on whether `column(x)` or `$x` is used, and it even
> depends on the datafile separator. I've distilled the issues I've found
> into the following minimal example:

I will explain what I can, but I may not be noticing what it is
that you are calling strange.

1) Difference between whitespace and csv files.
   There is only one instance of this, right? and it shows what happens
   when there is only one number on the line of data.
   This is a real difference and I think the reason is clear.
   In a csv file you can count field separators and know for certain
   that if there are N separators there are N+1 fields.
   If fields are separated only by whitespace you cannot distinguish
   between a field that is present, but empty, from a field that is
   missing altogether.  The former is handled by whatever is in place
   to catch zero or missing data entries, the latter is considered an
   error that invalidates the entire line.  You might think that marking
   the entire line invalid because the 2nd of two numbers is blank is
   excessive, but what if there were supposedly 5 fields and the 2nd
   was blank? - fields 3-5 would be misinterpreted as 2-4; bad. 

2) I see only one test case where there is a difference in output
   between $2 and column(2).  Is there another one that I missed?

> # Curve 0 of 1, 3 points
> # Curve title: "$data_with_whitespace u 1:(column(2)>0?column(2):0)"
> # x y type
>  1  1  i
>  2  NaN  u
>  3  3  i

The 'u' in the table output tells you that this point is undefined
(as opposed to "missing", in which case it would not appear at all).
I am uncertain why $2 doesn't behave identically, but in any case
if you set the property
   set datafile missing NaN
then both $2 and column(2) are treated as missing data.
The difference is worth investigating.  I'll see what I can find.

> Observations:
> - it's as if the mere presence of a $X in the specification causes the
> datum to be marked as invalid, and dropped entirely, if column X
> doesn't contain data, no matter what the rest of the specification is.

Which piece of output shows this?

> Bonus:
> `reset` doesn't reset `set table`. The documentation of `reset` doesn't
> mention that as an exception.

The help description is
  The `reset` command causes all graph-related options that can be set
  with the `set` command to return to their default values. 

It is only expected to affect the settings for graphics state.
It doesn't affect file output (set loadpath, set print, set table,
set output, ...).  It also doesn't affect "set datafile columnheaders"
although maybe it should, or maybe that should be added to the explicit
list of exceptions.

    cheers,
		Ethan

Weirdness in column specifications, column() vs dollar

[Juhász P. <pet...@gm...>]

Dear gnuplot list members,

today I tried to modify a plot so that it applies a default value if
one of the columns was empty, and for the longest time I couldn't
understand why it didn't work. I managed to make it work in the end,
but I still don't understand it. There are strange differences in
behavior, depending on whether `column(x)` or `$x` is used, and it even
depends on the datafile separator. I've distilled the issues I've found
into the following minimal example:

#------------------------------------------------
show version

$data_with_whitespace << EOD
1 1
2
3 3
EOD

$data_with_semicolons << EOD
1;1
2;
3;3
EOD

set table

plot $data_with_whitespace u 1:($2>0?$2:0)
plot $data_with_whitespace u 1:(column(2)>0?$2:0)
plot $data_with_whitespace u 1:(column(2)>0?column(2):0)
plot $data_with_whitespace u 1:(valid(2)?$2:0)
plot $data_with_whitespace u 1:(valid(2)?column(2):0)

set datafile separator ';'

plot $data_with_semicolons u 1:($2>0?$2:0)
plot $data_with_semicolons u 1:(column(2)>0?$2:0)
plot $data_with_semicolons u 1:(column(2)>0?column(2):0)
plot $data_with_semicolons u 1:(valid(2)?$2:0)
plot $data_with_semicolons u 1:(valid(2)?column(2):0)
#-----------------------------------------------------

Output:

#-----------------------------------------------------

	G N U P L O T
	Version 5.5 patchlevel 0    last modified 2020-06-24 

	Copyright (C) 1986-1993, 1998, 2004, 2007-2020
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info
	mailing list:     gnu...@li...
	faq, bugs, etc:   type "help FAQ"
	immediate help:   type "help"  (plot window: hit 'h')


# Curve 0 of 1, 2 points
# Curve title: "$data_with_whitespace u 1:($2>0?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 2 points
# Curve title: "$data_with_whitespace u 1:(column(2)>0?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 3 points
# Curve title: "$data_with_whitespace u 1:(column(2)>0?column(2):0)"
# x y type
 1  1  i
 2  NaN  u
 3  3  i


# Curve 0 of 1, 2 points
# Curve title: "$data_with_whitespace u 1:(valid(2)?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 3 points
# Curve title: "$data_with_whitespace u 1:(valid(2)?column(2):0)"
# x y type
 1  1  i
 2  0  i
 3  3  i


# Curve 0 of 1, 2 points
# Curve title: "$data_with_semicolons u 1:($2>0?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 2 points
# Curve title: "$data_with_semicolons u 1:(column(2)>0?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 3 points
# Curve title: "$data_with_semicolons u 1:(column(2)>0?column(2):0)"
# x y type
 1  1  i
 2  0  i
 3  3  i


# Curve 0 of 1, 2 points
# Curve title: "$data_with_semicolons u 1:(valid(2)?$2:0)"
# x y type
 1  1  i
 3  3  i


# Curve 0 of 1, 3 points
# Curve title: "$data_with_semicolons u 1:(valid(2)?column(2):0)"
# x y type
 1  1  i
 2  0  i
 3  3  i
#-------------------------------------------------------------------

Observations:

- it's as if the mere presence of a $X in the specification causes the
datum to be marked as invalid, and dropped entirely, if column X
doesn't contain data, no matter what the rest of the specification is.
- it depends on the datafile separator, see the NaN vs. 0 in the above
output.
- this was produced on a custom 5.5 build, but I've observed the same
on a distro-provided 5.4.x build too.

Is there any rational explanation for any of this? The documentation
doesn't seem to mention anything other than "The special symbols
 $1, $2, ... are shorthand for column(1), column(2) ...".

Bonus:
`reset` doesn't reset `set table`. The documentation of `reset` doesn't
mention that as an exception.

best regards,
Peter Juhasz

Re: Qt term enhancements

[m s. <mw...@us...>]

Thanks for accepting this patch.  I will revisit the change to mouse.c 
and see what was happening that caused me to change it.

Thanks again
MikeS

On 2/12/2022 2:09 AM, Ethan A Merritt wrote:
> On Wednesday, 9 February 2022 17:28:13 PST m sutton wrote:
>> Hi All,
>>
>> I modified the qt term so you can  set three options that are currently
>> on the tools dialog.
>>
>> The change will allow you to specify rounded|butt, {no}replotonresize
>> and {no}antialias.  These are temporary settings.
>>
>> This also fixed a bug with the {no}ctrl option.  If multiple "set term
>> qt" command were given before the plot window was opend, the {no}ctrl
>> setting would be lost.
>>
>> The attached diff is based on v5.4.1.  Let me know if something needs
>> changed.
> Looks good to me.
>
> I applied it to current git tip for the development branch (5.5).
> It's commit 490b2e9c3
>
> However I dropped the change to mouse.c, which I think was an
> artifact of working from an old version.  If that change was
> intentional for some reason, let me know and I'll have another look.
>
> Note:  this changes the gnuplot <-> gnuplot_qt protocol interface
> so testers should note that both programs must be updated in parallel.
> If you want to test before doing "make install", build it in the
> source directory and test with GNUPLOT_DRIVER_DIR=.
>
> 	cheers,
> 		Ethan
>
>> Once again, many thank to all of you that make Gnuplot so awesome.
>>
>> Regards,
>>
>> MikeS
>>
>>
>
>

Re: Qt term enhancements

[Ethan A M. <me...@uw...>]

On Wednesday, 9 February 2022 17:28:13 PST m sutton wrote:
> Hi All,
> 
> I modified the qt term so you can  set three options that are currently 
> on the tools dialog.
> 
> The change will allow you to specify rounded|butt, {no}replotonresize 
> and {no}antialias.  These are temporary settings.
> 
> This also fixed a bug with the {no}ctrl option.  If multiple "set term 
> qt" command were given before the plot window was opend, the {no}ctrl 
> setting would be lost.
> 
> The attached diff is based on v5.4.1.  Let me know if something needs 
> changed.

Looks good to me.

I applied it to current git tip for the development branch (5.5).
It's commit 490b2e9c3

However I dropped the change to mouse.c, which I think was an
artifact of working from an old version.  If that change was
intentional for some reason, let me know and I'll have another look.

Note:  this changes the gnuplot <-> gnuplot_qt protocol interface
so testers should note that both programs must be updated in parallel.
If you want to test before doing "make install", build it in the
source directory and test with GNUPLOT_DRIVER_DIR=.

	cheers,
		Ethan

> 
> Once again, many thank to all of you that make Gnuplot so awesome.
> 
> Regards,
> 
> MikeS
> 
> 

Re: Qt term enhancements

[Tatsuro M. <tma...@ya...>]

Hello Mike

Your proporsal new enhancement of qt terminal is really good.
However, your proprosal is better to be carried out in the Patches ticket.

https://sourceforge.net/p/gnuplot/patches/

Tatsuro 

> ----- Original Message -----
> 
> From: "m sutton" 
> To: "gnuplot-beta
> Date: 2022/02/10 木 10:42
> Subject: Qt term enhancements
> 
> 
> Hi All,
> 
> I modified the qt term so you can  set three options that are currently 
> on the tools dialog.
> 
> The change will allow you to specify rounded|butt, {no}replotonresize 
> and {no}antialias.  These are temporary settings.
> 
> This also fixed a bug with the {no}ctrl option.  If multiple "set term 
> qt" command were given before the plot window was opend, the {no}ctrl 
> setting would be lost.
> 
> The attached diff is based on v5.4.1.  Let me know if something needs 
> changed.
> 
> Once again, many thank to all of you that make Gnuplot so awesome.
> 
> Regards,
> 
> MikeS
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Qt term enhancements

[m s. <mw...@us...>]

Hi All,

I modified the qt term so you can  set three options that are currently 
on the tools dialog.

The change will allow you to specify rounded|butt, {no}replotonresize 
and {no}antialias.  These are temporary settings.

This also fixed a bug with the {no}ctrl option.  If multiple "set term 
qt" command were given before the plot window was opend, the {no}ctrl 
setting would be lost.

The attached diff is based on v5.4.1.  Let me know if something needs 
changed.

Once again, many thank to all of you that make Gnuplot so awesome.

Regards,

MikeS

Re: How to get the previous image of git of master baranch

[Tatsuro M. <tma...@ya...>]

Ethan

Thank you for your help.
The origin fo my trouble does not reply on the gnuplot source but on the local environment.
On copied cygwin environments gnuplot runs without problem.

I will reconstruct the cygwin enviromments. 

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2022/02/04 金 09:44
> Subject: Re: How to get the previous image of git of master baranch
> 
> 
> On Thursday, 3 February 2022 14:38:34 PST Tatsuro MATSUOKA wrote:
> > Please show me tbe way to get the previous image git go master branch.
> 
> Go back exactly one commit:
> 
>      git checkout HEAD~1
> 
> Go back to a commit that you know by number
> 
>      git checkout b992a505
> 
> Restore the state to where you started
> 
>      git checkout master
> 
> Ethan
> 
> > 
> > For my cygwin build of gnuplot on the development source, gnuplot does not run 
> > $ src/gnuplot
> > (nothing happen) 
> > $ 
> > (back to prompt)
> > 
> > I exucute gnuplot via gdb and set back trace to main but gnuplot ends.
> > 
> > I want to get the previous git source to see from what change causes the issue.
> > I note thar I could execute gnuplot 5.4.3 built myself.
> > 
> > Thank for advance.
> > 
> > Tatsuro
> 
> 
> 

Re: How to get the previous image of git of master baranch

[Ethan A M. <me...@uw...>]

On Thursday, 3 February 2022 14:38:34 PST Tatsuro MATSUOKA wrote:
> Please show me tbe way to get the previous image git go master branch.

Go back exactly one commit:

     git checkout HEAD~1

Go back to a commit that you know by number

     git checkout b992a505

Restore the state to where you started

     git checkout master

Ethan

> 
> For my cygwin build of gnuplot on the development source, gnuplot does not run 
> $ src/gnuplot
> (nothing happen) 
> $ 
> (back to prompt)
> 
> I exucute gnuplot via gdb and set back trace to main but gnuplot ends.
> 
> I want to get the previous git source to see from what change causes the issue.
> I note thar I could execute gnuplot 5.4.3 built myself.
> 
> Thank for advance.
> 
> Tatsuro

Re: Unicode in the postscript terminal

[Ethan A M. <me...@uw...>]

On Thursday, 3 February 2022 14:18:57 PST Tatsuro MATSUOKA wrote:
> A post was made for plot of unicode chracter.
> https://sourceforge.net/p/gnuplot/mailman/gnuplot-info/thread/66152bfa-127c-bb35-7068-91b0f215e705%40kaniuk.co.uk/#msg37602226
> 
> For interactive terminal it seems to be a problem of font selection.
> However,  in the postscript terminal,unicode character is not represented.

The PostScipt language does not support multi-byte encodings.
Therefore it does not support UTF-8 or any other "reasonable"
way to reference Unicode code points in general.

It is technically possible to extract a subset of Unicode entities
from a suitable font (probably *.ttf) and match them to PostScript
glyph assignments.  There are instructions and examples in the
file .../term/PostScript/unicode_maps.README

However it is not worth it.  Really it is not worth it.
The procedure is difficult, fragile, and does not extend well
to handle large numbers of Unicode gplyphs.

If you really require a *.ps file for some reason, it is better
to create a *.pdf file from gnuplot and then convert it from
pdf to PostScript in a separate step.  This has the added benefit
that PDF support transparency, which PostScript doesn't, and
the conversion will take care of that also.

But for most purposes it would be better to use the *.pdf file
and forget about PostScript.

set terminal pdf
set output 'myplot.pdf'
set encoding utf8
plot [1:10] \
    0.9*x w lp t "POINT"   pt "◎", \
    0.5*x w lp t "UNICODE" pt "\U+25CE", \
    0.2*x w lp t "HASH"    pt "#"
unset output
system("pdf2ps myplot.pdf myplot.ps")

	Ethan


> 
> The test script is :
> 
> #!/usr/bin/gnuplot -persist
> reset session
> set encoding utf8
> set terminal wxt 1 nopersist enhanced font 'Dejavu Sans'
> 
> unset key; set key on inside left
> 
> set samples 20
> 
> plot [1:10] \
> 0.9*x w lp t "POINT"   pt "◎", \
> 0.5*x w lp t "UNICODE" pt "\U+25CE", \
> 0.2*x w lp t "HASH"    pt "#"
> 
> set terminal push
> set terminal postscript eps enhanced color size 20 cm, 10 cm
> set output "test-pt.eps"
> replot
> set output
> set terminal pop
> #EOF    
> 
> I thouht that the postscript terminal cannot handle unicode.
> However Norwid provided the detailed analysis of eps file (test-pt.eps) created by the above script
> https://sourceforge.net/p/gnuplot/mailman/message/37602883/
> 
> With Inkscape (version 1.1.1) by internal import, one can see the unicode characters on the plot.
> (On Evince and Inksapce with poppler/cairo import (default), we cannot see unicode character. 
> In addtion, I also cannot see unicode chracters on gv , eps viewer and adobe reader (after coverted to pdf file))
> 
> Anyway, in the current state, the postscipt terminal cannot treat the unicode character properly.
> Am I right?
> 
> Tatsuro

How to get the previous image of git of master baranch

[Tatsuro M. <tma...@ya...>]

Please show me tbe way to get the previous image git go master branch.

For my cygwin build of gnuplot on the development source, gnuplot does not run 
$ src/gnuplot
(nothing happen) 
$ 
(back to prompt)

I exucute gnuplot via gdb and set back trace to main but gnuplot ends.

I want to get the previous git source to see from what change causes the issue.
I note thar I could execute gnuplot 5.4.3 built myself.

Thank for advance.

Tatsuro

Unicode in the postscript terminal

[Tatsuro M. <tma...@ya...>]

A post was made for plot of unicode chracter.
https://sourceforge.net/p/gnuplot/mailman/gnuplot-info/thread/66152bfa-127c-bb35-7068-91b0f215e705%40kaniuk.co.uk/#msg37602226

For interactive terminal it seems to be a problem of font selection.
However,  in the postscript terminal,unicode character is not represented.

The test script is :

#!/usr/bin/gnuplot -persist
reset session
set encoding utf8
set terminal wxt 1 nopersist enhanced font 'Dejavu Sans'

unset key; set key on inside left

set samples 20

plot [1:10] \
0.9*x w lp t "POINT"   pt "◎", \
0.5*x w lp t "UNICODE" pt "\U+25CE", \
0.2*x w lp t "HASH"    pt "#"

set terminal push
set terminal postscript eps enhanced color size 20 cm, 10 cm
set output "test-pt.eps"
replot
set output
set terminal pop
#EOF    

I thouht that the postscript terminal cannot handle unicode.
However Norwid provided the detailed analysis of eps file (test-pt.eps) created by the above script
https://sourceforge.net/p/gnuplot/mailman/message/37602883/

With Inkscape (version 1.1.1) by internal import, one can see the unicode characters on the plot.
(On Evince and Inksapce with poppler/cairo import (default), we cannot see unicode character. 
In addtion, I also cannot see unicode chracters on gv , eps viewer and adobe reader (after coverted to pdf file))

Anyway, in the current state, the postscipt terminal cannot treat the unicode character properly.
Am I right?

Tatsuro

Re: Translation of the manual into Italian

[Ethan A M. <me...@uw...>]

On Friday, 21 January 2022 08:24:18 PST s.lopoeta--- via gnuplot-beta wrote:

> we have translated the manual of Gnuplot version 5.4 into Italian
> and we have made it available on our website at the following page
> 
> https://www.bielle.it/opensource/gnuplot
> 
> We would love to see the URL added on the Gnuplot page
> 
> http://www.gnuplot.info/help.html
> 
> It's possible ?
> 
> The translation was done by Alice Lopoeta.

Translation of the manual into Italian

[<s.l...@bi...>]

Hello,

we have translated the manual of Gnuplot version 5.4 into Italian
and we have made it available on our website at the following page

https://www.bielle.it/opensource/gnuplot

We would love to see the URL added on the Gnuplot page

http://www.gnuplot.info/help.html

It's possible ?

The translation was done by Alice Lopoeta.

We hope there are no problems (copyright or otherwise) if so
tell us what needs to be done.

-- 
Stefano LOPOETA

BI ELLE Srl
Via Fattori, 75 -- 10141 TORINO
Tel. +39 0117725111
www.bielle.it