|
From: Daniel J S. <dan...@ie...> - 2007-07-01 02:49:10
|
Ethan A Merritt wrote:
> On Saturday 30 June 2007 16:55, Daniel J Sebald wrote:
>
>>>But why would you want to do this?
>>
>>So that the original data is not lost. STORE_VALUE_WITH currently tosses the data.
>
>
> It does not.
It currently does.
if (VALUE<0.0) { \
TYPE = UNDEFINED; \
UNDEF_ACTION; \
break; \
breaks before storing the data.
> We are ignoring the log/unlog case, because it will go away.
How will it go away? That's what I'm trying to point out. Are you saying that one will not be able to use mouse log/unlog scale and "set logscale x", etc. unless the data file is present? (I just tried the patch and that's currently how it works.) We agree that isn't acceptable, long term (forget the fact this may be incremental), right?
So, the question is then how does one get from where the patch is to log/unlog working correctly? I just tried something similar to this by saving the data without taking the log. I punted because, yes a bit of work with all the uses here and there, but mainly because that curve-fitting code that alters the data.
I've come to the conclusion that saving the v's and j's is preferred. Sure there are other things to fix like the scale (I think 1/x is a perfectly fine and nice feature). But the curve fitting code, and having two versions of ranging code to keep track of are detrimental in comparison to using a hunk of memory for the original data.
The j/v's solution is actually pretty solid because of the code clean up we've done. Data can only come in through df_readline() and that is where we are tapping into things. On refresh, just push the code through the very beginning of the system and it doesn't matter if there was curve fitting code in between.
>>There is quite of bit of code between reading it in and storing it.
>
>
> Please quote code sections. I see none.
I meant between reading and plotting, sorry. E.g., splines and who knows what else?
Dan
|