After some head banging with MacPorts in order to try to install python_select, I’ve found an explanation why python_select, although being displayed as being installed and active by MacPorts, still does not get installed in /opt/local/bin (and therefore, it borks when trying to run it from the command line): #29531 (_select ports no longer provide _select binary) – MacPorts.
So now it seems that python_select was deprecated and we should use instead (e.g. to select python2.6):
% sudo port select python python26
> would work perfectly well if the range returned [1, 2, 3, 4] and the
> list was indexed starting with 1. Basically, range(4) has to produce a
> list of four items, we just differ on what those items should be.
If indexes started at 1, then maybe so should ranges. However,
having read the followups to this message, I think there are still
advantages of simplicity and regularity in having arrays (even if
one calls them lists:-) indexed from 0. My master thesis, lo that
many years ago, included a large program in Fortran IV (1-based
index only) and had to do a lot of +1/-1 twiddling because of
that. I didn’t understand why at the time (having not yet met
Koenig’s book “C traps & pitfalls”, which introduced me to the
many advantages of half-open ranges — array indexing being a
case of that), but now I think I do.
Suppose my 1-dimensional array/list needs at some point to
be ‘seen’ as composed of several adjacent subarrays, each of
length N — just for example. OK, what’s M, the index in the
array of element I of subarray K?
If everything starts from 0:
M = I+K*N
nice and simple. If everything starts from 1:
M = 1 + (I-1) + (K-1)*N
= I + (K-1)*N
darn — an unavoidable ‘-1’… 1-based indexing just isn’t as
arithmetically nice as 0-based when you start having to
compute your indices.
And the reverse, too — given M and N,
K, I = divmod(M,N)
with 0-based indexing throughout — nice, isn’t it…? What
about *one*-based indexing throughout…? Hmmm, looks
like we’ll have to do the -1 dance on M first, then the +1
one on both of the subresults…:
K, I = divmod(M-1, N)
K += 1
I += 1
Doesn’t it start to look as if indices WANT to be zero-based,
and coercing them to 1-based is simply a pretty artificial
choice requiring many +1’s and -1’s strewn around…?
OK, what about the “main diagonal” of the intrinsic 2D
array embedded in my 1D one — first element of first
subarray, second element of second subarray, etc. Can
I get the indices of that easily and naturally? What’s the
index M in the big array of the I-th element of this main
diagonal? Well, when 0-based indexing is being used
throughout, M=I*(N+1) seems right. When 1-based…:
M = 1 + (I-1)*(N+1)
Again we have to do a -1 on I to move it from 1-based
to 0-based for the computation, and +1 on the result
to move the natural 0-based one to 1-based. Just take
care to NOT do more or fewer -1’s and +1’s than needed
or a bug may emerge…:-).
OK, forget subarrays. Say we just have two very long
arrays A and B. We need to consider them starting
from indices IA and IB, and obtain a result by summing
corresponding elements — the first element in our
result array is A[IA]+B[IB], and so on. Simple, right?
OK, so, what’s the I-th element of our result?
C[I] = A[IA+I] + B[IB+I]
when all indices are 0-based. If 1-based, though:
C[I] = A[IA+I-1] + B[IB+I-1]
darn — once again the -1 emerges! Once again we
have to just about “translate” arithmetically-funny
1-based indices to the “natural” 0-based ones, and
so the -1 (or +1, depending).
You will no doubt find some counterexamples too, but
in general I think you’ll notice that anytime two indices
need to be added, or other kinds of arithmetic on
indices are required, 0-based indices tend to behave
better, 1-based ones need some ‘translation’ (-1, +1)
far more often than the reverse case.
So I’m using a different python install from the one provided OEM in OSX by Apple. Specifically, I’m using Fink to get a more recent version of python 2.5 (but it could be MacPorts – the following problem would be the same).
Having python and swig installed in my osx box (both from Fink), I’m now trying to build the Marsyas library with python bindings, by means of swig, so that it becomes a python module I can use when coding in… er… python ;-).
The problem is that Cmake, when looking for the python installs and dependencies in my OSX box (which it does when I activated the WITH_SWIG flag in Marsyas CMake build configuration), only looks for the python install provided by Apple in OSX (which is in fact a “framework” (in Apple sense) and not a library) and doesn’t know a thing about the Fink installed python (which lives in /sw/bin).
The result (and problem) is that if I start python (from Fink) and do “import marsyas”, it returns an error because that module was not in fact installed for it (it was installed for the Apple OEM python install, which I don’t want to use).
I found this blog where someone had a similar problem using Opencv ad Python and kind of fixed it, but I don’t find the proposed solution elegant and I’m still looking for less hacky fix to this issue.
So I finally found the time (and need!) to properly install Python in my OSX10.5.6 box, together with some nice modules I’ll need for some of my current research/development work. I’ve followed a quite instructional site (see it here and here) on how to do it, but for Marsyas you’ll only need the following modules:
- python2.5 (from Fink, and not the one provided by Apple in OSX, which is a kind of old and hard to manage version of python)
- scipy-core-py25 (aka NumPy)
After you install all the modules (go grab a coffee because they will take a substantial amount of time to build!), you still need to make sure you call the Fink’s installed python and not the OSX OEM python install (you can ask OSX which python is currently being used in the terminal with “$ which python”). Fink installs python at /sw/bin/python2.5, so in order call it from anywhere you should update you .bash_profile with:
This way, you can call python2.5 from anywhere (the same applies to any other Fink installed tool). If you want to drop the 2.5 part, just create a symbolic link to python2.5 in /sw/bin, like this:
$ cd /sw/bin
$ ln -s python2.5 python
And that’s it!
I’ll now move on to play with Marsyas and SWIG (which gets installed for you by Fink when installing the modules above) and probably report back here in case I find any troubles/tips.