Ethan A Merritt wrote:
>I have not looked much at Daniel's "with image" code, except for
>the terminal API. I am a bit surprised that it needs to call df_readline()
>at all, since I would have expected that reading a binary file is a
>distinct operation from reading successive lines of formatted input.
>Daniel - don't you think it would be cleaner to provide an entirely
>separate routine, df_readbinary(), and call it instead of df_readline()
>when needed? You can never mix the two modes of input (is that right?),
>so it seems a bad idea to mix the code that handles them.
That is correct, and I sort of started out that way. However, the more
I thought about it, it just seemed that the formatted and binary input
really weren't too much different. One can still imagine data inside a
binary file as being in columns, with implicit columns filled in by the
line number, etc.; just like with the formatted I/O. And at the bottom
of df_readline() is the important code which knows how and where to put
data in the v variables, and there may even be some scripts there, as
I don't really understand the "at" stuff and that.
I thought about splitting it off into binary data input, say some
derivative of "df_3dmatrix()" or whatever it is called. However, then
the flexibility like in df_readline() wouldn't be there, unless I copied
parts of df_readline(). Also, if there were a hypothetical
"df_readbinary()" then at the higher levels like plot2d.c and plot3d.c
one would have to know if it is reading a binary data file or a formated
ascii file. You then get these kind of limiting conditional statements
in strange places, and a somewhat big df_3dmatrix() routine.
That is why I proposed earlier that it may be possible to modify what
I've done inside df_readline() so that it reads gnuplot binary. I don't
think it would take too much. The trickiest part is that along the
x-dimension can be a *non-uniform* sampling as described by the very
first line of the gnuplot binary file. So, that needs to be stored in
memory. I've got some ideas, but it probably isn't worth discussing
now... or risking breaking the current df_3dmatrix() way of doing things.
Looking at df_3dmatrix() in datafile.c and all that supporting code in
binary.c, I couldn't see where to put in new binary code. Judging from
the comments with those routines, it looks like someone had in mind to
create arbitrary binary files but maybe gave up. It seems the paradigm
of storing coordinates in the point->x, y, z, dx, dy, etc. format will
not change in the near future, if at all. The free_matrix(),
extend_matrix() etc. seems like a powerful set of routines, but outside
the paradigm of point->x, y, z, dx, dy.