Hello,
The splitting will still fail. We need to do some fix and the likely one
will be that which disallows non-contiguous regions for the sampled dims
(I was just wanting to make sure nobody objected to that too much).
Wayne
On Thu, 31 Jan 2008, Patrick van der Wel wrote:
> Wayne,
>
> I am not sure that I entirely understood the technical aspects of the
> issue and/or the proposed solution, but I was wondering if this means
> that it should now be safe (and functional) to split the pseudo-3D
> windows, or that you are still thinking about the best way to fix it.
> (Last time it was a bit tricky to get it un-done since things started to
> fail a bit, preventing the deletion of the new slice).
>
> Patrick
>
> Wayne Boucher wrote:
> > Hello,
> >
> > Right, I think we understand the problem here. And it's happening because
> > of how we designed the Analysis part of the data model.
> >
> > So in each window for each dimension we allow more than one region
> > (AxisRegion, in data model parlance). Each of these regions is supposed
> > to be (r0, r1) for some floating point numbers r0 and r1 (so the region is
> > defined to be those r such that r0 <= r < r1). This works exactly as you
> > would want for normal (H, C, ...) axes.
> >
> > This does not work so well for pseudo (or "sampled") axes. The problem is
> > that here our region is not continuous, but a bunch of planes. And
> > indeed, if you wanted to model it, you might say that the region instead
> > of being (r0, r1) for two floats, is (p1, p2, p3, ...) where p1 < p2 < ...
> > are integers specifying the planes. Alternatively (depending on how you
> > view these things), you could model it as ((r0, r1), (s0, s1), (t0, t1),
> > ...), where these are all integers and r1 < s0, s1 < t0, etc., and the
> > region are x such that r0 <= x < r1 or s0 <= x < s1, etc. So the first
> > method lists the planes explicitly and the second method lists contiguous
> > regions.
> >
> > We tried to shoehorn the second possibility into our existing model.
> > This allows non-contiguous sets of planes to be displayed. So (r0, r1)
> > would be the first region, (s0, s1) the second etc. (Since the existing
> > model uses floats, not ints, this means we just have to be careful with
> > rounding errors, so plane 10 is 10.0, but that's not too difficult to
> > manage.)
> >
> > But by using the multiple regions to specify non-contiguous regions we
> > rather shot ourselves from at the same time being able to do strips in the
> > same way that we do strips for ordinary orthogonal regions. So normally
> > with strips we use the multiple regions so that strip 1 can have a
> > separate z region from strip 2, etc. With pseudo data we precluded that
> > (but didn't put all the correct checks in elsewhere) so that we could use
> > multiple regions for non-contiguous sets of planes.
> >
> > The errors you are getting are precisely because of this issue.
> > Basically, the strip functionality is broken for pseudo3D data.
> >
> > Here is the proper solution (which won't happen that quickly!). We should
> > probably subclass AxisRegion into two types: FloatAxisRegion (or some
> > better name which I can't think of right now), which has (r0, r1) as now.
> > And SampledAxisRegion which has the region defined by a list of planes.
> > This will probably cause some grief to put in.
> >
> > One thing we could do right now is to disallow non-contiguous regions (and
> > as it happens, there's another bug which means that in fact the
> > non-contiguous region option is not working right now in any case). And
> > then we can use the multiple regions for the strips again. Does that make
> > sense as the thing to do? That would be a relatively painless fix (I
> > think!).
> >
> > Wayne
> >
> > On Tue, 29 Jan 2008, Patrick van der Wel wrote:
> >
> >
> >> I am still running into some issues regarding the pseudo-3D datafile
> >> that I loaded earlier (see the trace below, that I get when I add
> >> another slice to the window showing the pseudo-3D data). I suspect this
> >> is still due to the dataset where I modified the number of planes after
> >> the fact. Is there a way to fix this, or should I just forget about
> >> recovering the picked peaks and assignments?
> >>
> >> Patrick
> >>
> >> Exception in Tkinter callback
> >> Traceback (most recent call last):
> >> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
> >> return self.func(*args)
> >> File
> >> "~/research/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/WindowPopup.py",
> >> line 3579, in motion
> >> self.showMotion(x, y, canvas)
> >> File
> >> "~/research/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/WindowPopup.py",
> >> line 3563, in showMotion
> >> self.parent.drawCrosshairs(typeLocation, self)
> >> File
> >> "~/research/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/AnalysisPopup.py",
> >> line 320, in drawCrosshairs
> >> popup.drawCrosshairs(typeLocation, originatingWindowPopup)
> >> File
> >> "~/research/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/WindowPopup.py",
> >> line 3764, in drawCrosshairs
> >> drawCanvasCrosshairs(canvases[j][i], xs, ys)
> >> File
> >> "~/research/software/ccpnmr/ccpnmr1.0/python/ccpnmr/analysis/WindowPopup.py",
> >> line 3652, in drawCanvasCrosshairs
> >> axisRegion = axisPanel.axisRegions[col]
> >> IndexError: tuple index out of range
> >>
> >>
>
|