Apply selectivity_scale to plots only w/o scaling data

[sf-issues]

Converted from SourceForge issue 3537828, submitted by philippjfr Submit Date: 2012-06-25 15:34 GMT

Currently, the selectivityscale, which is part of all DSF functions, offsets and multiplies feature selectivity data in an effort to make even low selectivity values properly viewable in Selectivity and Feature Preference/Selectivity maps. This also scales the underlying data, such that hovering over a particular unit in the map brings up the scaled, rather than the originally measured selectivity value. The scaling of the underlying value should apply only to the view of the Selectivity map or the saved plot but not to the underlying data.

[sf-issues]

Submitted by aplebe Date: 2012-06-26 08:16 GMT

I fully agree it would be desirable to segregate scaling of selectivity for the purpose of a visual appreciation in plotted maps, and scaling to a appropriate numerical range, for further mathematical analysis. And I agree that it would be very nice reading selectivity values in the desired range when hovering in the plotted maps.

I don't know if the reintroduction of selectivity_multiplier in revision 12083 is a first step in this direction. On one side, a duplicate multiplier (selectivity_multiplier and selectivity_scale[1]) is probably necessary, if selectivity_scale is in charge of scaling selectivity into a desired numerical range, for example 0..1, and selectivitymultiplier is for graphical visibility only. Since selectivity typically lacks a natural dimension, and it is not always easy to ensure a 0..1 range in DSF functions, selectivity_scale add flexibility. But the additional selectivity_multiplier cannot do the job, if coded inside featureresponses.collect_feature_responses, it just collapse into a single multiplier, alternative to selectivity_scale[1].

This additional selectivity_multiplier should be managed by the plotting function only.

I understand that it might simply avoid the hardcoded 17.0 amount of selectivity scaling from command/analysis.py, the problem is that this way the 17.0 number is coded even harder, being featureresponses.py less user-level than analysis.py. Moreover now, to avoid the hidden multiplication by 17, and keep the chosen selectivity_scale[1] working, one should specify FeatureMaps.selectivity_multiplier=0, that is rather odd, when one want to keep a multiplier flat.

[sf-issues]

Submitted by jbednar Date: 2012-07-07 08:12 GMT

HI Alessio,

I think we all agree about the right way to handle this scaling, but right now none of us are ready to try to implement a separate scale for plotting, which is what really needs to be done. But we had to have some way to control all of the hard-coded scaling by 17, because it's not appropriate for some networks, and until Philipp's change was not changeable in any reasonable way. Now that Philipp has made the selectivitymultiplier parameter be ignored if it's set to None, I think we have a compromise that works for us for now -- if it's None, no global scaling is applied, and the usual DSF selectivityscale mechanisms will work as you implemented them. If it's set to 17.0 (the default), then all of our tests pass, because it reproduces the historical behavior. If it's changed from the default, which was done for several years by .ty files prior to your introduction of DSF functions, then everything now works as it always has. Thus this approach gives us all the same results we always had, and the same way to control a global scale, while being compatible with your DSF_ approach and only requiring a few lines of implementation (and thus allowing Philipp to get back to his research!). And it can be turned off easily by setting the parameter to None. So unless we've overlooked some crucial problem, I think this lets us achieve all of our required short-term objectives, without introducing any too-ugly hack.

Of course, if any one wants to implement the separate plotting selectivity support, then that would be wonderful and the right thing to do in the long run, but we expect that to be a fairly complicated job, considering all the pain involved in making sure all the tests pass and that no behaviour has been broken.

[sf-issues]

Submitted by nobody Date: 2012-07-07 13:32 GMT

Hi Jim, Philipp, I saw the solution about selectivity_multiplier and its "historical" 17.0 default in revision 12084, and I agree it's a smart working compromise Alessio