Providing a way to make a "hard" direct link between a y-wave and its x-wave

Hmm.. You might already get 90% there with workarounds, depending on what you want to do (is it just graphing and the occasional analysis or more?). For example, tony has the X-Y Browser project ( https://www.wavemetrics.com/node/21303 ) which works via the wave's note. I also have a right-click menu in my Graph Tools to plot XY data directly from the Data Browser (not yet compatible with tony's approach, though). How would the linked x waves be handled. Do you allow for moving them to a different folder individually or for deleting them? Or are they then invisible to the normal user and move together with their Y compartment?

I imagine linking to be entirely transparent to the user. Also, regardless where the x-wave is, it is still located. Perhaps the x-wave becomes "embedded" with the y-wave, e.g. as a hidden column. Perhaps waves are referenced internally by an immutable meta-label.

Even with access to a range of packages to handle the issue (even my own from ages ago ... https://www.wavemetrics.com/project/LinkDisplay), I still have times when I wish that the ability to handle x-y data was built in.

jjweimer wrote:

the SetScale dialog box. In the Change Wave Scaling, we have an insert section set the X properties for scaled waves. We have Numeric, Date, Time, and Date&Time. Why not also "Linked" (for lack of a better word at the moment)? The choice for LINKED units type would provide an option to choose a wave that acts as the source for the x scaling

hmm, and then the x wave disappears from the user, perhaps the y wave becomes a 2d wave that appears the same as a scaled 1D wave...

And then we would expect all Igor functions and operations that work on scaled data to work with the new scaling method, not just display... You would lose the possibility of referencing by x value, and there would be no way to know how to interpolate values. 

I would find it a nice feature, but I also think that it could be confusing for new users. I fear that if I hand a collection of spectroscopic tools that 'just work' to a student, they may remain totally unaware of what is happening under the hood, which makes it more difficult for the student to make the leap from using a package to creating their own analytical routines. Imagine the question: Why can I write "Print IRspectrum(1000)" but not "Print RamanSpectrum(1000)?" They both *look* like they have a linear progression in X (wavenumber) values.

I'd not expect a full translation. I'd be glad for a core set of functions/operations to handle (x,y) pairing automatically. Certainly display and appendtograph. The big question would be how to allow programmers such as me to set the linked scaling: SetScale/LINK ywave, xwave????

WaveMetrics is rather good about not loosing backward compatibility. I'd expect x = pnt2x(wave,p) to remain even when x = wave[p][-1] or x = wave[p*] (or some such new nomenclature) becomes a viable new approach.

Those students who would write their own analytical routines will still ask why can I write "print RamanSpectrum(111.11)" but not write "print IRSpectrum(111.11)". This at least is a distinction that remains regardless.

In the meantime, I am glad that idea has sparked some interest.

I actually hate working with XY data and try to convert it to scaled data as much as possible even if this means using interpolation sometimes. My main concern would be that having two waves for one data set escalates the clutter a lot. If something like liking gets introduced, I would be in favor of hiding the x data inside the y data somehow. I think having this data inside row labels would be minimally invasive. Since dimension labels can have up to 255 bytes nowadays, the precision could be maintained. One would just need to add a special tag to the wave that the label contains the x info. With a bit of fiddling I could imagine getting this functional without official support from Igor by having functions in place which can extract the x info on the fly and do the magic in the background.

> I would be in favor of hiding the x data inside the y data somehow.

I initially envisioned using a negative index to indicate the x scaling. The x data for ywave is accessed as ywave[p][-1]. But this approach is cumbersome beyond a 1-D wave, for example image data[p][-1][q][-1]????

I just now remembered the notation ywave.d and ywave.x give the data and x-values, respectively, for a given ywave. So, when a ywave has a separate xwave, these commands would replace the calculated scaling with the respective data values (where I use /L to indicate "link" as an extension to the SetScale/I/P flags).

If this were implemented, I wonder how much would break in functions and operations that demand a /X= type of flag to explicitly denote the xwave?

Hi,

Could another option take the form from the complex variables, where two values are contained in a single point. The "real" would be the Y value and imaginary be the X value.

Andy