![](/profiles/wavemetrics/themes/wavemetrics/logo.png)
Providing a way to make a "hard" direct link between a y-wave and its x-wave
![](/sites/default/files/styles/thumbnail/public/jjweimer/profile-images/2018-12/meimage.jpg?itok=gNUlNM01)
Just a long term thought. Perhaps a pie-in-the sky idea. This concerns 1-D wave data only.
I struggle over this in reminding myself and my students about the distinction in displaying as well as manipulating scaled versus (y-x) paired data sets. Too often, even for me, simply forgetting the "display ywave vs xwave" or differentiate ... /X=... causes a short spell of frustration. And also, programming to account for general cases in analysis of spectroscopy is a nightmare. FTIR spectra have their scales built in, but ellipsometry spectra do not (by example). I have to write code with case or if-then switches, and track waves with wave notes for example.
So ... would it ever be possible to "link" one wave automatically as the source for the scaling to another wave? Consider the way that we choose a wave to generate the error bars for a display. Now review 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.. 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?
July 1, 2024 at 09:13 pm - Permalink
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.
July 2, 2024 at 06:01 am - Permalink
In reply to I imagine linking to be… by jjweimer
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.
July 2, 2024 at 08:59 am - Permalink
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.
July 2, 2024 at 01:49 pm - Permalink
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.
July 2, 2024 at 09:36 pm - Permalink
> 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).
imagewave.y = iy[p]
stackwave.z = sz[p]
SetScale/L x, xwave, ywave
SetScale/L x, ix, imagewave
SetScale/L y, iy, imagewave
SetScale/L x, sx, stackwave
SetScale/L y, sy, stackwave
SetScale/L z, sz, stackwave
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?
July 3, 2024 at 08:39 am - Permalink
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
July 3, 2024 at 08:49 am - Permalink