ENH: a usecase test for chaining mapper and a cross validation
Merge branch 'master' of github.com:PyMVPA/PyMVPA

* 'master' of github.com:PyMVPA/PyMVPA:
  DOC+BF: Silence doctest error in unfinished tutorial part.
ENH: for fresh ipythons add completions for keys of collections
ENH: disabling interpolation for plot_distance_matrix
quick ugly hack to get inverse of MNI2Tal based on good old Matthews non-linear transformation
Merge pull request #99 from wzinke/no_interpolation

ENH: disabling interpolation for plot_distance_matrix
BF: to prevent bugs with ucasing+unicode -- flag in capital sfor ctypes

Thanks to Ceyhun Çakar for troubleshooting
DOC: Update contributor list
BF: s/gnb/knn/ in sphere_m1nnsearchlight
BF(workaround): adhocsearchlights -- do not allow partitioners changing targets

The reason is that ATM due to current implementation with "groupping" of targets and partitions
presumably for efficiency, it would be tricky, and thus not implemented.
For now at least state that in docstring and raise Exception so people do
not fall into the trap
Merge remote-tracking branch 'origin/master'

* origin/master:
  DOC: Update contributor list
BF: rng= option for Permutator so default is to use a new RandomState()

Otherwise it leads to generation of the same permutations while generating
MC distribution of searchlight performances, in fancy two-stage way
(unittests accompanies).  So from now on we should not rely on the single
np.random all around to guarantee correct operation in the child processes
BF: forgotten import for mvpa2.tests.test_usecases.test_gnbsearchlight_permutations
NF: get_random_seed -- little helper to return a random int for seeding RNG
RF: follow Tiziano's wisdom -- provide seeds to child pprocesses

This way no control over rng for every use of np.random should be needed
and RNGs would provide different sequences in different child processes.

Sideeffect:  searchlight results with nproc=1 and nproc>1 might still differ.
the only solution for that would be to provide seed values per each roi_fid
which might be a bit overkill
NF(+RF): AttributePermutator got option strategy with new handling for uattrs value

if strategy="uattrs" is specified, then attributes are not simply
permuted breaking any possible existing interdependency -- samples
of the same unique combination of attrs obtain the same attrs value
of another unique combination.  In the simplest case, e.g. if
attrs=targets, it results in simply remapping targets (i.e. e.g.
1 becomes 2, 2 becomes 1 and 0 stays 0).

The idea is that this should be closer to the idea of "permutting
independent samples" as "clean" permutation MC H0 testing requires and
hopefully would eliminate the necessity for the scary two-stage design
to not permute "testing" labels.  With this setup, in case of balanced
labels, it should be ok to simply reassign labels in all functional runs
gaining similarly concervative H0 distribution (yet to be tested)
ENH: while looking at MulticlassClassifier -- minor typos + 1 more test
NF: core Node obtains additional parameter "pass_attr"

The purpose is to allow enriching resultant dataset (output by __call__) with
information from original dataset or the state of the instance's .ca.
Unfortunately postproc is not fit for the purpose since original dataset is not
even provided into it, only result.  Also providing such functionality via this
API change should not have significant performance impact but could come useful
in many scenarios.

ATM it also is capable of storing the content of .ca attributes of the instance
itself BUT only as .sa attributes since it lacks any idea what they should
correspond to.  We might like to consider extending ConditionalAttributes with
a parameter describing either they correspond to samples or features of the
result or may be adding some syntax into specification of pass_attr to describe
which collection any particular element should be copied to (e.g. a dictionary
{'sa' : [...]}.

Such feature should also enable more sophisticated postproc calls which
would make use of those passed additional attributes, happen that is needed.

Basic untitest test_multiclf.py:test_multiclass_classifier_pass_ds_attributes
gives an example.  Original intent was to father ca.raw_estimates but those
ATM are  in the transposed "shape" (classifier x samples).
ENH: when unable to resolve ties -- choose first one in sorted order

on one hand it is just making it somewhat worse (e.g. before it could be
considered random resolution since order of labels comes from a unordered dictionary)
but this way we should obtain results consistent with LIBSVMs failure to resolve
ties.  So -- for now lets be more consistent with LIBSVM.  Correct resolution still TODO
ENH: expose Multiclass's ca.raw_predictions also as a ca.raw_predictions_ds with correct orientation

Felt wrong to break meaning of what/how things are presented in raw_predictions.
But classifier x sample was not a good fit for pass_attr, so came up with
new .ca.  Having it as a Dataset allows to disambiguate what targets
actually corresponded to any given binary classifier's 'positive/negative' labels