Re: 'with pixels' (was Re: Engines are started; ...)

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

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.

Dan