Re: Small technicality on dynarray

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

Ethan A Merritt wrote:
> On Saturday 30 June 2007 15:47, Daniel J Sebald wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>On Saturday 30 June 2007 12:30, Daniel J Sebald wrote:
>>>
>>>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.
> 
> You seem to be working towards something orthogonal. I don't think it
> really has anything to do with my patch.

No, I said I punted on the more orthogonal approach.  This will fit nicely.


>>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 repeat my earlier request.  Just forget about the whole log/unlog
> STORE_WITH_LOG mess.  We will (eventually) put a general axis-mapping
> mechanism in place, at which point we can worry about removing old
> messy code.

The new patch has nothing to do with STORE_WITH_LOG.  You'll like it.  Give me 15 minutes...

> 
> 
>>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.
> 
> They must be stored un-transformed.  Nothing else makes sense.
> 
> 
>>So 4th and 15... The question is then whether there is a good place to 
> 
> tap into the original data.
> 
> Could you please back off at bit, and explain what's wrong with 
> just using the data as it is now stored?  Disregard log/unlog.
> I don't see any need to re-work the input or data storage.
> OK, the range checking could use cleaning up, particularly the axis
> reversal tangle,  but that is a tangential issue and can 
> be tackled separately if necessary.

Why disregard the log/unlog?  The log and unlog mouse feature is one of the nicer ones.

> 
> My thought is that what we could do is introduce a new layer of
> coordinate transform routines, one that maps the input data through
> the relevant axis mapping onto the linear coordinate system
> that we use now.

Exactly, would be nice.  That's not the issue here.


>>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. 
> 
> But why would you want to do this?

So that the original data is not lost.  STORE_VALUE_WITH currently tosses the data.  If there are negative coordinate values in the data stream and the data is first transformed and stored to logarithmic scale, what will you do with the negative coordinates beyond tossing them out?  Not transform them and mark them as UNDEFINED and test for this when reverse mapping?

There is quite of bit of code between reading it in and storing it.  Fitting alters the data.  Maybe splines isn't on option outside of the plot/splot command, but I'm just worried that unless we save the raw, unprocessed data at some point we'll be in a bind.

Dan