Re: [pymvpa] LinearCSVMC not found in PyMVPA-upstream-2.4.0 release

2015-07-30 Thread Melanie Boly
sok found it and with Swig3.0.4 now it works! thanks so much to everybody, 
Melanie

 On Jul 30, 2015, at 10:15 AM, Melanie Boly boly.mela...@gmail.com wrote:
 
 Dear Nick,
 Thank you so much for your comments; trying to apply your
 recommendation, but missing one simple step: what is the 'PyMVPA root
 directory'?
 Thanks so much,
 Melanie
 
 On Sun, Jul 19, 2015 at 8:44 AM, Nick Oosterhof
 n.n.ooster...@googlemail.com wrote:
 
 On 15 Jul 2015, at 18:46, Feilong Ma mafeil...@gmail.com wrote:
 
 I had a similar problem while installing PyMVPA on Mac OS (10.10.4).  I 
 think the problem is related to this line:
 https://github.com/PyMVPA/PyMVPA/blob/master/mvpa2/clfs/libsvmc/_svm.py#L22
 
 When I tried to run this line in ipython
 from mvpa2.clfs.libsvmc._svmc import C_SVC, NU_SVC, ONE_CLASS, EPSILON_SVR
 What I got is:
 ImportError: cannot import name C_SVC
 
 I get the same error. Briefly (see below for details), it seems due to a 
 change in SWIG, with later versions giving issues.
 
 When running python setup.py build_ext” and copying over the .o and .so 
 files from the build directory to PyMVPA’s root directory (across the 
 corresponding subdirectories), the following reproduces the error directly:
 
python -c from mvpa2.clfs.libsvmc._svmc import C_SVC”
 
 Strangely enough, the following works for the failing PyMVPA installation 
 (but not for the working one):
 
python -c from mvpa2.clfs.libsvmc._svmc import C_SVC_swigconstant”
 
 Digging a bit further, the mvpa2/clfs/libsvmc/svmc.py file differs between 
 my “working” (generated using SWIG 3.0.2) and “failing” (SWIG 3.0.6) PyMVPA 
 setup. One difference is that the working version has contents such as
 
C_SVC = _svmc.C_SVC
 
 whereas the failing version has extra lines that includes “swigconstant”
 
_svmc.C_SVC_swigconstant(_svmc)
C_SVC = _svmc.C_SVC
 
 (For completeness I’m including the full content of both versions below. )
 
 Tracing this back further, I compiled swig from source, both for the latest 
 version on github and for version 3.0.0 (version 3.0.2 gave an error when 
 compiling). When using 3.0.0, the import works fine; with 3.0.6 or the 
 latest (3.0.7 development) it breaks.
 
 
 I guess the problem might be related to compiling LibSVM.  I vaguely 
 remember there was some error messages with CLANG blah blah.
 
 I installed GCC 5.1 and get the same problem as when using CLANG.
 
 To summarize, the following worked for me to get libsvm to work on OS X 
 Yosemite:
 
 - clone swig from https://github.com/swig/swig, then “git checkout -tag 
 tags/tags/rel-3.0.0”
 - in the swig directory, run “autoconf  ./configure  make  sudo make 
 install” (although it gives an error when installing the man-pages due to 
 missing yodl2man, the binaries are installed fine). This requires autoconf, 
 automake and libconf.
 - in the PyMVPA directory, run python setup.py build_ext”
 - copy the .so and .o files from the build directory to the PyMVPA root 
 directory, for example in the PyMVPA root directory do for ext in .so .o; 
 do for i in `find build -iname *${ext}`; do j=`echo $i | cut -f3- -d/`; cp 
 $i $j; done; done”
 
 If anyone can confirm that using an earlier version of SWIG fixes the 
 problem, that would be great. In that case I can also raise the issue with 
 the developers.
 
 
 
 (Below: contents of mvpa2/clfs/libsvmc/svmc.py for working and failing 
 libsvm in PyMVPA)
 
 
 # *Failing* mvpa2/clfs/libsvmc/svmc.py
 
 
 # This file was automatically generated by SWIG (http://www.swig.org).
 # Version 3.0.6
 #
 # Do not make changes to this file unless you know what you are doing--modify
 # the SWIG interface file instead.
 
 
 
 
 
 from sys import version_info
 if version_info = (2, 6, 0):
def swig_import_helper():
from os.path import dirname
import imp
fp = None
try:
fp, pathname, description = imp.find_module('_svmc', 
 [dirname(__file__)])
except ImportError:
import _svmc
return _svmc
if fp is not None:
try:
_mod = imp.load_module('_svmc', fp, pathname, description)
finally:
fp.close()
return _mod
_svmc = swig_import_helper()
del swig_import_helper
 else:
import _svmc
 del version_info
 try:
_swig_property = property
 except NameError:
pass  # Python  2.2 doesn't have 'property'.
 
 
 def _swig_setattr_nondynamic(self, class_type, name, value, static=1):
if (name == thisown):
return self.this.own(value)
if (name == this):
if type(value).__name__ == 'SwigPyObject':
self.__dict__[name] = value
return
method = class_type.__swig_setmethods__.get(name, None)
if method:
return method(self, value)
if (not static):
if _newclass:
object.__setattr__(self, name, value)
else:
self.__dict__[name] = value
else:

Re: [pymvpa] Surface searchlight taking 6 to 8 hours

2015-07-30 Thread Nick Oosterhof

 On 29 Jul 2015, at 20:57, John Baublitz jb...@bu.edu wrote:
 
 Thank you very much for the support. Unfortunately I have tried using this 
 GIFTI file that it outputs with FreeSurfer as an overlay and surface

Both at the same time?

 and it throws errors for all FreeSurfer utils and even AFNI utils. FreeSurfer 
 mris_convert outputs:
 
 mriseadGIFTIfile: mris is NULL! found when parsing file f_mvpa_rh.func.gii
 
 This seems to indicate that it is not saving it as a surface file. Likewise 
 AFNI's gifti_tool outputs:
 
 ** failed to find coordinate/triangle structs
 
 How exactly is the data being stored in the GIFTI file? It seems that it is 
 not saving it as triangles and coordinates even based on the code you linked 
 to in the github commit given that the NIFTI intent codes are neither 
 NIFTI_INTENT_POINTSET nor NIFTI_INTENT_TRIANGLE by default.

For your current purposes (visualizing surface-based data), consider there are 
two types of surface GIFTI files:

1) functional node-data, where each node is associated with the same number 
of values. Examples are time series data or statistical maps. Typical 
extensions are .func.gii or .time.gii.
2) anatomical surfaces, that have coordinates in 3D space (with 
NIFTI_INTENT_POINTSET) and node indices in face information (with 
NIFTI_INTENT_TRIANGLE). The typical extension is surf.gii.

In PyMVPA:
(1) functional surface data is handled through mvpa2.datasets.gifti. Data is 
stored in a Dataset instance.
(2) anatomical surfaces are handled through mvpa2.support.nibabel.surf (for 
GIFTI, mvpa2.support.nibabel.surf_gifti). Vertex coordinates and face indices 
are stored in a Surface instance (from mvpa2.support.nibabel.surf)

(I'm aware that documentation about this distinction can be improved in PyMVPA).

 I've also run into a problem where the dataset that I've loaded has no intent 
 codes and unfortunately it appears that this means that the NIFTI intent code 
 is set to NIFTI_INTENT_NONE.

Why is that a problem? What are you trying to achieve? If the dataset has no 
intent, then NIFTI_INTENT_NONE seems valid to me, as the GIFTI standard 
describes this as Data intent not specified.


___
Pkg-ExpPsy-PyMVPA mailing list
Pkg-ExpPsy-PyMVPA@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-exppsy-pymvpa