Many thanks for these comments Simon, that really helps me a lot!
warm regards
David
On 23/04/13 19:30, Simon Urbanek wrote:
On Apr 23, 2013, at 12:43 PM, dpleydell wrote:
Many thanks Simon for your response
Identifying the source of the message is a non-trivial problem because there
are a large number of calls to printf and fprintf etc in several thousands of
lines of code spread over many different *.c files.
There should be none, so apparently you have broken the rules quite a lot ;).
This is not a new rule, R just got better at identifying the transgressions.
Number of lines in your code is quite irrelevant - that's why there is grep and
the search function in editors.
Well, that wouldn't be the first time I've broken rules ;0)
But, how bad could the consequences of my misbehaviour be here? Are we talking
about crashing R or just messing the output a little?
We're not talking life and death here ;) - yes, frustrated users because of
messed up output is the main danger here. Also the behavior changes by GUI and
platform, so throw in inconsistency charge as well.
To be precise, there are two issues: a) the output on stdout/stderr is not
necessarily visible (e.g. the Windows GUI discards it) and it is separate from
the console (e.g. sink() doesn't work on it). More importantly b) it messes up
the use of R in streaming, i.e. uses where you are processing input on stdin
and streaming output on stdout -- it will break the output. This is most
frustrating because the user has no way to control this behavior other than
deleting the offending package.
In Writing R Extensions (current on-line version) the worst they say about
printf is
[QUOTE]
The most useful function for printing from a C routine compiled into R is
Rprintf. This is used in exactly the same way as printf, but is guaranteed to
write to R's output (which might be a GUI console rather than a file, and can
be re-directed by sink).
[UNQUOTE]
and both printf and fprintf are used in section 8.2.2 in the rtest.c example.
Also, the manual does not say explicitly what fprintf should be replaced with.
fprintf() is ok as long as you don't use it with stdout/stderr. You can use it
for files, no problem there.
Come to think of it... my package performs MCMC and uses fprintf to write
samples to an output file. I have noticed that once in each nth blue-moon (for
large n) a single line of output has been dropped or scrambled. More
frequently, the updates of the output file seem to lag behind the progress of
the algorithm's principal loop - for example, file size becomes non-zero much
later than I expect.
Typically, I/O is buffered, so the file is not necessarily updated after you
use fprintf(). By default, it will get updated only after the output buffer has
been filled. You can use fflush() to flush the output buffer to disk
immediately (alternatively you can mark the stream as unbuffered).
I never understood this behaviour or saw how to rectify it. Perhaps replacing fprintf
with something else could "guarantee" the end of this undesirable behaviour?
Great!
Is there a "safe" way to re-write the following?
fprintf(fMCMCout, "%d %e %e ", iteration, posteriorLoglik, parameter);
if (numberRandomEffects > 1) {
for (k=0; k < numberRandomEffects; k++) {
fprintf(fMCMCout, "%e ", randomEffects[k]);
}
fprintf(fMCMCout,"\n");
This is really a question of 2 parts
1) what is the best replacement of fprintf in the above?
If MCMCout is a file, the above is fine.
and
2) Writing R Extensions says "It is wise to write complete lines (including the
"\n") before returning to R.", so is it legal to defer \n as in the example above?
Yes, sure.
Cheers,
Simon
many thanks
David
--
David Pleydell,
INRA,
UMR-1351 CMAEE,
Domaine Duclos,
Prise D'eau,
97122 Petit Bourg,
Guadeloupe
dpleyd...@antilles.inra.fr
pleyd...@cirad.fr
Tel +33 5 90 25 54 42
Fax +33 5 90 94 03 96
--
David Pleydell,
INRA,
UMR-1351 CMAEE,
Domaine Duclos,
Prise D'eau,
97122 Petit Bourg,
Guadeloupe
dpleyd...@antilles.inra.fr
pleyd...@cirad.fr
Tel +33 5 90 25 54 42
Fax +33 5 90 94 03 96
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
