Menu
▾
▴
#1156 "update" requires file to already exist
On gp4.6.0, windows 32bit official build (running on win7 64 bit)
After doing any (sucessful) fit, calling update gives an errormessage, if the file does not exist.
gnuplot> update "testtest.txt"
Could not rename file testtest.txt to testtest.old
error during fit
Also the second filename given in the errormessage isn´t correct, update renames "testtest.txt" to "testtest.txt.old" if the former exists. Lokks like some DOS relict. "error during fit" of course is also misleading.
Well, yes, that's what it does. That's also why the command is called "update", not "write" or "save" --- it updates a set of variable values in that file. That makes no sense without such a file to start off with.
So this is not a bug in the program. It's a bug in the documentation of "update", at most.
But why should the command rely on the file to already exist?
Of course, if it exists, update replaces only the value, keeping comments and ordering, blank lines, etc. intact, otherwise update would have to write the variable names.
To me, this would be quite convenient, and the help really reads as if that was the intended behaviour.
> But why should the command rely on the file to already exist?
Because that the only way it can figure out which variables' values to output. There is no record which variables participated in the last fit, and no particular reason to assume the user couldn't be wanting the variables of the last 13 fit commands to be included.
Otherwise 'update' would have to save all variables, but then it would be identical to 'save variables', which would be pretty pointless.
That "error during fit" message is still present in 4.6.5, and also the documentation has not been changed.
Is there going to be a 4.6.6, making it worthwhile to fix that?
Last edit: Karl Ratzsch 2014-03-23
Strictly speaking the documentation doesn't need to be fixed, because it's correct as-is. It's just a little terse. Note that it reads:
I.e. it expects to be given a file, which means that yes, it is expected to already exist. If it did what you think that meant, that line really would have to read
instead.
True, but why not make the meaning just clear?
A very simple fix, that would have saved us this unfruitful discussion.
actually it´s not true. "update" has nothing to do with "fit". it just updates the values of the variables it finds in the file with the given name.
I think the update function for fitting should in future (post-4.6) be done directly by "fit" (upon users choice, e.g,
that´d remove all ambiguity. "update" would then just stay how it is.
Last edit: Karl Ratzsch 2014-03-23
I´ll add this as a new feature request, this one here gets a bit stuffed.
OK?
In the current CVS version the 'update' command no longer requires the parameter file to exist already. Info retained from the last fit is used to create a new file instead. All current user variables are saved to the new file. The ones which were not varied during the last fit are marked '# FIXED'. Thus the resulting file can be used as input for 'fit' without editing, unlike the output of 'save variables'.
Shouldn´t the file (at least optionally) only contain the variables used in the last fit? If all variables are saved, the fit would restore some completely unrelated variables to a former value.
So you're beginning to understand why it never did that. The user is the only person who can really make a valid distinction between variables related to the fit, and those that are not. The way to make that distinction is to create an initial-value file to be used as part of the 'fit' command. If you insist you don't want to do that, then we'll have to insist you can't use the "update" command.
(That answer from me is a year old, btw., and related to the post from Bastian.)
Bastian says that the version in cvs marks the values not changed in the last fit. So gnuplot obviously does know which ones were fitted last.
I understand this new/changed feature will probably not land in the 4.6 trunk, but at least the documentation and misleading error messages should be fixed. And probably would have been long ago, hadn´t you just dismissed this bug report as invalid.
The whole "fit" subsystem is relatively unfamiliar to me. Compared to the rest of the program I have hardly glanced at the code. So this is just a first thought....
I would prefer to get rid of the "create backup file" functionality altogether. I think it was a half-hearted attempt to provide behavior equivalent to the VMS native filesystem. But gnuplot doesn't do anything like this for other output file, so why should it for this one piece of output from "fit"?
It might come handy in some cases to return to the next-to-last values. I say it can´t be hard to create a backup file.
However i´ve just discovered this here, beware:
# just copy&paste to reproduce
set print "test1"
print "a=1"
set print
fit a "-" via a
1
1
e
# no problem during fit
update "test1"
update "test1"
Last edit: Karl Ratzsch 2014-03-23
Because this is not just output from "fit" --- it's also input to fit ('via "params.txt"'), and input to 'update' itself (controlling which variables to output). And particularly in trial-and-error style fitting, it may be important to have both the initial values from the previous fit and the results from that available. For most such uses the two-file syntax of "update" would be more appropriate, but it doesn't hurt to be helpful.
And it even get´s funny: If you miss the extension of your parameter file (sure that is some old DOS ghoul from the depths of time), this comes up:
# just copy&paste to reproduce
set print "test6.dat"
print "a=1"
set print
fit a "-" via a
1
1
e
# no problem during fit
update "test6"