On Tue, 3 Apr 2001, William D. Kirby wrote:

> In both the Cygnus X-Windows and WIN32 versions of gnuplot the use of
> environment variable for PATH in labels works interactively when
> directly entered or from a file using the load 'file.plt' command.
> However, if the file file.plt is given on the execution command line the
> process aborts.

Can you perhaps find out *where* it aborts? Run it in a debugger, or
look at the CS:IP reported in the crash dialog displayed by Windows and
relate to the place where the crash happens.

In real Unix, this doesn't cause any problem I could observe.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hello,

an idea that crossed my mind recently is that the information about
individual plot styles (LINES, LINESPOINTS, POINTS_STYLE, BOXES, ...)
is currently stored and accessed in quite a badly organized way.
Some information is kept in special bits inside the plot style number
itself, but most of it is encoded implicitly in switch() statements
all over the place.

As I see it, this needs some cleaning up. Something roughly like the
'axis' stuff, but centered on plot styles. There'd probably be an array of
"plotstyle" structs, each of which would hold all information about a
single plot style we have: min/max number of 'using' colums, type of
sample drawn in the key, meaning of the abused 'z' column in 2D plots, and
probably some more. Instead of passing around enum plot_style members,
we'ld use indices into that global array. Even some function pointers
inside the struct might come in handy --- we'll see.

Probably this should all be encapsulated in yet another new module.
Or it could be put into the main module (plot.[ch]).

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

[ forwarding : majordomo didn't like the word 'config' as the first thing
  in the mail !
  dd
]

From: "William D. Kirby" <wdkirby@...>


config.log shows that compiling conftest.exe links the libraries in the wrong
order. It has -lpng -lz -lpdf -lz -ltiff. It should be -lpdf -ltiff -lpng -lz.

Lars Hecking wrote:

> > > configure can't find libpdf.a. I moved the library, and even set
> > > --with-pdf=lib-path.
> >
> > No big surprise: there's no pdf support in the CVS version of configure.
>
>  Yes it does, as you finally discovered ;-)
>
> > I'd check in a working 'configure' myself, but my autoconf version is
> > different from Lars', so I'd rather avoid that.
>
>  Nope, I'm using bog-standard autoconf 2.13 (release version). The only
>  tool I'm using that is different is automake.
>
>  The generated config.log file should say a word or two why the lib
>  cannot be found.
>
> [[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hi Lauren,

> I'd be happy (and find a lot of uses for ) a COM
> wrapper for the gnuplot plotting engine. No UI,
> just write to file (or return result as string for
> terms like postscript, SVG etc) Has anyone done
> this previously?

This mode would be part of an MFC-friendly version.
Way back, I trimmed a version of Gnuplot to provide only
a 32bit ANSI do_line(char*) engine.  This was to get
postscript and gif dumps of FEM fields, in addition to
the interactive Vtk visualizations.  *nix users could use
their usual tools, but this gave Win32 users easy access
to ps and gif.  But that was a crude once-off  :-)
This time, I will try to stay on the evolutionary path
leading inexorably towards v4.0 ",... and Beyond"!
Nigel

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 3 Apr 2001, William D. Kirby wrote:

> order. It has -lpng -lz -lpdf -lz -ltiff. It should be -lpdf -ltiff -lpng -lz.

I.e. it's still the same problem you mentioned earlier.

Hmm... I can't quite see why this should make any difference. This detail
in link order would only make a difference if -lpdf itself were using
-lpng, i.e. pdflib is built with some PNG file support. Mine isn't, I
think.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

William D. Kirby writes:
>
> [ forwarding : majordomo didn't like the word 'config' as the first thing
>  in the mail !
>  dd
> ]

  [ Yeah, really nasty ;-) lh ]

> config.log shows that compiling conftest.exe links the libraries in the wrong
> order. It has -lpng -lz -lpdf -lz -ltiff. It should be -lpdf -ltiff -lpng -lz.

  I had a look at your other mails on the subject. The only conclusion I can
  draw from this is that libtiff requires either libpng or libz.

  I'll fix this once I have installed libpdf.

  [Please don't Cc: me on list replies. Thank you.]


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

> Probably this should all be encapsulated in yet another new module.
> Or it could be put into the main module (plot.[ch]).

I'd suggest releasing the next version of gnuplot before making this change.

--
Jeff Spirko             WD3V  | The study of non-linear physics
spirko@...             | is like the study of
http://www.lehigh.edu/~jas8/  | non-elephant biology.

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Happy to report that I got the Cygnus X-Windows version of gnuplot to
use pipes (internal and external).

I found it failed before because the piped input file had a DOS format.
This includes the use of unix formatted environment variables.

I discovered that there has to be a blank line after a "pause -1 "Hit
return to continue"" type command line in the input file. Otherwise
gnuplot stopped with an error (line 0:invalid command) processing the
next command line after the pause line. The simple.dem file was modified
for creating a file output for this testing.

Hope to create and test a Cygwin Windows console version to can use
pipes as well.




[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Mon, 2 Apr 2001, Hans-Bernhard Broeker wrote:

> On Mon, 2 Apr 2001, Johannes Zellner wrote:
>
> [...]
>
> That's a point which is debatable, at least to some extent. Currently,
> we have two families of 'plot styles' in gnuplot.
>
> 1) the traditional "with <style>" variety. There's default behaviour,
>    and the 'set style data' and "set style functions" to override that
>    default, to save some typing.
>
> 2) global mode changes. Currently, those are:
>
>  set hidden3d
>  set contour
>  set pm3d
>

In my opinion, there is a possibility of confusion with the new
'column' syntax, where pm3d is both a global and a local 'plot' modifier.
For the MAIN trunk, pm3d is only global. On the other hand, the problem
with a global pm3d is that while you can specify which type of
surface/plane you want couloured (top, bottom, surface), you can not make
it colour only *some* of the surfaces if you have several of them, they
will both become coloured.
Maybe let the global pm3d as it is, and use csurface or whatever you like
as the name of the local modifier.

> I.e. it's not like "with <style>" is the only prior art, in this area, or
> the only thing we'ld have to think about if we modify the method to access
> pm3d.
>

In this case, as I said before, the question is not really a global *or* a
local colour modifier, both are needed with the actual syntax. Of course,
it would be always possible to use only a local modifier, but in this
case:

- you would break up already existing scripts relying e.g. on 'set pm3d at
s'

- how can one colour the bottom or top xy plane in addition to the
surface? You can't specify these planes within a plot command.

As a side note: maybe in some cases it would even make sense
to colour the back or side planes also (xz or yz planes)...

> > maybe some abbreviations like 'linespoints' could faciliate this:
>
> This smells of lack of orthogonality in the command. We should think twice
> before we introduce separate commands for all possible combinations of two
> essentially unrelated choices. It blows up the code, and makes it
> unnecessarily hard to maintain. The current mess with the axis-related
> settings is bad enough, already.
>
> Besides, if we keep adding options to {s}plot at this pace, we'll have to
> think about a method to store all the options put into a single dataset
> description (from function/filename up to the style arguments) into a
> user-definable variable. Something like
>
>  set plot 5 'datafile' using 5:25 \
> 	    title "some complicated enhps stuff" \
> 	    with linespoints lt 3 lw 2.5 pt 2 ps 1
>
>  plot sin(x), plot(5)
>
> or something along those lines.
>

Yes, interesting idea. But IMHO for now, it would be wiser to modify not
too much, it would permit to release the new stable gnuplot quickier. As I
understood, it is really a small job to modify the actual code for getting
support for individually coloured surfaces and datafile-given polygon
colours. This is really a big gain, at least for some of us: it would
permit to represent a physical surface in 3D projection with a given
parameter (temperature, stiffness, etc.) colour-mapped on it.

Levente


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Thu, 5 Apr 2001, Novak Levente wrote:

> On Mon, 2 Apr 2001, Hans-Bernhard Broeker wrote:

> > That's a point which is debatable, at least to some extent. Currently,
> > we have two families of 'plot styles' in gnuplot.
> >
> > 1) the traditional "with <style>" variety. There's default behaviour,
[...]
> > 2) global mode changes. Currently, those are:
[...]

> In my opinion, there is a possibility of confusion with the new
> 'column' syntax, where pm3d is both a global and a local 'plot' modifier.

Exactly. And it's this confusion that we have to sort out before we
can put the column stuff into the trunk version, I think.

> For the MAIN trunk, pm3d is only global. On the other hand, the problem
> with a global pm3d is that while you can specify which type of
> surface/plane you want couloured (top, bottom, surface), you can not make
> it colour only *some* of the surfaces if you have several of them, they
> will both become coloured.

Likewise, you can't choose to contour only some of your datasets (assuming
they're eligible for contouring in the first place). And that's why I
brought this up. If we change pm3d to a per-plot option, consistence would
require to at least think about doing the same for contouring. Hidden3d
may fall in the same category.

OTOH, both hidden3d and contouring, and possibly dgrid3d too, might be
considered prototypes of a new type of splot option, which we might call
'mesh transformation': they take input data and transform the data:
hidden3d into triangles (so other plot elements can be hidden behind
them), contour into contour lines, dgrid transforms non-grid into grid
data. And pm3d transforms into coloured triangles.

Looking at it this way would probably help quite a bit to restructure
both the user interface and the internal code layout.

It *might* even make sense to put together several of these
transformations for a single datafile. Color-column data, e.g., could be
transformed 'contour hidden3d' to turn them into a solid-looking
isosurface.

> In this case, as I said before, the question is not really a global *or* a
> local colour modifier, both are needed with the actual syntax.

But that would only make full sense if there also was a local option to
not draw a particular surface in pm3d mode, even though pm3d is turned on,
globally, IMHO.

> - you would break up already existing scripts relying e.g. on 'set pm3d at
> s'

Breaking up scripts using beta versions isn't considered a very major sin,
at least by me.  We really can't guarantee compatibility among development
versions. Among released versions is a different game, of course.

> - how can one colour the bottom or top xy plane in addition to the
> surface? You can't specify these planes within a plot command.

Right. The current per-plot syntax is incomplete. We'll have to shift the
'at <sequence>' argument down to the per-dataset options, too.


[... on 'saving' a dataset's plot options for later usage ...]

> Yes, interesting idea. But IMHO for now, it would be wiser to modify not
> too much, it would permit to release the new stable gnuplot quickier.

In case that wasn't obvious: this was really a vague idea of a long-term
plan. Not anything I'd want to see changed before Easter this year :-)

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hello,

I have a problem when compiling gnuplot 3.8f patchlevel 0
(retrieved via cvs)
  G N U P L O T
  Version 3.8f patchlevel 0
  last modified jeu avr  5 16:44:02 CEST 2001
  System: Linux 2.2.17

my ./configure :
./configure --prefix=/home/allegreg --with-x --with-x11-driver \
--with-readline

but the generated Makefile shows a blank line :
GNUPLOT_X11 =

and after compiling, there is no gnuplot_x11 binary

Have I forgotten something in the ./configure ?
Thanks for help

--
Guillaume Allègre   Guillaume.Allegre@...  04.76.51.40.48
GreCO (Grenoble universités / Campus Ouvert)   -     Logiciels Libres
liste GreCO-Libre@...       site http://libris.grenet.fr

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Thu, 5 Apr 2001, Guillaume Allègre wrote:

> Hello,
>
> I have a problem when compiling gnuplot 3.8f patchlevel 0
> (retrieved via cvs)
>  G N U P L O T
>  Version 3.8f patchlevel 0
>  last modified jeu avr  5 16:44:02 CEST 2001
>  System: Linux 2.2.17
>
> my ./configure :
> ./configure --prefix=/home/allegreg --with-x --with-x11-driver \
                                                ^^^^^^^^^^^^^^^^^

There's your problem. You shouldn't have used that option, or if so,
you should have given it an argument. The 'configure --help' output
isn't telling so, but that's what you should have done.

It's also advisable to --enable-pm3d --enable-mouse.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

I got a cvs update for 5 April, and found that configure still can't
find pdflib. The test.exe linking has -lpdf -lz -ltiff. It should be
-lpdf -ltiff -lpng -lz. My pdflib has png support which may be a factor.

I'm using Cygwin 1.1.8


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Le Thu 05 Apr 2001 à 17:32:30PM +0200, Hans-Bernhard Broeker a écrit :
> On Thu, 5 Apr 2001, Guillaume Allègre wrote:

> > my ./configure :
> > ./configure --prefix=/home/allegreg --with-x --with-x11-driver \
>                                                ^^^^^^^^^^^^^^^^^
>
> There's your problem. You shouldn't have used that option, or if so,
> you should have given it an argument. The 'configure --help' output
> isn't telling so, but that's what you should have done.

I have exactly the same problem with only
./configure --prefix=/home/allegreg --with-x

Actually, I have added --with-x11-driver because it didn't work without
the first time I tried.

Am I the only one to obtain this problem ?

--
Guillaume Allègre   Guillaume.Allegre@...  04.76.51.40.48
GreCO (Grenoble universités / Campus Ouvert)   -     Logiciels Libres
liste GreCO-Libre@...       site http://libris.grenet.fr

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Thu, 5 Apr 2001, William D. Kirby wrote:

> I got a cvs update for 5 April, and found that configure still can't
> find pdflib. The test.exe linking has -lpdf -lz -ltiff. It should be
> -lpdf -ltiff -lpng -lz. My pdflib has png support which may be a factor.

This is getting curiouser and curiouser. I looked into my Linux libpdf a
bit, and found that it, too, has PNG support, but that *does* cause it to
require -lpng after -lpdf.  At least not for linking an application that
doesn't actually use any of the PNG support in libpdf like the test
executable built by configure.

We really can't just add -lpng to that list just like that, I think
(I was rather weary of adding -ltiff, already): some people might have
built their PDFLib without support for png, and might not even have a
-lpng on their system. In such cases, the test for -lpdf would fail
for no good reason.

What might work is if we add -lpng to the -lpdf test line, but only if
-lpng has been found, by its own test. However, this would again break
a build --without-png --with-pdf.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Fri, 6 Apr 2001, Guillaume Allègre wrote:

> I have exactly the same problem with only
> ./configure --prefix=/home/allegreg --with-x

We'll need your config.log, then, and maybe config.status, too. For some
reason, 'configure' isn't finding any X11 on your machine, it seems.

Be sure to re-run configure from a clean start:

	 make distclean
	 ./configure --prefix=$HOME

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Fri, 6 Apr 2001, Hans-Bernhard Broeker wrote:

> bit, and found that it, too, has PNG support, but that *does* cause it to
                                                          ^^^^^^
Ooops, that was mean to read "does *not*", of course :-)

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Hans-Bernhard Broeker writes:
> On Thu, 5 Apr 2001, William D. Kirby wrote:
>
> > I got a cvs update for 5 April, and found that configure still can't
> > find pdflib. The test.exe linking has -lpdf -lz -ltiff. It should be
> > -lpdf -ltiff -lpng -lz. My pdflib has png support which may be a factor.
>
> This is getting curiouser and curiouser. I looked into my Linux libpdf a
> bit, and found that it, too, has PNG support, but that *does* cause it to
                                                               not
> require -lpng after -lpdf.  At least not for linking an application that
> doesn't actually use any of the PNG support in libpdf like the test
> executable built by configure.

  I finally got around to installing pdflib on my Solaris box ...

  TERMLIBS = -lpng -lz -lpdf -lz -ltiff

  and this works, although my pdf lib has png and tiff support.

  I'll have a solution shortly, but I _think_ it'll require rewriting
  GP_PATH_LIB.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Fri, 6 Apr 2001, Lars Hecking wrote:
>
>  I finally got around to installing pdflib on my Solaris box ...
>
>  TERMLIBS = -lpng -lz -lpdf -lz -ltiff
>
>  and this works, although my pdf lib has png and tiff support.

Seems the author of PDFlib is aware of potential problems in this
area, too. The latest version (4.0.0beta3) of it now swallowed all
it needs of the support libs (z, tiff, png) into its own sources.
Unless you configure otherwise, it does *not* use any existing
pre-installed versions of those libraries at all.

The good news: PDFlib 4.0.0beta3 seems to work quite nicely with our PDF
terminal driver (even as a shared lib on an Alpha/DigitalUnix box, after
some fiddling with LD_LIBRARY_PATH).

It offers a new feature, too: "templates", i.e. essentially macros.
Using that might reduce the size of gnuplot-generated PDFs quite a bit,
at the cost of a longer prologue. I.e. it's moving into a direction
extremely similar to SVG and PostScript --- no surprise, all of these
coming from the same home: Adobe

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

The following is reported by gnuplot after a mistaken exchange of
set<->show:

gnuplot> show data style linesp;
                    ^
          internal parser error -- report as a bug

---

Petr Mikulik




[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

The following commands

set autoscale
plot '-'
0 0.999999999999999
1 1
e

freeze gnuplot. This bug seems to be introduced during the last 3 months.

---
Petr Mikulik



[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Sun, 8 Apr 2001 18:18:52 +0200 (CEST), Petr Mikulik wrote:

>The following commands
>
>set autoscale
>plot '-'
>0 0.999999999999999
>1 1
>e
>
>freeze gnuplot. This bug seems to be introduced during the last 3 months.
>

Confirmed, cuplrit seems to be axis.c:gen_tics().
There are some HBB comments from 20010121 which seems to match
the 3 months you mention.
Which in turn puts him in a leading position to deal with it  ;-)

As one already guesses from the example the numeric seems
to strike back :-(


---
Alexander Mai
st002279@...



[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Fri, 30 Mar 2001, Johannes Zellner wrote:

> I think the main issue is to discuss the syntax. If there'd be
> an agreement about the syntax I'd volunteer to do the necessary
> changes.
>
> I'd LOVE to see this in before there'd be a release.
>
> I'd also try having a look at pm3d for SVG & PDF if there'd
> be any timeline for a release.
>

Hi Johannes,

I suppose you have read what are the problems that Petr discovered (at
least for 'set pm3d map', see his mail of 7 March). Are they easily
solvable? Also several persons seem to agree on a syntax in which the 'set
pm3d' is different from the local 'plot "data.dat" with csurface' (or
whatever you may prefer) modifier.
As you are the implementor of the 'column' feature, I would like to ask
you what is your opinion about these changes, and also do you think this
would be not too difficult to implement before a 4.0 release? Maybe the
other changes pointed out e.g. by HBB - while they are also of importance
- could be coded after the 4.0 release if they do not fit in the
timeline.
I would be glad if I could help you in testing on Linux/Windows (for the
moment, my coding skills are rather poor).

Levente


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Sun, 8 Apr 2001, Alexander Mai wrote:
> On Sun, 8 Apr 2001 18:18:52 +0200 (CEST), Petr Mikulik wrote:
[...]
> >freeze gnuplot. This bug seems to be introduced during the last 3 months.

> Confirmed, cuplrit seems to be axis.c:gen_tics().
> There are some HBB comments from 20010121 which seems to match
> the 3 months you mention.
> Which in turn puts him in a leading position to deal with it  ;-)

Right. My fault. What happens is this: in gen_tics, the loop over the
individual tic positions turns into an infinite one because of numerical
cancellation. In particular, the situation is this:

(gdb) print start
$14 = 0.999999999999999
(gdb) print end
$15 = 1
(gdb) print step
$16 = 9.9999999999999998e-17
(gdb) print tic
$17 = 1
(gdb) print tic + step
$18 = 1
(gdb) print (tic + step) - end
$19 = 0

The problem is that the range is so short compared to the absolute size
of the endpoint that we suffer from numerical cancellation in the
iteration step.

	 (step / end) <= DBL_EPS    /* assuming IEEE doubles */

I still maintain the opinion expressed in my comment, though:

/* HBB 20010121: Previous code checked absolute value
  * DBL_EPSILON against tic distance. That's numerical
  * nonsense. It essentially disallowed series ticmarks for
  * all axes shorter than DBL_EPSILON in absolute figures.
  * */

I.e. with the previous code,

	 p [1e-20:2e-20] x

would produce completely stupid tics (end tics only), and even those were
computed with lots of rounding error. Try this example with 3.7.1 and see.

At the time of writing that code, I obviously was aware of the potential
problem, as can be seen by the FIXME comment right above it:

/* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
  * begging for rounding errors to strike us. */

The rounding error does strike, in the example given by Petr.

I'll add another test for fabs(step/max(fabs(start), fabs(end))) coming
too close to DBL_EPS, I think. Or rewrite the loop to count tics instead
of check for tic <= end;

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Sat, 7 Apr 2001, Petr Mikulik wrote:

> The following is reported by gnuplot after a mistaken exchange of
> set<->show:
>
> gnuplot> show data style linesp;
>                    ^
>          internal parser error -- report as a bug

Right. Problem is that S_DATA is still defined in tables.[ch], but it's
is not used anywhere in the sources. Show.c may need an #ifdef
BACKWARDS_COMPATIBLE block, too, just like set.c.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 10 Apr 2001, Hans-Bernhard Broeker wrote:

> On Sat, 7 Apr 2001, Petr Mikulik wrote:
>
> > The following is reported by gnuplot after a mistaken exchange of
> > set<->show:
> >
> > gnuplot> show data style linesp;
> >                    ^
> >          internal parser error -- report as a bug
>
> Right. Problem is that S_DATA is still defined in tables.[ch], but it's
> is not used anywhere in the sources. Show.c may need an #ifdef
> BACKWARDS_COMPATIBLE block, too, just like set.c.

Thinking about it: show is almost entirely for interactive use. There,
we shouldn't need to offer full backwards-compatibility. That's mainly
important for scripts.

I.e. I think it should be enough to just delete S_DATA from tables.[ch]
and be done with it.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Tue, 10 Apr 2001, Hans-Bernhard Broeker wrote:

> /* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
>  * begging for rounding errors to strike us. */
>
> The rounding error does strike, in the example given by Petr.
>
> I'll add another test for fabs(step/max(fabs(start), fabs(end))) coming
> too close to DBL_EPS, I think. Or rewrite the loop to count tics instead
> of check for tic <= end;

I just checked in the solution I chose: it checks tic for near-equality
with end. If it is, and this is not the first ticmark output, sets the
already existing flag to break out of the loop at the next iteration.

--
Hans-Bernhard Broeker (broeker@...)
Even if all the snow were burnt, ashes would remain.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

I just grabbed and compiled Gnuplot from CVS an hour ago. There is a
problem with tics/ticlabels: if you do a plot (say plot x**2), the biggest
ticslabel is not 100 as it should be, but 100.1. Similar happens with many
of the plots produced by all.dem, but the ticlabel is OK when doing e.g.
plot x instead of plot x**2.
It has to do something with autoscaling as:
  plot [:] [:] x**2    # Wrong, max=100.1
  plot [:] [0:] x**2   # OK, max=100
Isn't it a bug introduced by the latest axis/range changes of HBB?

Levente

PS: Maybe it is important to note that gnuplot was compiled on Win95 with
a recent Cygwin, with PM3D, mouse, IPC, PNG and GIF enabled.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

On Wed, Apr 11, 2001 at 11:41:31AM +0200, Novak Levente wrote:
> I just grabbed and compiled Gnuplot from CVS an hour ago. There is a
> problem with tics/ticlabels: if you do a plot (say plot x**2), the biggest
> ticslabel is not 100 as it should be, but 100.1. Similar happens with many
> of the plots produced by all.dem, but the ticlabel is OK when doing e.g.
> plot x instead of plot x**2.
> It has to do something with autoscaling as:
>  plot [:] [:] x**2    # Wrong, max=100.1
>  plot [:] [0:] x**2   # OK, max=100
> Isn't it a bug introduced by the latest axis/range changes of HBB?
>
> Levente
>
> PS: Maybe it is important to note that gnuplot was compiled on Win95 with
> a recent Cygwin, with PM3D, mouse, IPC, PNG and GIF enabled.
>

Well, here on i86-linux it's also similar, but not the same:
The first gives a 1100.1 label, while for the second I get
an upper limit for y of 120!?
Hmm, not sure this additional difference between you're and my
results is related to the bug, but seems possible.

--
Alexander Mai
st002279@...

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]