Re: Small technicality on dynarray

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

Ethan A Merritt wrote:
> On Saturday 30 June 2007 12:30, Daniel J Sebald wrote:
> 
>>I'm using a dynarray for the "quick refresh record data etc." patch 
>>(more on this shortly)
> 
> 
> Speak up quickly then.
> I was heading towards putting it in CVS as-is.
> Did you find a problem with it?

Hold on a bit.  I've got something I think you will like that could be integrated into what you have fairly easily.  I'll explain now I guess since I have a prototype that works (but doesn't have a "refresh" command, just a kludged replot).

I don't like that one has to have two forms of "range check", the STORE_WITH_LOG_AND_UPDATE_RANGE and the what is in the patch.  Also, I think it is much preferred if there is no restriction on "refreshing" if log scale is changed.  That's a nice feature.  Losing negative data because of the log scale is almost a no-go for me.

I'm wrapping up a prototype right now in which all data is saved and can be recalled.  However, I punted on my original approach of leaving ->points in un-transformed format.  Although I like the idea of saving the data not processed, there are couple reasons:

1)  I got to the color axis, and it accesses the data a lot and would have required too many AXIS_LOG_VALUE's.

2)  The splines/fitting code alters the data in ->points.  That right there means we must keep a copy of the original points.  OK, in concept that's fine, but not so nice from a programming perspective.

3)  The good thing about STORE_VALUE_WITH_LOG_AND_UPDATE_RANGE() is that it does the work for those cases only where ->xlow, ->ylow, ->xhigh, etc., are used.  If we wait until after all data is collected then we must transform all that data assuming that it is used.

So 4th and 15... The question is then whether there is a good place to tap into the original data.  I think there is.  Rather than save the ->points, we can save the v[]'s and j's (and user specs).  That array is just as compact at the ->points array.  And if we save that, we can stuff that back through the system pretty much at the start of processing.  So, right near df_readline we can put a mechanism that stores or retrieves the v's.  Seems to work.  I'll post that soon.

The only thing that makes me wonder is the case where format information is gotten from a binary file.  We have the j's and v's and specs.  But will something about not being able to open the binary file and find info about format cause a problem?  I don't think so.  We've been pretty careful to isolate that part of the program.  I think we should be fine but not sure on that one point.

I certainly wouldn't want to descend any further (i.e. into the datafile) for storing the original data.  I'd rather it stay with the plot_struct.  You mentioned a volatile file concept.  Is there any advantage to that?  Or do you think the point to tap into the data is where I described?

Dan