Re: Small technicality on dynarray

[Ethan A M. <merritt@u.washington.edu>]

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.

> 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.

> 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.

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.   I think this can be developed cleanly without
altering any existing code, and then slotted in via extra mapping
calls in a small number of places like map_position() and friends. 

> 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?

> Or do you think the point to tap into the data is where I described? 

Nope. At this point I see no advantage to it at all.
That's why I ask what you see wrong with the current data flow.

-- 
Ethan A Merritt