Custom Query (43 matches)

1. open the attached VIFF which is just press_cp0 w/a fitting tab
2. Click on the fitting tab
3. Click on initial values subtab
4. Under baseline estimate, choose Lowess. Immediately I get the error below.

Traceback (most recent call last):
 File "/Users/me/w/duke/src/vespa/analysis/src/tab_voigt.py", line 1255, in on_initial_baseline_method
   self.process_and_plot()
 File "/Users/me/w/duke/src/vespa/analysis/src/tab_voigt.py", line 2008, in process_and_plot
   self.process(entry=entry)
 File "/Users/me/w/duke/src/vespa/analysis/src/tab_voigt.py", line 1965, in process
   self.block.chain.run(voxel=voxel, entry=entry, statusbar=self.top.statusbar)
 File "/Users/me/w/duke/src/vespa/analysis/src/chain_voigt.py", line 353, in run
   funct.algorithm(self)
 File "/Users/me/w/duke/src/vespa/analysis/src/functors/funct_initial_values.py", line 167, in algorithm
   util_inital_values.find_initial_values(chain.data, chain)
 File "/Users/me/w/duke/src/vespa/analysis/src/util_initial_values.py", line 2515, in find_initial_values
   initvals_1h_lowfield_shortte(data, chain)
 File "/Users/me/w/duke/src/vespa/analysis/src/util_initial_values.py", line 1848, in initvals_1h_lowfield_shortte
   ddat = inital_estimate_baseline(ddat, proc)
 File "/Users/me/w/duke/src/vespa/analysis/src/util_initial_values.py", line 1186, in inital_estimate_baseline
   base1 = baseline_estimation_lowess(dat.real, proc, widmul=1.0)
 File "/Users/me/w/duke/src/vespa/analysis/src/util_initial_values.py", line 640, in baseline_estimation_lowess
   ms  = np.median(dat[lhs1:lhs])
 File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/lib/function_base.py", line 2955, in median
   return mean(sorted[indexer], axis=axis, out=out)
 File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/fromnumeric.py", line 2374, in mean
   return mean(axis, dtype, out)
FloatingPointError: invalid value encountered in double_scalars

On all platforms, we have code that reacts to changes in the # of data points slider and ensures that the slider's value is one of the values acceptable to the HLSVD algorithm as described in ticket #40. In other words, when we get a "slider changed value" event, we sometimes react to that by changing the slider's value again.

Under OS X, all is well except that at some point the slider "forgets" the value we've given it and goes back to the value to which the user set it. For example -- the slider is at 1024. I use the keyboard to move the slider left; the slider moves to 1021. This isn't valid for HLSVD, so during the "slider changed value" event, we change the value of the slider to 1020 which is valid.

If I immediately get the value of the slider, it says 1020. If I get the value of the slider in _apply_hlsvd() (which is executed with wx.CallAfter() which allows events to happen before calling the function in question), it says 1020. However, if I then hit the left arrow again, the slider reports its value as 1021.

The consequence for us is that our code believes the last slider value was 1020, so if it is now 1021, then the user must have hit the right arrow and asked for a bigger number when in fact the opposite is true. This makes slider keyboard navigation for # of data points almost useless under OS X. It is possible to take advantage of it by getting the slider close to the value you want using the mouse, and then using the keyboard to move it a notch or two. But it's flaky.

This is especially annoying given bug #42 which limits what one can do to a slider with the mouse under OS X.

I don't think we're doing anything to cause this problem, especially since it doesn't happen under Windows nor GTK.

Under OS X, one can slide a slider all the way to the right with the mouse, but it doesn't reach the max value. For instance, of # of data points max = 1024, sliding it to the right will only reach 1012 or so. Moving it with the keyboard allows one to reach the max (but that has another problem that I'll document in another ticket).

The inability to reach the max is a known problem with wx under OS X. If I read this ticket correctly, the problem is solved under wx 2.9.

​http://trac.wxwidgets.org/ticket/4555

I'm closing this as WONTFIX since we can't do much about it.