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

Re: palette allocation during mouse rotation

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

I have a bit of free time to wrap up the patch to stop the constant palette refresh with X11 mouse activity.  Just one detail and I wanted to get developers opinions.

As part of a palette comparison a copy of the previous palette is stored.  Part of that is copying a udft_entry.  Right now it is only a partial copy of udft_entry as the color routines don't use all parts of the udft_entry in the test.

I'm just wondering which of these alternatives are preferred:

1) Leave this code inside getcolor.c as an incomplete copy and call the routines:

  udft_partial_cpy()
  udft_partial_del()

2) Make the routines a complete copy and delete keeping track of details for temp_at, perm_at, free_at and move them to somewhere like eval.h/eval.c so that they might find some future use somewhere else.

Basically, do you want a

udft_cpy()
udft_del()

?

Dan

Re: fileexist(f)

[Petr M. <mi...@ph...>]

>> fileexist(name)=\
>> system(sprintf("bash -c \"if [ -a %s ]; then echo 1; else echo 0; fi\"", name))
>>
>> print fileexist('a')
>> print fileexist('aa')
>
> ierr = system("test -e 'a'")
> if (ERRNO) print "No such file"

How to make a function of it? I cannot figure it out:

fileexist(name)=((system("test -e 'ab'")!="!!!") && !ERRNO)
print fileexist('anything')

Unfortunately, neither works under wgnuplot_pipes.

> Didn't we start this whole discussion thread with comparisons of
> "find" vs. "test" and their use to check file existence or updates?

Then I have probably haven't figure it out how to write it in a portable 
way.

---
PM

Re: fileexist(f)

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

On Thursday 09 March 2006 11:03 pm, Petr Mikulik wrote:
> 
> No examples has been presented until now, but I've just constructed it this 
> way:
> 
> fileexist(name)=\
> system(sprintf("bash -c \"if [ -a %s ]; then echo 1; else echo 0; fi\"", name))
> 
> print fileexist('a')
> print fileexist('aa')
> 
> Any better solution?

Didn't we start this whole discussion thread with comparisons of
"find" vs. "test" and their use to check file existence or updates?

ierr = system("test -e 'a'")
if (ERRNO) print "No such file"

ierr = system("test 'a' -nt 'b'")
if (!ERRNO) print "a is newer than b"

Maybe that was another thread....

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

Re: fileexist(f)

[Petr M. <mi...@ph...>]

> It is sufficient to use whatever system-dependent shell command
> matches your use. I gave several examples already.

No examples has been presented until now, but I've just constructed it this 
way:

fileexist(name)=\
system(sprintf("bash -c \"if [ -a %s ]; then echo 1; else echo 0; fi\"", name))

print fileexist('a')
print fileexist('aa')

Any better solution?
(There could be one with "REXX support" patch going into gnuplot...)

---
PM

Re: [ gnuplot-Patches-908040 ] Break PostScript prologue file out of post.trm

[Petr M. <mi...@ph...>]

>> - in cvs, shouldn't they be in src/PostScript instead of
>> term/PostScript? The usual place for terminal specific files
>> is in src/
>
> Usual place?
> What examples are you thinking of?
> So far as I know, driver files are in .../term
> Things like gnuplot_x11 are in .../src because they are
> separate programs, not drivers.

What about wxt? Next?
I consider them terminal specific files, whatever they do.

>> I propose to look also to directory
>> inside loadpath
>
> What loadpath are you talking about?

show|set loadpath

---
PM

Re: Changes to gnuplot fitting submitted to sourceforge as patch

[Thomas M. <mat...@ph...>]

On 8-Mar-06, at 10:34 AM, Hans-Bernhard Br=F6ker wrote:

>
> drand48() cannot be used like that.  It's quite a non-portable=20
> function.  Of the compilers I tried so far, only the most dedicated=20
> impersonators of UNIX (DJGPP and real Cygwin) have it.

On 9-Mar-06, at 5:56 AM, Hans-Bernhard Br=F6ker wrote:

> Thomas Mattison wrote:
>
>> Yeah, I wondered whether that would be sufficiently portable.
>> Is there a random generator internal to gnuplot that I should use?
>
> Hmm, we do have specfun.c:ranf().  That should fit the bill.

I looked at specfun.c.  There's something declared
static double ranf(struct value *init)
but it's not visible outside specfun.c, and I didn't know what to do
with the struct value* .
There's also in specfun.h something declared
void f_rand __PROTO((union argument *x))
but returning void doesn't help me much.

> ["TM" is Thomas Mattison, HBB are my, Hans-Bernhard Broeker's,=20
> comments]
>
> 4.  Zero-change in chisquare is now "BETTER" rather than "WORSE"
>
> TM: Previously, if the exact minimum of chisquare was found, so the
> chisquare change was zero, this was called "WORSE" in
> marquardt().  The loop in regress() didn't exit, and further
> iterations were done, which were also "WORSE" and increased
> lambda until the upper limit on lambda or iterations was
> reached.  This was a waste of time, and potentially confusing,
> for no benefit.
>
> HBB: I'm not entirely sure about this one.  There could be other
> reasons for a failure to find an improvement besides having found a
> well-defined optimum.  An extended flat minimum, or a pair of local
> minima, say.  Giving up the Marquardt process immediately when the
> Newton iteration admits defeat seems to defeat the purpose of doing
> the Marquardt.

I think it would be hard to construct a test case where an iteration
produces EXACTLY zero change in chisquare, where the following=20
iterations
succeeded in improving the chisquare.  The only cases I can think of
where the chisquare change would be EXACTLY zero are that the parameters
are already at the minimum to machine precision, or the value of lambda
is so large that the parameter steps are so small that the chisquare
doesn't change.  In the first case, it's OK if we stop iterating.  In
the second case, a result of WORSE will make lambda even bigger, so
the next step will be even smaller, so it will also produce zero change
in chisquare.

But it is fairly easy to construct a case where the present code does
something that would likely confuse a user. As the iteration approaches
the minimum, the calculated parameter changes _should_ get smaller and
smaller, and eventually get so small that the chisquare does not change
to machine precision.  Gnuplot's default convergence limit of 1e-5
relative change in chisquare is pretty loose, so convergence is=20
typically
declared before this happens.  But if you reduce FIT_LIMIT to much
smaller values, you will find that in most cases, the fit gets to a=20
point
where further iterations no longer change the chisquare.  If this is=20
defined
as WORSE, then the iteration would continue forever.

Obviously there would be many complaints if this actually happened.  The
reason it doesn't happen is that there is _another_ way to exit that=20
loop.
When the chisquare is WORSE, then lambda is increased, and the loop=20
exits
on maximum lambda value.  The existing code does NOT print a message=20
that
the maximum lambda has been exceeded.  What it prints is that the fit=20
converged.

I know from experience teaching with gnuplot that lots of users make=20
mistakes
that cause "convergence" to nonsense.  Ideally, if gnuplot knows that=20
the fit
hasn't converged properly, it should tell the user that.  Having lambda=20=

hit
the maximum should be a sign that the fit has not converged.  I have=20
added a
print statement that tells the user the truth when the fit has=20
terminated
because lambda hit the maximum.  But in order for this to be useful, we=20=

need
to make sure that this _isn't_ printed for a fit that has actually=20
found the
minimum.  The way to do that is to make EXACTLY zero change in chisquare
be BETTER instead of WORSE, so the loop exits then, rather than waiting
for lambda to hit the limit.


> 5.  Final parameter cleanup fixes
>
> TM: The gnuplot internal variables for the fit parameters may contain
> values from an iteration that made the chisquare worse rather
> than better, if the loop in regress() terminates due to maximum
> iterations or maximum lambda rather than convergence.  There was
> code at the end of regress() that restores the internal variable
> for only the last parameter (for a different reason: the last
> variable is altered in call_gnuplot() to calculate derivatives,
> but not restored there).  I changed the code at the end of
> regress() to restore _all_ internal variables, from the array
> that contains the parameters that gave the best chisquare so
> far.
>
> HBB: this feels risky, at first sight.  regress() keeps more state =
than
> just the parameters --- restoring the parameters could leave them out=20=

> of
> synch with the rest, e.g. the correlation matrix and chisquare.

I looked again and I think it's OK.  The parameters array a[] and the
derivatives matrix C[] that is used for the error and correlation=20
calculation
in regress() are calculated inside marquardt().  They are always in=20
synch
with each other, and what regress() has is always from the best=20
chisquare
that marquardt() has seen, and the chisq variable is that value.


> TM: I also put a copy of the last-parameter-only fix code
> into call_gnuplot(), where it logically belonged anyway.
>
> HBB: I don't think that's correct.  call_gnuplot is not supposed to=20
> know how
> fit's numeric derivation method works.  It should just plug in the
> parameter values and evaluate.

You're right, because I made a mistake in my note, not the actual code.
I actually put the last-parameter-only fix code into calculate(), not
call_gnuplot().  calculate() is the function that perturbs the internal
variables for the derivative calculation, not call_gnuplot.  The change
is just to undo the perturbation for the last parameter, just like
is done for all the other parameters.

> TM: Without this, if the user interrupted the fit and tried to
> plot the current function on top of the data, the last
> internal parameter was not correct.
>
> HBB: in that case, the fit interruption handler is what needs fixing,
> not call_gnuplot

That would be another way of fixing things, but is there any significant
reason why calculate() should not undo the perturbation of the last
parameter that it had just done?


>
> 6.  Changed convergence criterion, with new user-variable=20
> FIT_LIMIT_ABS.
>
> TM:
> [...]
> less than epsilon.  But if the chisquare was less than
> NEARLY_ZERO =3D 1.0e-30, (which could happen if fitting data with
> magnitude less than 1.0e-15 with no errors), the old criterion
> was _absolute_ change in chisquare less than epsilon.  Any
> change in chisquare would probably be less than epsilon in
> these cases, so the fitter would announce convergence
> immediately rather than finding the minimum.  Users would
> probably prefer the default relative convergence criterion in
> these cases,  but there was no way for them to impose it.
>
> HBB: I have to disagree here.  Of course users could impose a
> change: they could supply the missing error values.  Fake them by a
> constant, if they must.  I know I tend to be a bit harsh on users
> in this regard:  I think there is a threshold of how easy it should
> be made to abuse a tool.  The above change is still OK, but IMHO
> it's getting a bit close to that threshold.


You're right that there is _something_ that they could do.  They could
either supply sensible errors so they have a real chisquare which would
not be 1e-30.  Or they could re-scale their data even without errors
so the "chisquare" came out in the range that works.

But this looks like a case where it's easier to fix the code so it works
even when somewhat abused, rather than explaining what constitutes=20
abuse,
why it causes the problem, and how to get the results they want.
We advertise gnuplot fits as working even if errors are not supplied,
and this is a case where they don't work properly.  It's easily fixed,
and the change just simplifies both the code and the explanation of
what the code does.  So why not?


>
> 7.  New one-line progress-report, revert by FIT_CLASSIC_PROGRESS =3D 1
>
> TM: (except to print an asterisk).  It printed  "WSSR" with no
> explanation that this means weighted sum of squared residuals,
> rather than the more common term "chisquare".
>
> HBB: the meaning of all abbreviations is explained in the
> documentation.  There's no excuse for user not reading the documention
> of a tool as complex as this.  Considerable work has gone into that
> documentation in the past.  One result of much deliberation during =
that
> activity was was to call that quantity WSSR, instead of chisquare.
> I'd rather not go through all that again.

Ah, if they would only read documentation....

Is the discussion you mention recorded anyplace?  I'd like to see the
arguments.  In my experience (undergrad physics as student and
professor, grad school and beyond in experimental particle physics,
sound's a lot like you actually), chisquare is by far the more
common name.

But it's easy to change my column label to WSSR if that's really
more universally understood, or even to SSR for no-errors fits
and WSSR for fits with errors.


> TM: The new report
> is one line per iteration, with everything in neat columns so
> it's easy to track the progress.
>
> HBB: ... but only for fits with less sufficiently few parameters to
> all fit in one line.  Please try to keep in mind that not everybody
> uses text consoles 200 or more characters wide...
>
> TM: The user can
> revert to the old progress report show_fit() by setting
> FIT_CLASSIC_PROGRESS =3D 1.
>
> HBB: Good --- because otherwise, all those users out there who have
> scripts parsing fit.log and/or console output of gnuplot would cause
> a mighty ruckus.

I considered adding line breaks, but decided against it.  They don't
solve the readability problem for narrow consoles, compared to letting
the text wrap.  And they make the output less useful for people who do
use wide consoles and/or capture the output for display in some other
program that can scroll horizontally.  And remember that the old multi-
line output has a different problem:  there is a limit to how many
iterations will be visible on a terminal or scroll-buffer.  To me,
the old progress report was very hard to use as a progress report,
and I think most people only looked at the final results.  The new
progress report is more likely to be useful as a progress report,
even if it's not perfect for all users, which nothing ever is.


>
> 8.  New final fit parameter report format, revert by=20
> FIT_CLASSIC_RESULT =3D 1
>
> TM: The old default final report label "final sum of squares of
> residuals" was misleading because if the user supplied errors,
> the number printed  was the chisquare (_weighted_ sum of
> squared residuals or WSSR). The new report labels are
> "chi-squared, "degrees of freedom," and "chisq/ndf"
>
> HBB: see above note about nomenclature and documentation.

I'm open to debate about what to call things.  But part of my
point was that what we print means different things if the
user supplies  errors vs not supplying errors.  So we should
have different labels in the different cases.


> 9.  Error-rescaling control
>
> TM: user supplied errors or not.  This means that the internal
> variables for parameter errors (not default, but available
> through recompiling with a preprocessor option)
>
> HBB: Assuming you're referring to GP_FIT_ERRVARS there:
> that build option is supposed to be turned on by default, these days.
>
> TM: and the
> (non-default) old-style result report always give only rescaled
> errors, as before, unless someone changes the source and
> recompiles.
>
> HBB: this could be quite bad.  Changing the meaning of a=20
> machine-readable
> entity like the parameter error variables is a recipe for utter=20
> confusion.
> Please consider introducing a different set of error variables for the
> new-style errors.  There has to be a way for users'
> scripts to get at the exact same values they used to get, or at least
> to detect that the numbers now stored in the same places now mean=20
> something
> different.

I guess I wasn't clear.  My code does _not_ (presently) change the=20
values
calculated for the user-accessible variables created when GP_FIT_ERRVARS
is turned on.  The calculated errors are re-scaled using the actual
fit "chisquare" like they were before.  And if the user reverts to the
old-style final result report, they will get the same rescaled error
values as before.

I only included a comment to make it obvious how to change the source
code so the GP_FIT_ERRVARS error variables would only be rescaled by
the chisquare when the fit is done without user errors, which I think
is the right thing.  Another solution would be to create another
conditional-compile flag, but I didn't do it that way.

I don't advocate doubling the number of fit-error variables created,
I think that would be much more confusion than it's worth.

I do advocate changing the default behavior.  It's statistically wrong=20=

to
rescale the errors according to the chisquare, if the user provided=20
valid
errors.  If we repeat the same experiment and fit many times, the data=20=

will
have statistical fluctuations, the fit parameters will have statistical
fluctuations, and the chisquare will have statistical fluctuations. =20
But it's
not true that the fits that with lower chisquare are more closely=20
clustered
around the true parameter values.  They should not be assigned smaller=20=

errors.

Apparently some commercial fitting packages make this mistake also.
For instance, see http://physics.gac.edu/~huber/fitting/aapt2001.ppt
But it's still a mistake.

For the new default final result report, both raw and rescaled errors
are printed, and the code correctly prints both errors labelled properly
whether the rescaling variable is set to old-style GP_FIT_ERRVARS=20
values,
or to what I consider to be the right calculation.


> 10.  Gnuplot-readable parameters and errors in one line in fit.log =
file
>
> HBB: I'm against this.  fit.log is the wrong place for this data.
> It's much more similar to what the 'update' command already does, so =
if
> this feature is added, it should go there, not into fit.log.

The point is that I want to _append_ many fit results to a
gnuplot-readable file, so the results from many similar fits
could be conveniently plotted along with their errors.  The
file from the update command doesn't seem to be appropriate for
appending results from many fits.

Can you give a reason _why_ fit.log is the wrong place?
Recall that in the exchange we had in the fall, I suggested making a
new fit-summary output file that would contain _only_ lines like this,
and your answer was

> I think it would make a lot more sense to add a couple lines to=20
> 'fit.log'
> instead of creating what would be an almost complete copy of all of=20
> its content.

So would it be best to go back to my original proposal
of a separate new file that contained only appended
one-line summaries with errors?


> 13.  Parameter step size limit, controlled by FIT_MAX_PAR_STEP
>
> TM: function LimitParSteps() called by marquardt() to scale down the
> steps in all parameters so the ratio of any parameter change to
> its value is no larger than internal variable maxParStep.
>
> HBB: It's been a while since I rewrote this Marquardt-Levenberg
> code, and I don't have my textbooks at hand,  but:
> this 'limit the step size' looks awfully like a duplicate of
> what Marquardt's lambda parameter is designed to do.  Even if it's not
> an exact duplicate, this seems to almost beg for a fight between
> those two mechanisms over who gets to decide how big the step sizes
> should be...
> Couldn't the same effect be had by a simple penalty on the chisquare
> to steer the existing algorithm away from those regions?

It's not a duplication of what lambda does, it addresses a different
problem.  On the first iteration of a nonlinear fit, particularly if
the initial parameters are poor, the first parameter step may be
to a region where the function is not even defined, which results in
a failure.  Lambda doesn't reliably prevent this, because it can take
several iterations for lambda to increase far enough to limit step
sizes by itself.

For an example, try fitting my demo/newfit/newfit5.dat
with a*exp(b*x) with starting parameter values a=3Db=3D1 with old =
gnuplot.
You will get "Undefined value during function evaluation".

My modified version of gnuplot would print the extra information
that a=3D229 and b=3D7869 for the next trial, which is why the =
calculation
of the function blows up.  But with the default FIT_MAX_PAR_STEP =3D =
1.5,
it increases the value of a and b slowly enough that the function is
never undefined (although it still converges VERY slowly unless you
use FIT_SKEPTICAL =3D 1)

The two mechanisms cooperate nicely.  The new mechanism doesn't=20
interfere
with convergence once the steps are small.  It just keeps things from
running away before a reasonable value of lambda has been established
by the iteration.

The chisquare already penalizes the regions we are talking about,
the problem is that sometimes first steps are so large that the function
can't even be evaluated to calculate the chisquare!


> 14.  Scale-independence through multiplicative lambda,
> revert by FIT_CLASSIC_LAMBDA =3D 1
>
> TM: implementation is "multiplicative", which is dimensionless and is
> insensitive to parameter scale differences.  The implementation
> in gnuplot is "additive" which makes the performance sensitive to
> the relative scale of parameters and errors.
>
> HBB: I must admit you've lost me there.  Could you pass me some
> references about these two different lambda's?

I don't have a textbook or article reference, other perhaps than
Numerical Recipes (which uses multiplicative and doesn't mention
the other possibility).  Basically, you write the chisquare sum,
take the derivatives with respect to the parameters, and set them
to zero, to get N nonlinear equations in the N unknown parameters.
Then you linearize those equations, resulting in an N by N matrix
which I call the weight matrix, which is the inverse of the covariance
matrix.  The weight matrix isn't explicitly calculated in the gnuplot
implementation, but it's C times its transpose.  For a linear problem
the parameter step is the inverse of the weight matrix times the vector
of sum of residuals over errors times parameter-derivatives, and
iteration is not needed.  For a nonlinear problem, the resulting
parameter step is not optimal, and may increase the chisquare.

The Levenberg-Marquardt trick is to increase the diagonal
of the weight matrix (the diagonal elements are always positive),
so the elements of the inverse are smaller, and the parameter steps
are smaller.  If the diagonal is increased so far that the off-diagonal
elements are negligible, then the parameter steps are in a direction=20
that
is guaranteed to decrease the chisquare, but the steps will be small.

Additive lambda means add the same number lambda to each element
of the diagonal of the weight matrix.  Multiplicative lambda means
multiply each diagonal element by (1+lambda).  For multiplicative=20
lambda,
lambda=3D1000 would result in each parameter changing by 1/1000 of
the distance from its present value toward the value that would minimize
chisquare if all other parameters were held fixed for a linear problem.

If the elements on the diagonal are all about the same size, it makes
little difference whether you use additive or multiplicative lambda.
But when the elements are very different, and lambda is much bigger
than some elements and much less than some others, some parameters
are not affected by lambda and converge quickly, while others are
frozen by lambda and don't change.  So you can have false convergence.

> =46rom what I'm aware
> of the, usual approach against parameter scale differences is not
> a change to the handling of lambda, but of the parameters.  I.e.=20
> instead
> of minimizing with respect to the actual problem parameters, all=20
> parameters
> are modelled as factor*initial_value, with the factors all starting at=20=

> 1.0,
> and only the factors are minimized by the algorithm.  This makes them=20=

> all the
> same scale initially.  The only drawback is that the fit is no longer
> idempotent, i.e. re-running the fit with the converged results from an
> earlier fit can yield different results.  That's what MINUIT does, as
> far as I remember from reading its docs.

It's true that a sophisticated user can rescale the problem to=20
circumvent
the problems with additive lambda.  But that's never necessary with
multiplicative lambda.  I think multiplicative is a better default,
because it's scale-independent and it's easier to interpret the lambda=20=

value.

But it is true that some problems just seem to converge faster with
additive lambda than multiplicative lambda, so it's useful to keep both.



> 16. Monte Carlo search for initial fit parameters
>
> HBB: Nice.  So all we now miss for a complete typical fitting
> mess-of-tools is the Nelder-Meade Simplex search algorithm.
> Oh, and about 100 pages of documentation explaining all this to
> gnuplot users who don't have anywhere near the experience it takes
> to avoid hurting themselves with such a mighty tool chest (whether
> by shooting themselves in the foot, or by dropping the chest on =
it...).


I thought about adding simplex, but from what I've read and heard,
its main strength is dealing with discontinuous derivatives, which
chisquare fits don't normally have (though it might do better on the
original hemisphere-fit demo problem....)  But the gain didn't seem
to be big enough often enough to be worth creating the new controls.

But the Monte Carlo search solves a more common problem: finding
a reasonable starting point, particularly if there can be multiple
minima.  It needs extra user input for the ranges, so I hesistated,
but realized that the parameter-file mechanism could let me add it
in a way that wouldn't burden people who didn't need/want it.

Re: fileexist(f)

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

Ethan Merritt wrote:
> On Thursday 09 March 2006 09:03 am, Hans-Bernhard Br=C3=B6ker wrote:
>=20
>>What's the point of asking a question like "if fileexists", when
>>there's nothing useful that could be done with the answer, that we
>>can't already do later on, when a command actually tries to read it?=20

I have to agree with Hans, too, Petr.  If I understand, the idea is to mo=
nitor if a data file changes, then replot it.  Or is it something else?  =
I guess I'm looking for a bigger context of this.  It just seems like som=
ething better dealt with using a little utility or daemon that monitors t=
he file then simply reissues the gnuplot command through a pipe.

At the same time, I'm wondering why gnuplot should plot something if any =
of its specified input files are not present.  Shouldn't there be an erro=
r? =20

Now, Ethan raised an issue in one of our discussions about some method fo=
r conditionally checking the functionality of gnuplot so that the demos d=
on't fail if something isn't compiled inside gnuplot, rather they are sim=
ply skipped using proper adjustment of, say, all.dem.  If that method exi=
sted, might it be possible to use that kind of thing for checking file ex=
istence of a file?

>=20
>=20
> I am in 100% agreement with you.
> The discussion of Petr's xxx_exist() functions was a spin-off
> that was probably a total waste of time.
>=20
> My preferred method of dealing with this issue is to handle
> missing/empty files cleanly during the plotting process.
> That is relatively straightforward for 2D plotting from ascii
> files, and I have already posted a patch that does so.
>=20
> The code for binary files is a mess, and the 3D code
> is very different from the 2D code.  So far I do not see an
> easy way to modify these code paths to handle missing files.

This seems to be a clear case where any code for checking the existence o=
f a file should be at a higher level than binary/ascii/3D/2D.  Are you sp=
eaking about the options part of binary?  Or at a lower level of input on=
ce the options string has been processed?

> Should I go ahead and apply the patch for 2D code,
> which is after all a major category of use?
>=20
> If inspiration (or code clean-up) strikes for the 3D/binary
> case we can deal with that later.  For the present it would
> remain a known limitation that 2D plots can handle missing
> files cleanly, but 3D plots cannot.

Could it be written generic?  A little routine that can be called by the =
options handling no matter if it is 2D, 3D, ascii or binary?  (We're talk=
ing at the options, level, right?)

I can probably help out with short patches on say, regarding what came up=
 the other day (below), but I'd prefer some unification eventually.

Dan

*****

An alternative might be to move just this chunk of code:

#ifdef HAVE_SYS_STAT_H
       struct stat statbuf;

       if ((stat(df_filename, &statbuf) > -1) &&
           !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
           os_error(name_token, "\"%s\" is not a regular file or pipe",
                    df_filename);
       }
#endif /* HAVE_SYS_STAT_H */

which I think sort of checks the existence of the file without really ope=
ning it.  And replace it with

#ifdef HAVE_SYS_STAT_H
       struct stat statbuf;

       if ((stat(df_filename, &statbuf) > -1) &&
           !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
           os_error(name_token, "\"%s\" is not a regular file or pipe",
                    df_filename);
       }
#else
    if (<open fails>)
        error("Can't open data file "xxx"");
    else
        close_file();
#endif /* HAVE_SYS_STAT_H */

Would that kind of thing work?  That would mean if there is no "stat()" t=
hen the file would be opened and closed for checking existence (also chec=
k for emptiness?), then after options are checked opened again for readin=
g.

Or would you prefer opening and keeping track of the file pointer and doi=
ng a "close" before each instance of "error()"?=20

Re: [ gnuplot-Patches-908040 ] Break PostScript prologue file out of post.trm

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

Responding on the list because SourceForge is acting up.

> - in cvs, shouldn't they be in src/PostScript instead of
> term/PostScript? The usual place for terminal specific files
> is in src/

Usual place?
What examples are you thinking of?
So far as I know, driver files are in .../term
Things like gnuplot_x11 are in .../src because they are
separate programs, not drivers.

> - I did  ./configure --prefix=/tmp, but plotting to ps file
> does not work:
> Can't find PostScript prologue file "a.gp", line 5:
> ${prefix}/share/gnuplot/4.1/PostScript/i8859-2.ps

Ouch.  That seems to be a problem with the autoconf
commands.  It is not specific to the new option.
If you look, you'll see that the help directory is
similarly set to
    GIHDIR = ${prefix}/share/gnuplot/4.1
I'll need help to fix this one.

> They are in /tmp/share/gnuplot/4.1/PostScript ... 

That's what you asked for

> amazingly,  with chmod +x ?

That is the default for the INSTALL macro.
But I can override that, I think.  Thanks for pointing it out.

> I propose to look also to directory
> inside loadpath (including GNUPLOT_LIB).

What loadpath are you talking about?
GNUPLOT_LIB is not defined by default, but I don't
mind looking there if other places fail.  
Do you propose search order:

	./
	GNUPLOT_PS_DIR/
	GNUPLOT_LIB/


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

Re: fileexist(f)

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

>
> Based on the discussion: it is fully sufficient to have fileexist()
> for testing whether the given file exist. Nothing more (no pipes, no
> loadpaths). 

I did not conclude that from the discussion I saw.
I think if you have such a thing at all, it must handle pipes
and loadpaths.  Otherwise what is the point of testing?

But I also agree with Hans-Bernhard that such a specialized yet
system-dependent function does not belong in gnuplot at all.
It is sufficient to use whatever system-dependent shell command
matches your use. I gave several examples already.

> > My preferred method of dealing with this issue is to handle
> > missing/empty files cleanly during the plotting process.
>
> Gnuplot support files with palettes as well.

Sorry, I am not understanding you there.
Are you complaining that my missing-files patch doesn't
handle PM3D or other 3D plot modes?  I'd welcome your
help in untangling the code in plot3d.c/graph3d.c so that
missing files can be skipped cleanly.


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

Re: fileexist(f)

[Petr M. <mi...@ph...>]

>> What's the point of asking a question like "if fileexists", when
>> there's nothing useful that could be done with the answer, that we
> I simply don't believe that either of these functions does something that 
> gnuplot has to do, or even *can* do meaningfully.

The fileexist() is a long time on my done list, I needed that several times, 
so finally decided to commit it.

Some applications: number of fit files, availability of extracted 
experimental data files. This function is a good candidate for the group of
string-related functions for the "strings" patch which has become part of 
gnuplot recently.

Based on the discussion: it is fully sufficient to have fileexist() for 
testing whether the given file exist. Nothing more (no pipes, no loadpaths). 
Thus I still wish to commit it (unless there is really still big big 
opposition).


> My preferred method of dealing with this issue is to handle
> missing/empty files cleanly during the plotting process.

Gnuplot support files with palettes as well.


> Should I go ahead and apply the patch for 2D code,
> which is after all a major category of use?

Yes.


>> Trimmed from lines 1240-1280 of datafile.c:
>> =========================================================================
>>    /* filename cannot be static array! */
>>    gp_expand_tilde(&df_filename);
> This line makes sense only for regular files and thus it should be moved 
> to just above the "stat" function.

And this change should be committed too.

---
PM

Re: fileexist(f)

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

On Thursday 09 March 2006 09:03 am, Hans-Bernhard Br=C3=B6ker wrote:
> What's the point of asking a question like "if fileexists", when
> there's nothing useful that could be done with the answer, that we
> can't already do later on, when a command actually tries to read it?=20

I am in 100% agreement with you.
The discussion of Petr's xxx_exist() functions was a spin-off
that was probably a total waste of time.

My preferred method of dealing with this issue is to handle
missing/empty files cleanly during the plotting process.
That is relatively straightforward for 2D plotting from ascii
files, and I have already posted a patch that does so.

The code for binary files is a mess, and the 3D code
is very different from the 2D code.  So far I do not see an
easy way to modify these code paths to handle missing files.

Should I go ahead and apply the patch for 2D code,
which is after all a major category of use?

If inspiration (or code clean-up) strikes for the 3D/binary
case we can deal with that later.  For the present it would
remain a known limitation that 2D plots can handle missing
files cleanly, but 3D plots cannot.

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

Re: fileexist(f)

[V. <gae...@no...>]

On Thu, Mar 09, 2006 at 06:03:57PM +0100, Hans-Bernhard Br=F6ker wrote:
> gnuplot is a plotting program.  It's not a command-line shell, and it's=
=20
> not a full-featured script language processor.  Nor, IMHO, should it tr=
y=20
> and become either of those.

    I fully agree with this point.

	Ga=EBl

Re: fileexist(f)

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

Ethan Merritt wrote:

> Huh?  But that is quite broken.  If you read from that data source,
> even 1 byte, then you have poisoned it for actual plotting.

Not necessarily.  If you do it via <stdio.h> functions, you can still 
use fungetc() to put the djinn back into the bottle.  But the real 
problem is, of course a different one: blocking I/O. If you try to read 
from an existing stream, but there's nothing in it, gnuplot may just sit 
there and wait forever

> Anyhow, my main point is that an   xxx_exists()  routine should be
> exactly parallel to the routine used for actual data input.  

I had given up on following this discussion for a while, because I still 
maintain a rather more serious doubt.  The length at which you guys have 
discussed the vagaries of implementing this features brings me back to 
that issue:

I simply don't believe that either of these functions does something 
that gnuplot has to do, or even *can* do meaningfully.

gnuplot is a plotting program.  It's not a command-line shell, and it's 
not a full-featured script language processor.  Nor, IMHO, should it try 
and become either of those.

What's the point of asking a question like "if fileexists", when there's 
nothing useful that could be done with the answer, that we can't already 
do later on, when a command actually tries to read it?   Why ask if the 
bridge is there before you come to it?  What's the assumption based on 
that this file should exist, but maybe it doesn't?  AFAICS, it's based 
on the fact that somewhere a program is running that is supposed to 
create that file.  So what makes it gnuplot's job to check for this event?

It's not as if gnuplot had thousands of other terribly important things 
to do that it should take care of while some other program sets up that 
file.  So why was gnuplot started or that script loaded, before the 
datafile was ready?  We're not the shell.  We're just another program. 
So if some other program is to create a data file and then gnuplot 
should read that file, the right place to ensure that sequence is in the 
other program, or in the shell.  gnuplot is the wrong place to do this.

Worse yet, existence of a file is rather certainly not even the 
information we actually need about that file in the first place.  We 
need to know whether whichever process is writing that file considers 
itself done with it.  There's *no* way at all we could deduce that from 
looking at the file.  It's not even worth trying.

So to sum it up: I really don't see why we would need these functions. 
And given the apparent complexities of implementing it,  I strongly 
suggest we just drop this plan.  It's getting us nowhere we should be.

Re: fileexist(f)

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

On Wednesday 08 March 2006 01:26 pm, Petr Mikulik wrote:
> >>    pipeexist(s) which returns 1 for "-" and 1/0 whether it is a
> >> pipe wherefrom you can read at least 1 byte;
> >
> > Huh?  But that is quite broken.  If you read from that data source,
> > even 1 byte, then you have poisoned it for actual plotting.
>
> I don't think so. plot '<awk {blalbal} bla.dat' gives always the
> same. Can you give an counter-example?

Any real-time data source?
A keyboard input stream?
A pipe to another interactive program?

> >> The truth is that popen() "never" returns NULL
> >> (contrary to specification) -- at least for OS/2, Windows, Linux.
> >
> > On linux it returns NULL if the pipe open fails.
>
> No, it does NOT! Try it!
> popen("bla bla", "r") does not return NULL

It does not return NULL in that case because it successfully opened
a pipe to the forked command "/bin/sh bla bla".   The forked shell
itself returned an error ("command not found").
But there is no pipe failure here.  

> I would prefer no system error message at all.

Then you must configure your shell environment to not
print an error.  This is being printed by /bin/sh, not by gnuplot.
The fact that it is printed at all is an indication that the popen()
did in fact succeed.

> But popen() did not return NULL. So I must read at least one byte.

You are looking in the wrong place for the error return.
If you want to do error checking, you need something like this:

--- gnuplot/src/datafile.c      2006-01-27 08:36:48.000000000 -0800
+++ gnuplot-cvs/src/datafile.c  2006-03-08 14:25:53.000000000 -0800
@@ -1343,7 +1343,9 @@
     if (!mixed_data_fp) {
 #if defined(PIPES)
         if (df_pipe_open) {
-            (void) pclose(data_fp);
+            int ierr = pclose(data_fp);
+           if (ierr)
+               fprintf(stderr,"pipe error %s\n",strerror(ierr));
             df_pipe_open = FALSE;
         } else
 #endif /* PIPES */

With that patch in place, your test example gives:

gnuplot> plot "< bla bla"
  sh: bla: command not found
  pipe error Unknown error 32512

I'm not sure how to make it print a more interpretable error message
string, but I assume that 32512 in fact means "command not found".

> > Anyhow, my main point is that an   xxx_exists()  routine should be
> > exactly parallel to the routine used for actual data input. 
> > Otherwise you cannot trust the result as an indication of whether
> > you will or will not be able to plot it.   Thus it should handle
> > both files and pipes, because the data input routine handles both
> > files and pipes.
>
> Then I propose   streamexist()  that would do all of that; it would
> be equivalent to
>  	if (fileexist(file_in_path(x)) || pipeexist(x))

OK, but the pipe part of the test must not actually read any data.


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

Re: fileexist(f)

[Petr M. <mi...@ph...>]

>>    pipeexist(s) which returns 1 for "-" and 1/0 whether it is a pipe
>> wherefrom you can read at least 1 byte;
>
> Huh?  But that is quite broken.  If you read from that data source,
> even 1 byte, then you have poisoned it for actual plotting.

I don't think so. plot '<awk {blalbal} bla.dat' gives always the same.
Can you give an counter-example?

> That's no good.  This is a *pipe*, not a file.  You cannot
> necessarily go back to the beginning and read that byte a
> second time.

I do pclose().


>>>    /*{{{  open file */
>>>    if (*df_filename == '<') {
>>>        if ((data_fp = popen(df_filename + 1, "r")) == (FILE *)
>>> NULL) os_error(name_token, "cannot create pipe for data");
>>
>> This will never work.
>
> ???
> But this is what the code does *now*.
> Are you saying that the current pipe code doesn't work for you?
>
>> The truth is that popen() "never" returns NULL
>> (contrary to specification) -- at least for OS/2, Windows, Linux.
>
> On linux it returns NULL if the pipe open fails.

No, it does NOT! Try it!
popen("bla bla", "r") does not return NULL

>> gnuplot> plot '<bla'
>> sh: bla: command not found
>
> This is the correct error message.
> There is no command "bla", so you cannot pipe its output.

I would prefer no system error message at all.

> On the contrary.  The pipe failed because there is no such command,
> and that is the most enlightening error message.

But did not return NULL. So I must read at least one byte.

> Anyhow, my main point is that an   xxx_exists()  routine should be
> exactly parallel to the routine used for actual data input.  Otherwise
> you cannot trust the result as an indication of whether you will or
> will not be able to plot it.   Thus it should handle both files and
> pipes, because the data input routine handles both files and pipes.

Then I propose   streamexist()  that would do all of that; it would be
equivalent to
 	if (fileexist(file_in_path(x)) || pipeexist(x))

---
PM

Re: fileexist(f)

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

On Tuesday 07 March 2006 02:44 pm, Petr Mikulik wrote:
> > Then it needs yet another routine pipeexist().
>
> So, now there are (patch enclosed) both
>    fileexist(s)
> which detects regular files, and
>    pipeexist(s) which returns 1 for "-" and 1/0 whether it is a pipe
> wherefrom you can read at least 1 byte; 

Huh?  But that is quite broken.  If you read from that data source,
even 1 byte, then you have poisoned it for actual plotting.
That's no good.  This is a *pipe*, not a file.  You cannot 
necessarily go back to the beginning and read that byte a
second time.

> that's because: 

> > Trimmed from lines 1240-1280 of datafile.c:
> > ===================================================================
> >====== /* filename cannot be static array! */
> >    gp_expand_tilde(&df_filename);
>
> This line makes sense only for regular files and thus it should be
> moved to just above the "stat" function.
>
> >    /*{{{  open file */
> >    if (*df_filename == '<') {
> >        if ((data_fp = popen(df_filename + 1, "r")) == (FILE *)
> > NULL) os_error(name_token, "cannot create pipe for data");
>
> This will never work.

??? 
But this is what the code does *now*.
Are you saying that the current pipe code doesn't work for you?

> The truth is that popen() "never" returns NULL 
> (contrary to specification) -- at least for OS/2, Windows, Linux.

On linux it returns NULL if the pipe open fails.
OK, that's almost never, unless you have exceeded your quota for
open files. That is different from the case where the pipe is opened
but nothing can be read.

>
> gnuplot> plot '<bla'
> sh: bla: command not found

This is the correct error message.
There is no command "bla", so you cannot pipe its output.

> gnuplot> plot '<bla'
>                      ^
>           no data point found in specified file
>
> The last message seems to be the most proper one, while "sh: bla:
> command not found" is something unwanted.

On the contrary.  The pipe failed because there is no such command,
and that is the most enlightening error message.   

"no data point..." would be correct if the pipe was successfully opened, 
but the data stream contained no valid points.  That can happen also,
but it is a separate error.


Anyhow, my main point is that an   xxx_exists()  routine should be
exactly parallel to the routine used for actual data input.  Otherwise
you cannot trust the result as an indication of whether you will or
will not be able to plot it.   Thus it should handle both files and 
pipes, because the data input routine handles both files and pipes.


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

Re: choose linestyle solid or dashed

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

On Tuesday 07 March 2006 04:52 am, Hartmut Ehmler wrote:
> How can I create a solid and a dashed line of the same color for
> plotting a function?

Please see the demo scripts collection for version 4.1.
The one that answers your question is
	
  http://gnuplot.sourceforge.net/demo_4.1/dashcolor.html


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

Re: fileexist(f)

[Petr M. <mi...@ph...>]

> Then it needs yet another routine pipeexist().

So, now there are (patch enclosed) both
   fileexist(s)
which detects regular files, and
   pipeexist(s) which returns 1 for "-" and 1/0 whether it is a pipe 
wherefrom you can read at least 1 byte; that's because:


> Trimmed from lines 1240-1280 of datafile.c:
> =========================================================================
>    /* filename cannot be static array! */
>    gp_expand_tilde(&df_filename);

This line makes sense only for regular files and thus it should be moved to 
just above the "stat" function.

>    /*{{{  open file */
>    if (*df_filename == '<') {
>        if ((data_fp = popen(df_filename + 1, "r")) == (FILE *) NULL)
>            os_error(name_token, "cannot create pipe for data");

This will never work. The truth is that popen() "never" returns NULL 
(contrary to specification) -- at least for OS/2, Windows, Linux. Or, have 
seen the contrary on some system? It is necessary to read at least 1 B from 
the opened stream, but if popen() fails, then you always see an offending 
message by your system.

See this on Linux:
gnuplot> plot 'bla'
               ^
          can't read data file "bla"
          util.c: No such file or directory

gnuplot> plot '<bla'
sh: bla: command not found
               ^
          warning: Skipping data file with no valid points
                     ^
          x range is invalid


See this of wgnuplot under Wine (pipes disabled):
gnuplot> load 'bla'
                    ^
          Cannot open load file 'bla'

gnuplot> load '<bla'
                     ^
          Cannot open load file '<bla'


See this of wgnuplot_pipes under Wine:

gnuplot> plot 'bla'
               ^
          can't read data file "bla"

gnuplot> plot '<bla'
                     ^
          no data point found in specified file

The last message seems to be the most proper one, while "sh: bla: command 
not found" is something unwanted.


>    } else if (*df_filename == '-' && strlen(df_filename) == 1) {
>        plotted_data_from_stdin = TRUE;
>    } else {
>        struct stat statbuf;
>        if ((stat(df_filename, &statbuf) > -1) &&
>            !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
>            os_error(name_token, "\"%s\" is not a regular file or pipe",
>                     df_filename);
>        }
>        if (!(data_fp = loadpath_fopen(df_filename, df_binary ? "rb" : "r"))
>            os_error(name_token, "can't read data file \"%s\"", df_filename);
>    }

---
PM

Changes to gnuplot fitting submitted to sourceforge as patch

[Thomas M. <mat...@ph...>]

Hi

My changes to gnuplot fitting are now available as a patch at 
sourceforge.

Changes are limited to src/fit.c, demo/fit.dem, and a new directory
demo/newfit, containing details in README.newfit, and many demos.

At present, the patch is constructed more for an audience of developers
to test, rather than for users to install, since the idea is for people
to evaluate it for acceptance into the distribution, rather than for
users to patch a released version.

Please run the demos in demo/newfit to see the effect of the changes.

Re: choose linestyle solid or dashed

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

Hartmut Ehmler wrote:
> How can I create a solid and a dashed line of the same color for plotting a
> function? When I use the different linetypes (in postscript output),
> linetype 1 is always associated with a solid red line and linetype 2 with a
> dashed green line etc. I did not find any possibility of drawing e.g. a
> dashed red line.

You're posting this to gnuplot-beta, so I'll assume you have the 
development versioon.  In that case, the answer is: see the "linecolor" 
option, and use the 'linetype' to select between dot/dash types.

choose linestyle solid or dashed

[Hartmut E. <Har...@ip...>]

How can I create a solid and a dashed line of the same color for plotting a
function? When I use the different linetypes (in postscript output),
linetype 1 is always associated with a solid red line and linetype 2 with a
dashed green line etc. I did not find any possibility of drawing e.g. a
dashed red line.



-------------------------------------------------------
Dr. Hartmut Ehmler
W7-X Basic Device/Magnets
Max Planck Institut fuer Plasmaphysik
Wendelsteinstrasse 1
17491 Greifswald (Germany)

phone: +49 (0)3834/88-2525
fax:   +49 (0)3834/88-2709
email: eh...@ip...
  

Re: fileexist(f)

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

On Sunday 05 March 2006 12:00 pm, you wrote:
> >> The routine fileexist() is for files only; it makes no sense for pipes.
> >> For pipes, do
> >>  	if (fileexist('a.dat')) plot '<tr . , a.dat'
> >
> > Sure. But that is only possible if you already know whether it is a
> > pipe or not.  What about the case where you want to put the
> > fileexist() test in a loadable routine that is passed the filename
> > string as a parameter?
> 
> Then it needs yet another routine pipeexist().

I think you are making these tests way too specific.
Wouldn't it be better to duplicate the code that would actually
be used to open the file while plotting?

Trimmed from lines 1240-1280 of datafile.c:
=========================================================================
    /* filename cannot be static array! */
    gp_expand_tilde(&df_filename);

    /*{{{  open file */
    if (*df_filename == '<') {
        if ((data_fp = popen(df_filename + 1, "r")) == (FILE *) NULL)
            os_error(name_token, "cannot create pipe for data");
    } else if (*df_filename == '-' && strlen(df_filename) == 1) {
        plotted_data_from_stdin = TRUE;
    } else {
        struct stat statbuf;
        if ((stat(df_filename, &statbuf) > -1) &&
            !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
            os_error(name_token, "\"%s\" is not a regular file or pipe",
                     df_filename);
        }
        if (!(data_fp = loadpath_fopen(df_filename, df_binary ? "rb" : "r"))
            os_error(name_token, "can't read data file \"%s\"", df_filename);
    }
=========================================================================

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

Re: fileexist(f)

[Petr M. <mi...@ph...>]

>> The routine fileexist() is for files only; it makes no sense for pipes.
>> For pipes, do
>>  	if (fileexist('a.dat')) plot '<tr . , a.dat'
>
> Sure. But that is only possible if you already know whether it is a
> pipe or not.  What about the case where you want to put the
> fileexist() test in a loadable routine that is passed the filename
> string as a parameter?

Then it needs yet another routine pipeexist().

---
PM

Re: fileexist(f)

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

Ethan Merritt wrote:

Well, the patch Ethan created is in the right area of datafile.c.  In order to have the
 
  Can't open data file "xxx"

take precedence over

  Unsupported file type

I'd say it means rearranging the options string interpretation code and the code that opens the file in "df_open".  That is simply the way it has traditionally been, I guess.  Check options first then attempt opening file.

An easy change, but there needs to be care with one thing.  If the file is opened first, then checked for options, any error in the options will leave an open file hanging around.

An alternative might be to move just this chunk of code:

#ifdef HAVE_SYS_STAT_H
        struct stat statbuf;

        if ((stat(df_filename, &statbuf) > -1) &&
            !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
            os_error(name_token, "\"%s\" is not a regular file or pipe",
                     df_filename);
        }
#endif /* HAVE_SYS_STAT_H */

which I think sort of checks the existence of the file without really opening it.  And replace it with

#ifdef HAVE_SYS_STAT_H
        struct stat statbuf;

        if ((stat(df_filename, &statbuf) > -1) &&
            !S_ISREG(statbuf.st_mode) && !S_ISFIFO(statbuf.st_mode)) {
            os_error(name_token, "\"%s\" is not a regular file or pipe",
                     df_filename);
        }
#else
	if (<open fails>)
		error("Can't open data file "xxx"");
	else
		close_file();
#endif /* HAVE_SYS_STAT_H */

Would that kind of thing work?  That would mean if there is no "stat()" then the file would be opened and closed for checking existence (also check for emptiness?), then after options are checked opened again for reading.

Or would you prefer opening and keeping track of the file pointer and doing a "close" before each instance of "error()"?

Dan


> --- gnuplot/src/datafile.c	2006-01-27 08:36:48.000000000 -0800
> +++ gnuplot-cvs/src/datafile.c	2006-03-03 15:19:13.000000000 -0800
> @@ -1275,7 +1275,9 @@
>          if ((data_fp = loadpath_fopen(df_filename, df_binary ? "rb" : "r")) ==
>  #endif
>              (FILE *) NULL) {
> -            os_error(name_token, "can't read data file \"%s\"", df_filename);
> +            /* os_error(name_token, "can't read data file \"%s\"", df_filename); */
> +	    int_warn(name_token, "Skipping unreadable file \"%s\"", df_filename);
> +	    return -1;
>          }
>      }
>  /*}}} */
> --- gnuplot/src/plot2d.c	2005-11-28 11:02:56.000000000 -0800
> +++ gnuplot-cvs/src/plot2d.c	2006-03-03 15:33:24.000000000 -0800
> @@ -1787,6 +1787,11 @@
>  		++line_num;
>  	    }
>  	    if (this_plot->plot_type == DATA) {
> +		if (specs < 0) {
> +		    /* Error check to handle missing or unreadable file */
> +		    this_plot->plot_type = NODATA;
> +		    goto SKIPPED_EMPTY_FILE;
> +		}
>  		/* actually get the data now */
>  		if (get_data(this_plot) == 0) {
>  		    /* EAM 2005 - warn, but keep going */
> --- gnuplot/src/plot3d.c	2006-01-12 11:55:14.000000000 -0800
> +++ gnuplot-cvs/src/plot3d.c	2006-03-03 15:32:54.000000000 -0800
> @@ -1560,6 +1560,9 @@
>  		struct surface_points *first_dataset = this_plot;
>  		    /* pointer to the plot of the first dataset (surface) in the file */
>  		int this_token = this_plot->token;
> +		/* Error check to handle unreadable or missing data file */
> +		if (specs < 0)
> +		    df_eof = 1;
>  		while (!df_eof) {
>  		    this_plot = *tp_3d_ptr;
>  		    assert(this_plot != NULL);
> 
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: fileexist(f)

[Petr M. <mi...@ph...>]

>>> gnuplot> plot 'demo.edfxxx' binary filetype=auto with image
>>>                                                  ^
>>>          Unsupported file type
>
> recognizing some file in the present working directory?

The error message should be "file does not exist" instead of the above one.

---
PM