About alternatives to Matlab

25 views
Skip to first unread message

Boris

unread,
Oct 23, 2006, 10:32:21 AM10/23/06
to
Hi, is there any alternative software for Matlab? Although Matlab is
powerful & popular among mathematical & engineering guys, it still
costs too much & not publicly open. So I wonder if there's similar
software/lang that is open & with comparable functionality, at least
for numerical aspect. Thanks!

Jérôme

unread,
Oct 23, 2006, 10:36:26 AM10/23/06
to

NZTideMan

unread,
Oct 24, 2006, 3:09:44 AM10/24/06
to

In addition to these, have a look at Python and in particular NumPy
(Numeric Python).
In NumPy there are add on's that make it look exactly like Matlab and
it's free.
http://www.python.org/

weg...@gmail.com

unread,
Nov 12, 2006, 11:11:36 AM11/12/06
to

In fact, numpy is mainly the array structure and scipy contains the
'extensions'. One additional tool you need is matplotlib, which
provides plotting similar to matlab. For a single distribution that
contains everything (python+numpy+scipy+matplotlib+editors+...) look at

http://code.enthought.com/enthon/

In my opionion scilab and octave are both mediocre imitations of matlab
(didn't check recently), which itself is a mediocre language for
everything else than matrices. I personally find Python a very
'pleasant' language, which can be used for everything from websites to
command line stuff. Allthough the matrix stuff is clearly bolted on
later and is still not totally finished, I do see it as a good
competitor for matlab in the near future. It is already used actively,
for example, in the pipeline to process Hubble images.

Cheers, Bas

Harmonic Software

unread,
Nov 16, 2006, 1:27:29 PM11/16/06
to
[This followup was posted to comp.soft-sys.matlab and a copy was sent to
the cited author.]

In article <1163347896.8...@m73g2000cwd.googlegroups.com>,
weg...@gmail.com says...
> NZTideMan wrote:


> > J=E9r=F4me wrote:
> > > Hi,
> > >
> > > <http://www.gnu.org/software/octave/>
> > > <http://www.scilab.org/>
> > > <http://scipy.org/>
> > >

> > > J=E9r=F4me


> >
> > In addition to these, have a look at Python and in particular NumPy
> > (Numeric Python).
> > In NumPy there are add on's that make it look exactly like Matlab and
> > it's free.
> > http://www.python.org/
>
> In fact, numpy is mainly the array structure and scipy contains the
> 'extensions'. One additional tool you need is matplotlib, which
> provides plotting similar to matlab. For a single distribution that
> contains everything (python+numpy+scipy+matplotlib+editors+...) look at
>
> http://code.enthought.com/enthon/
>
> In my opionion scilab and octave are both mediocre imitations of matlab
> (didn't check recently), which itself is a mediocre language for
> everything else than matrices. I personally find Python a very
> 'pleasant' language, which can be used for everything from websites to
> command line stuff. Allthough the matrix stuff is clearly bolted on
> later and is still not totally finished, I do see it as a good
> competitor for matlab in the near future. It is already used actively,
> for example, in the pipeline to process Hubble images.
>
> Cheers, Bas
>
>

Might have a look at O-Matrix, www.omatrix.com. Not free, but much less
expensive, and faster than other commercial alternatives.

sturlamolden

unread,
Nov 16, 2006, 4:09:03 PM11/16/06
to

I have used Matlab for years, and has recently changed to Python. In
addition one needs NumPy and Matplotlib, and perhaps SciPy. Other
useful packages are PyGTK for GUI, PyGame for multimedia, PyOpenGL for
3D graphics, Mpi4Py for parallel computation, etc. You will find python
packages for nearly any conceivable task. Unlike Matlab, Python is a
general purpose programming language, and a distant cousin of Lisp. The
Python language is fare more expressive and productive than Matlab, yet
even more easy to use.

The NumPy package is the core requirement for numerical work in Python.
It is quite different form Matlab, but I think it is more powerful.
Particularly, arrays are passed by reference (not by value), and
indexing creates view matrices.

To compare Matlab with NumPy we can e.g. use the D4 discrete wavelet
transform. I have here coded it in Matlab and Python/NumPy using Tim
Swelden's lifting scheme.

First the Matlab version (D4_Transform.m):

function x = D4_Transform(x)
% D4 Wavelet transform in Matlab
% (C) Sturla Molden
C1 = 1.7320508075688772;
C2 = 0.4330127018922193;
C3 = -0.066987298107780702;
C4 = 0.51763809020504137;
C5 = 1.9318516525781364;
s1 = zeros(ceil(size(x)/2));
d1 = zeros(ceil(size(x)/2));
d2 = zeros(ceil(size(x)/2));
odd = x(2:2:end);
even = x(1:2:end-1);
d1(:) = odd - C2*even;
s1(1) = even(1) + C2*d1(1) + C3*d1(end);
s1(2:end) = even(2:end) + C2*d1(2:end) + C3*d1(1:end-1);
d2(1) = d1(1) + s1(end);
d2(2:end) = d1(2:end) + s1(1:end-1);
x(1:2:end-1) = C4*s1;
x(2:2:end) = C5*d2;
if (length(x) >2)
x(1:2:end-1) = D4_Transform(x(1:2:end-1));
end


Then the Python version (D4.py):

import numpy
import time

def D4_Transform(x, s1=None, d1=None, d2=None):
"""
D4 Wavelet transform in NumPy
(C) Sturla Molden
"""
C1 = 1.7320508075688772
C2 = 0.4330127018922193
C3 = -0.066987298107780702
C4 = 0.51763809020504137
C5 = 1.9318516525781364
if d1 == None:
d1 = numpy.zeros(x.size/2)
s1 = numpy.zeros(x.size/2)
d2 = numpy.zeros(x.size/2)
odd = x[1::2]
even = x[:-1:2]
d1[:] = odd[:] - C1*even[:]
s1[0] = even[0] + C2*d1[0] + C3*d1[-1]
s1[1:] = even[1:] + C2*d1[1:] + C3*d1[:-1]
d2[0] = d1[0] + s1[-1]
d2[1:] = d1[1:] + s1[:-1]
even[:] = C4 * s1[:]
odd[:] = C5 * d2[:]
if x.size > 2:

D4_Transform(even,s1[0:even.size/2],d1[0:even.size/2],d2[0:even.size/2])

if __name__ == "__main__":
x = numpy.random.rand(2**23)
t0 = time.clock()
D4_Transform(x)
t = time.clock()
print "Elapsed time is %.6f seconds" % (t-t0)


Now let's do benchmark on my laptop (1.73 GHz Pentium M, 0.99 GB RAM).
I have stopped paying for Matlab maintenance (for reasons that will be
obvious), so I only have R14 Service Pack 2 for comparison.

First we try Matlab (R14 Service Pack 2):

>> x = rand(2^23,1);
>> tic; D4_Transform(x); toc
Elapsed time is 27.145438 seconds.


Then we Python 2.4.4 with NumPy 1.0:

C:\develop\python\D4>python D4.py
Elapsed time is 3.364887 seconds

That is quite astonishing.

If anyone wonders why I think Travis Oliphant and the NumPy team should
be knighted, then this is the answer. The Mathworks' product only
achieved 100% * 3/27 = 11% the speed of Python/NumPy, and is infinitely
more expensive.

Does anyone wonder why I am not paying for Matlab maintenance anymore?

Sorry Mathworks, I have used your product for years, but you cannot
compete with NumPy.


Cheers,
Sturla Molden

John Henry

unread,
Nov 16, 2006, 4:46:13 PM11/16/06
to
Bill Gates will have you jailed! :-)

On a more serious note, is there any alternative to Simulink though?

Cameron Laird

unread,
Nov 16, 2006, 5:55:38 PM11/16/06
to
In article <1163711343.8...@h48g2000cwc.googlegroups.com>,

sturlamolden <sturla...@yahoo.no> wrote:
>Boris wrote:
>> Hi, is there any alternative software for Matlab? Although Matlab is
>> powerful & popular among mathematical & engineering guys, it still
>> costs too much & not publicly open. So I wonder if there's similar
>> software/lang that is open & with comparable functionality, at least
>> for numerical aspect. Thanks!
>
>I have used Matlab for years, and has recently changed to Python. In
.
.
.
While I frequently push Matlab users toward Python, they also deserve
to know about Octave <URL:
http://www-128.ibm.com/developerworks/library/l-oslab/?n-l-10242 >.

Matimus

unread,
Nov 16, 2006, 6:37:48 PM11/16/06
to
Boris wrote:
> Hi, is there any alternative software for Matlab? Although Matlab is
> powerful & popular among mathematical & engineering guys, it still
> costs too much & not publicly open. So I wonder if there's similar
> software/lang that is open & with comparable functionality, at least
> for numerical aspect. Thanks!

There is also Scilab. I've only used it a tiny bit but for the task it
worked well. I do know that it has a somewhat restrictive license. It
is open source, but you aren't allowed to modify and redistribute the
source. I get the feeling that some people avoid Scilab but I'm not
sure why. If anybody knows the reason I'd be happy to hear it.

Scilab website: http://www.scilab.org

-Matt

Filip Wasilewski

unread,
Nov 17, 2006, 2:17:49 PM11/17/06
to
sturlamolden wrote:
> Boris wrote:
> > Hi, is there any alternative software for Matlab? Although Matlab is
> > powerful & popular among mathematical & engineering guys, it still
> > costs too much & not publicly open. So I wonder if there's similar
> > software/lang that is open & with comparable functionality, at least
> > for numerical aspect. Thanks!
>
> I have used Matlab for years, and has recently changed to Python. In
> addition one needs NumPy and Matplotlib, and perhaps SciPy. Other
> useful packages are PyGTK for GUI, PyGame for multimedia, PyOpenGL for
> 3D graphics, Mpi4Py for parallel computation, etc. You will find python
> packages for nearly any conceivable task. Unlike Matlab, Python is a
> general purpose programming language, and a distant cousin of Lisp. The
> Python language is fare more expressive and productive than Matlab, yet
> even more easy to use.

Huh, so you don't think it's just damn sexy to do OOP, networking and
databases by multiplying matrices?;-)


> The NumPy package is the core requirement for numerical work in Python.
> It is quite different form Matlab, but I think it is more powerful.
> Particularly, arrays are passed by reference (not by value), and
> indexing creates view matrices.

For those interested in drilling down on this topic there is a Numpy
for Matlab Users guide at http://scipy.com/NumPy_for_Matlab_Users


> To compare Matlab with NumPy we can e.g. use the D4 discrete wavelet
> transform. I have here coded it in Matlab and Python/NumPy using Tim
> Swelden's lifting scheme.

[...]

Actually you have not. The algorithm you presented gives completely
wrong results. Have a look at quick&dirty(TM) implementation bellow.

import math
import numpy

def d2_lwt(x, axis=-1, level=None, copy=False):
"""
Daubechies2 (4 point support) Lifting Wavelet Transform in NumPy
"""
C1 = 1.7320508075688772 # sqrt(3)
C2 = 0.4330127018922193 # sqrt(3)/4
C3 = -0.066987298107780702 # (sqrt(3)-2)/4)
C4 = 0.51763809020504137 # (sqrt(3)-1)/sqrt(2)
C5 = 1.9318516525781364 # (sqrt(3)+1)/sqrt(2)

if not isinstance(x, numpy.ndarray) or x.dtype.kind != 'f':
x = numpy.array(x, dtype=numpy.float64)
elif copy:
x = x.copy()

max_level = int(math.floor(math.log(x.shape[axis],2)))
if level is None:
level = max_level
else:
assert level <= max_level, "Level param too high"

coeffs = []
cA = x.swapaxes(0, axis)
while level > 0:
level -= 1

# lazy
even = cA[::2]
odd = cA[1::2]

# dual
# using `even = even + C1*odd` may speed up things on
# some machines (only for not in-place transform).
even += C1*odd

# primal
odd[0] -= C2*even[0] + C3*even[-1]
odd[1:] -= C2*even[1:] + C3*even[:-1]

# dual
even[:-1] -= odd[1:]
even[-1] -= odd[0]

# scale
even *= C4
odd *= C5

cA, cD = even, odd
coeffs.append(cD.swapaxes(axis, 0))

coeffs.append(cA.swapaxes(axis, 0))
coeffs.reverse()
return coeffs

if __name__ == "__main__":
d = [1,5,3,2,4,8,5,2]
data = [
numpy.array(d, dtype=numpy.float32),
numpy.array(d, dtype=numpy.float64),
numpy.array([d]*2, dtype=numpy.float64),
numpy.array([d]*2, dtype=numpy.float32),
numpy.array(d, dtype=numpy.int32),
[d]*2,
[[d,d]]*3,
]

for i,x in enumerate(data):
print "Case %d:" % (i+1)
print "x in:\n", x
coeffs = d2_lwt(x, axis=-1, level=None, copy=False)
print "coeffs:"
for c in coeffs:
print c, c.dtype
print "x out:\n", x
print


Please excuse me not including Matlab version here, I would like to
have a free weekend.

As far as the speed comparison is concerned I totally agree that NumPy
can easily outperform Matlab in most cases. Of course one can use
compiled low-level extensions to speed up specific computations in
Matlab, but it's a lot easier and/or cheaper to find very good tools
for Python.


> If anyone wonders why I think Travis Oliphant and the NumPy team should
> be knighted, then this is the answer.

Would love to see the ceremony:)

cheers,
fw

Maarten van Reeuwijk

unread,
Nov 17, 2006, 7:15:48 PM11/17/06
to
sturlamolden wrote:

> Sorry Mathworks, I have used your product for years, but you cannot
> compete with NumPy.

Funny. I went exactly the other way. Had a full OO postprocessing library
for Python/Scipy/HDF etc which worked brilliantly. Then changed to a 64 bit
machine and spent three days trying to install all the additional libraries
that I had become dependent on over the year. In the end, I gave up
completely frustrated (something to do with a Fortran compiler in
combination with SciPy or something). Then I tried MATLAB and was
completely delighted that there was a program with all MY batteries
included :-).

BTW, I have the impression that MATLAB and SciPy have about the same
performance.

Cheers, Maarten
--
===================================================================
Maarten van Reeuwijk dept. of Multiscale Physics
Phd student Faculty of Applied Sciences
maarten.vanreeuwijk.net Delft University of Technology

sturlamolden

unread,
Nov 18, 2006, 1:57:00 PM11/18/06
to

Filip Wasilewski wrote:

> Actually you have not. The algorithm you presented gives completely
> wrong results. Have a look at quick&dirty(TM) implementation bellow.

God grief. I followed the implementation in Ingrid Daubechies' and Wim
Sweldens' original wavelet lifting paper (J. Fourier Anal. Appl., 4:
247-269, 1998). If you look at the factorized polyphase matrix for D4
(which gives the inverse transform), their implementation of the
lifting steps the original paper is incorrect. That is scary.

A free PDF or PS of the paper is available here:

http://cm.bell-labs.com/who/wim/papers/factor/index.html

Thanks a lot!


Sturla Molden

sturlamolden

unread,
Nov 18, 2006, 2:45:27 PM11/18/06
to

sturlamolden wrote:

> God grief. I followed the implementation in Ingrid Daubechies' and Wim
> Sweldens' original wavelet lifting paper (J. Fourier Anal. Appl., 4:
> 247-269, 1998). If you look at the factorized polyphase matrix for D4
> (which gives the inverse transform), their implementation of the
> lifting steps the original paper is incorrect. That is scary.
>
> A free PDF or PS of the paper is available here:
>
> http://cm.bell-labs.com/who/wim/papers/factor/index.html


Actually its more complicated than that. The PS and the PDF files are
different, and only the PS-file is confused. Here is the correct
explanation:

The factorization of the polyphase matrix is not unique. There are
several valid factorizations. Our implementations corresponds to
different factorizations of the analysis and synthesis poyphase
matrices, and both are in a sence correct, although numerically
different.

sturlamolden

unread,
Nov 19, 2006, 12:18:09 PM11/19/06
to

sturlamolden wrote:

> def D4_Transform(x, s1=None, d1=None, d2=None):
> """
> D4 Wavelet transform in NumPy
> (C) Sturla Molden
> """
> C1 = 1.7320508075688772
> C2 = 0.4330127018922193
> C3 = -0.066987298107780702
> C4 = 0.51763809020504137
> C5 = 1.9318516525781364
> if d1 == None:
> d1 = numpy.zeros(x.size/2)
> s1 = numpy.zeros(x.size/2)
> d2 = numpy.zeros(x.size/2)
> odd = x[1::2]
> even = x[:-1:2]
> d1[:] = odd[:] - C1*even[:]

> s1[0] = even[0] + C2*d1[0] + C3*d1[-1] #typ0
> s1[1:] = even[1:] + C2*d1[1:] + C3*d1[:-1] #typo


> d2[0] = d1[0] + s1[-1]
> d2[1:] = d1[1:] + s1[:-1]
> even[:] = C4 * s1[:]
> odd[:] = C5 * d2[:]
> if x.size > 2:
> D4_Transform(even,s1[0:even.size/2],
> d1[0:even.size/2],d2[0:even.size/2])


Actually, there was a typo in the original code. I used d1[l-1] where I
should have used d1[l+1]. Arrgh. Here is the corrected version, the
Matlab code must be changed similarly. It has no relevance for the
performance timings though.


def D4_Transform(x, s1=None, d1=None, d2=None):
"""
D4 Wavelet transform in NumPy
(C) Sturla Molden
"""
C1 = 1.7320508075688772
C2 = 0.4330127018922193
C3 = -0.066987298107780702
C4 = 0.51763809020504137
C5 = 1.9318516525781364
if d1 == None:
d1 = numpy.zeros(x.size/2)
s1 = numpy.zeros(x.size/2)
d2 = numpy.zeros(x.size/2)
odd = x[1::2]
even = x[:-1:2]
d1[:] = odd[:] - C1*even[:]

s1[:-1] = even[:-1] + C2*d1[:-1] + C3*d1[1:]
s1[-1] = even[-1] + C2*d1[-1] + C3*d1[0]

Filip Wasilewski

unread,
Nov 19, 2006, 3:28:56 PM11/19/06
to
sturlamolden wrote:
[...]

> Here is the correct explanation:
>
> The factorization of the polyphase matrix is not unique. There are
> several valid factorizations. Our implementations corresponds to
> different factorizations of the analysis and synthesis poyphase
> matrices, and both are in a sence correct, although numerically
> different.

Please correct me if I'm missing something but I'm pretty sure that
choice of polyphase matrix factorization for given wavelet filter bank
has influence only on speed and numerical stability of computation and
not on the result itself. Particularly it should be possible to
reconstruct analysis and synthesis filters from polyphase matrices
regardless of the chosen factorization and both the discrete wavelet
transform and the wavelet lifting scheme should give corresponding
results for chosen wavelet (one can be rewritten in the form of other).

cheers,
fw

Filip Wasilewski

unread,
Nov 19, 2006, 3:33:27 PM11/19/06
to

If you swap C4 with C5 then our solutions give identical results and
both match the classic dwt approach:

even[:] = C5 * s1[:]
odd[:] = C4 * d2[:]

> if x.size > 2:
> D4_Transform(even,s1[0:even.size/2],
> d1[0:even.size/2],d2[0:even.size/2])

cheers,
fw

Randy Yates

unread,
Nov 19, 2006, 6:32:17 PM11/19/06
to
"Boris" <auhg...@gmail.com> writes:

I cast another vote for Octave. While there are a few inconsistencies
(in the plot() command, e.g.) they are usually minor. It's the next
best thing to Matlab I've found, and I usually design my code to run
on either nowadays.
--
% Randy Yates % "...the answer lies within your soul
%% Fuquay-Varina, NC % 'cause no one knows which side
%%% 919-577-9882 % the coin will fall."
%%%% <ya...@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO
http://home.earthlink.net/~yatescr

Rob Purser

unread,
Nov 27, 2006, 10:16:54 AM11/27/06
to
Hi all,

I'm not going to touch the big picture issues here -- you need to pick the
right tool for the job you're doing, and only you know what works best for
your task. However, since it didn't come up, I feel I need to add a piece
of info to the mix, since I spend my days getting MATLAB working with data
acquisition hardware. To be clear, I'm the development lead for Data
Acquisition Toolbox, which is MathWorks' add on product to MATLAB and
Simulink to handle all the issues associated with interfacing data
acquisition hardware without all the CMEX work, threading, DLLs, etc. As
Sturla points out, that's not trivial work in any language.

Anyway, I just wanted to call your attention to Data Acquisition Toolbox:
http://www.mathworks.com/products/daq/

I'm not sure what hardware you're using, Phil, so I can't say whether we
support it. We do add support for new hardware all the time, so I'd be
interested in hearing about your application.

All the best,
-Rob

--
Rob Purser
Senior Team Lead, Connectivity Products
The MathWorks
rob.p...@mathworks.com

"sturlamolden" <sturla...@yahoo.no> wrote in message
news:1164504562.8...@l39g2000cwd.googlegroups.com...
>
> Phil Schmidt wrote:
>
>> Thanks for that list. I'm currently in the process of getting quotes
>> for a bunch of Matlab tools for hardware-in-the-loop simulation. Big
>> bucks.
>
> Yup, and better spent elsewhere...
>
>
>> I'd love to use Python, but I'm not comfortable with the hardware side
>> of that. I'm certain that most, if not all data acquisition hardware
>> comes with DLL drivers, which I could interface with using ctypes. I'm
>> concerned though about spending more time messing around with the
>> hardware interface than it's worth.
>
> Usually you have to mess equally much with Matlab, writing CMEX
> interfaces between the DLLs and Matlab. And afterwards you get the
> headache of Matlab's single-threaded environment and horrible
> pass-by-value sematics.
>
>
>> Do you have any experience with this side of the Matlab replacement
>> question? How about anyone else? Any recommendations?
>
> If you are afraid of doing some C coding or using ctypes, I'd say go
> for LabView. When it comes to data acquisition, LabView is far superior
> to Matlab. And data acquisition hardware usually comes with LabView
> drivers ready to run. LabView can also compile programs that you can
> run on real-time OS'es and common DSP chips, so you will not need to
> port your code to these targets if you need hard real-time constraints
> in your system.
>
> First find out what drivers or APIs are supplied with the hardware.
> Then do the decision of which language to use - including Python,
> Matlab, LabView, Java, C# .NET, C or C++. I would in any case get a
> quote for LabView as well, i does not cost you anything just to obtain
> the quote. Generally, development time is far more expensive than
> licenses, even with the ultra-expensive Matlab and LabView software.
> Using Python just for the sake of using Python is silly.
>


sturlamolden

unread,
Nov 27, 2006, 7:12:17 PM11/27/06
to

Rob Purser wrote:

> Anyway, I just wanted to call your attention to Data Acquisition Toolbox:
> http://www.mathworks.com/products/daq/

Absolutely. If the hardware is supported by this toolbox, there is no
need to reinvent the wheel. The license is expensive, but development
time can be far more expensive. Matlab is an excellent tool for
numerical work.

However, Matlab is only single-threaded and does not optimize its
pass-by-value semantics with proper 'escape analysis'. (Yes, Matlab
does lazy copy-on-write to optimize function calls, but functions have
return values as well.) I have (temporarily?) stopped using Matlab
because I constantly got annoyed by the limitations of the language. I
still use Matlab as an advanced desktop calculator though. Somehow I
find it easier to type in an expression in Matlab than NumPy, probably
because I am more accustomed to the syntax.

Eric Sampson

unread,
Nov 29, 2006, 6:23:36 PM11/29/06
to
sturlamolden wrote:
>
> I have used Matlab for years, and has recently changed to Python.
> To compare Matlab with NumPy we can e.g. use the D4 discrete
> wavelet
> transform. I have here coded it in Matlab and Python/NumPy using
> Tim
> Swelden's lifting scheme.
>
(snip code)


> Now let's do benchmark on my laptop (1.73 GHz Pentium M, 0.99 GB
> RAM).
> I have stopped paying for Matlab maintenance (for reasons that will
> be
> obvious), so I only have R14 Service Pack 2 for comparison.
>
> First we try Matlab (R14 Service Pack 2):
>
>>> x = rand(2^23,1);
>>> tic; D4_Transform(x); toc
> Elapsed time is 27.145438 seconds.
>
>
> Then we Python 2.4.4 with NumPy 1.0:
>
> C:\develop\python\D4>python D4.py
> Elapsed time is 3.364887 seconds
>
(snip)
> Cheers,
> Sturla Molden
>

Hi Sturla,

For comparison purposes, I ran your code under MATLAB R2006b and
Python 2.4.4, both on my P4 3GHz laptop with 1GB of ram. I obtained
the following timing:

Python: 1.88 sec
MATLAB: 2.85 sec (your code)
MATLAB: 2.35 sec (my code, slight mods)

Although Python maintains an advantage, it is not nearly as dramatic
as your timings.

Best regards,
Eric Sampson
The MathWorks,Inc.

aap

unread,
Nov 29, 2006, 6:52:05 PM11/29/06
to

John Henry wrote:
> Bill Gates will have you jailed! :-)
>
> On a more serious note, is there any alternative to Simulink though?
>
It's called SciCos, and as far as I've seen it not only covers Simulink
but also PowerSim.

I found only 1 major disadvantage inSciLab, ...
... it has no ActiveX

cheers,
Stef Mientki

Dmitrey

unread,
Nov 30, 2006, 10:33:29 AM11/30/06
to
It seems to me the speed comparison will be determed by 2 main
factors: algoritmic base, which currently is much more better in
MATLAB, & speedup via JIT accelerator and similar thing for Python (I
don't know how it is called, despite I used Python some years ago &
find it much more convinient vs MATLAB)
As for me I found Octave to be very useful & free, that is very
important vs MATLAB, espesially in 3rd-party countries. I hope they
will add something like JIT accelerator soon

Jon Harrop

unread,
Dec 3, 2006, 12:00:12 AM12/3/06
to
Carl Banks wrote:
> No, they're never redefined (even in the recursive version). Slices of
> them are reassigned. That's a big difference.

I see.

> (Actually, it does create a temporary array to store the intermediate
> result, but that array does not get bound to odd.)

Sure.

>> In particular, I think you are eagerly
>> allocating arrays when, in a functional language, you could just as
>> easily compose closures.
>
> You are completely wrong.

I'll give an example. If you write the Python:

a[:] = b[:] + c[:] + d[:]

I think that is equivalent to the ML:

fill a (map2 ( + ) (map2 ( + ) b c) d)

which can be deforested in ML to avoid the creation of the intermediate
result b[:] + c[:] by using a closure to add three values at once:

fill a (map3 (fun b c d -> b + c + d) b c d)

which will be much faster because it doesn't generate an intermediate array.

> This data sharing more or less accomplishes the same thing that the
> "closures" you speak of accomplish (in this case), only without the
> functional.

The closure avoided the intermediate result. You said that the Python isn't
doing that?

> It's not correct, but what you left out is probably low cost.
>
> OCaml is compiled to machine code, right?

Yes.

> And types can be inferred at compile time, correct?

Types are completely inferred at compile time.

> Well then of course it's faster.

Yes. So this doesn't seem to be a killer example of numpy, although I am
still amazed that it can outperform Matlab.

> It seems to
> me a big help is the ability to fold multiple array operations into a
> single loop, which is optimization a dynamically-typed language like
> Python can't easily make. (It'd require are really smart JIT compiler
> or some concessions in dynamicity.)

Writing a JIT to compile this kind of stuff is easy. My point is that this
is fundamentally bad code, so why bother trying to write a Python JIT? Why
not just write in a better language for this task? Optimising within a
fundamentally slow language seems silly to me.

--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Dmitrey

unread,
Dec 3, 2006, 4:11:09 AM12/3/06
to
>Why not just write in a better language for this task?

Because caml with all his features, despite a few lines of code to use vs many other languages, is VERY, VERY difficult language for ordinary students (at least, in comparison with Python, MATLAB/Octave, even C++), so very little number of high schools will study this one, and a little bit of software (including scientific) will be written; and a little bit of caml programmers will be available for hiring. So using program & algorithmic base of other languages seems to be more prefereble.

>Writing a JIT to compile this kind of stuff is easy. My point is that this is fundamentally bad code, so why bother trying to write a Python JIT?

Some monthes ago I encounted a rewiev of benchmark, where JIT-optimiezed Java code took exactly the same cputime as C++ (cputime was decriased in a factor of 5). So, since Python is so wide-spreaded, appearing a JIT-accelerator for Python (if it's doesn't exist yet) is just a matter of time. Moreover, Python language has implementation JPython (written in Java, along with CPython in C++), so I guess using JIT for Java will be easy in the case.

>Why not just write in a better language for this task?
>Optimising within a fundamentally slow language seems silly to me.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

"The point of view depends of place taken" :)

Jon Harrop

unread,
Dec 3, 2006, 5:25:07 PM12/3/06
to
Dmitrey wrote:
>>Why not just write in a better language for this task?
>
> Because caml with all his features, despite a few lines of code to use vs
> many other languages, is VERY, VERY difficult language for ordinary
> students (at least, in comparison with Python, MATLAB/Octave, even C++),

I didn't mean OCaml specifically, C++ is just as suitable for this task.

> so very little number of high schools will study this one,

ML and Lisp are actually widely taught, the former in Europe and the latter
in North America. I've never heard of Python being taught but I may be out
of date. Matlab was taught to engineers at my university.

> and a little
> bit of software (including scientific) will be written; and a little bit
> of caml programmers will be available for hiring. So using program &
> algorithmic base of other languages seems to be more prefereble.

Yes. But there are plenty of other languages that are both common and more
suitable for this kind of work: C, C++, Java, C#...

>>Writing a JIT to compile this kind of stuff is easy. My point is that this
>>is fundamentally bad code, so why bother trying to write a Python JIT?
>
> Some monthes ago I encounted a rewiev of benchmark, where JIT-optimiezed
> Java code took exactly the same cputime as C++ (cputime was decriased in a
> factor of 5). So, since Python is so wide-spreaded, appearing a
> JIT-accelerator for Python (if it's doesn't exist yet) is just a matter of
> time. Moreover, Python language has implementation JPython (written in
> Java, along with CPython in C++), so I guess using JIT for Java will be
> easy in the case.

Well, Python has been around for several years and, AFAIK, doesn't have a
fast implementation. In contrast, F# has been around for much less time and
is already vastly faster.

Anyway, when a fast Python/Matlab implementation does appear, you're going
to be lumbered with lots of code that has been "optimised" to use slices.
To get competitive performance an optimiser would then have to boil the
slice-based code down to the array operations that you actually wanted to
perform before compiling it. So the sooner there are fast Python/Matlab
implementations the better!

Steve Eddins

unread,
Jan 12, 2007, 2:00:11 PM1/12/07
to
sturlamolden wrote:

> I have used Matlab for years, and has recently changed to Python.

> [snip detailed comparison of MATLAB and Python performance for some wavelet code]

Sturla's post comparing MATLAB and Python caught our attention. We have
run some performance comparisons
of MATLAB and Python, and we've looked into the specific code sample
that Sturla provided. (Note: I
didn't do the benchmarking work myself; I just volunteered to summarize
it for the newsgroup.)

Here are some of the operations we tested:

* Assignment
* Binary operators
* IF
* Array growth
* Calling built-in functions
* Calling user-written functions
* Triply-nested loops
* Real general eigenvalues
* Real symmetric eigenvalues
* Complex eigenvalues
* Real SVD
* Complex SVD
* Real matrix inverse
* Complex matrix inverse
* Least-squares solution
* Complex FFT

On a Win64 machine, we found MATLAB to be significantly faster than
Python on almost all of these tests.
The one exception where Python was faster was in calling user-written
functions.

So what's the story with Sturla's code? It turns out that the expensive
lines were like this:

s1(2:end) = even(2:end) + C2*d1(2:end) + C3*d1(1:end-1);

But does this mean that MATLAB was slower at arithmetic than Python?
No, it means that MATLAB was
allocating more temporary memory than Python, and the memory allocation
time was dominating the
computation time.

Historically, when computing an expression like this:

2*b + c*d

MATLAB would allocate space for the intermediate arrays such as (2*b)
and (c*d). But in recent years,
MATLAB has been automatically generating machine code that computes the
entire expression without
allocating any extra memory. At MathWorks, we often refer to this
automatic optimization machinery as the
MATLAB JIT, where JIT stands for just-in-time code generation.

The JIT currently optimizes 2*b + c + d, but it does not yet optimize
some expressions that are indexed
the way Sturla's are.

But the JIT gets better every six months, with each new release of
MATLAB. And "reports from the field"
like Sturla's help us prioritize our JIT work. In fact, Sturla's post
was unusually helpful to us because
it was so specific, so I'd like to thank him (belatedly) for taking the
time to write up his experiences.
This kind of information gives us valuable guidance on how to invest in
the JIT and in MATLAB overall.

--
Steve Eddins
http://blogs.mathworks.com/steve

Stef Mientki

unread,
Jan 12, 2007, 3:38:34 PM1/12/07
to
Steve Eddins wrote:
> sturlamolden wrote:
>
>> I have used Matlab for years, and has recently changed to Python.
>
>> [snip detailed comparison of MATLAB and Python performance for some
>> wavelet code]
>
> Sturla's post comparing MATLAB and Python caught our attention. We have
> run some performance comparisons
> of MATLAB and Python, and we've looked into the specific code sample
> that Sturla provided. (Note: I
> didn't do the benchmarking work myself; I just volunteered to summarize
> it for the newsgroup.)
> On a Win64 machine, we found MATLAB to be significantly faster than
> Python on almost all of these tests.
> The one exception where Python was faster was in calling user-written
> functions.
>
Coming from MatLab, I've been playing around with Python (Enthought
-edition) for a few weeks now, and indeed all my functions were 3..7
times faster in Python. A did some tests on several machines around
here, all winXP, all 32bit, 2.5 GHz AMD / 3.x GHz Intel, and relative
differences were all equal.
In these cases I just rewrote the MatLab functions almost 1:1 to Python,
but made use of the more extensive basic math functions available in
Python.
I guess even more can be achieved, certainly in readability of the
programs, by using Python's OOP-functionality.

Although I didn't investigate where the difference came from,
I've the feeling that the following issues play an important role:
- Python does the calculation inplace if it can be done inplace
- There a lot more basic function, e.g. a function that calculates
mean and SD simultaneously in the same run
- When some calculation can be written faster, one day or the other,
someone will write the faster code

And another major improvement is the memory footprint:
Matlab: 110 MB
Python: 10..20 MB
I couldn't determine exactly Python's footprint, because I used it
embedded in a Delphi application.

> So what's the story with Sturla's code? It turns out that the expensive
> lines were like this:

That might be another advantage of Python, Python is much less sensitive
for the exact notation of the user. I followed a number of discussions
the past few weeks about optimizations, and the results of the different
user notations are just a few percent.

And for the record some very subjective difference, although you all
helped me well to solve my problems, the answers are always somewhat
formal, e.g. look in that manual (covering 100 times as much than I
asked, "the tree and the forest problem"), logging in at Mathworks, to
watch "webinairs" (which should be seen as an "free" advertisement, open
for everyone), and which didn't run on most computers I was working on
:-(. In the Python newsgroups, the answer points to the "tree" and they
even tell you something about the "leaves".

For now it's too early to call myself a "former" MatLab user,
but Python is certainly interesting to investigate further.

cheers,
Stef Mientki

Charles Cuell

unread,
Jan 16, 2007, 9:38:02 AM1/16/07
to
Dear all,

I'm interested in knowing about development time, rather than actual
performance. When the theory that the code is based on is still in
development, the amount of time it takes to write or modify code far
outweighs a few seconds of performance gain or loss.

I've found my work to be far more productive when I use Matlab than
when I use C++, simply because I can experiment and test new ideas
far more quickly.

My question is: how does NumPy compare to Matlab with respect to
actually writing, modifying and debugging code?

Thanks in advance for any opinions on this. I've been lurking about
for a while and have found some very useful tips from various posts.

stef

unread,
Jan 16, 2007, 10:25:50 AM1/16/07
to

> Dear all,
>
> I'm interested in knowing about development time, rather than actual
> performance. When the theory that the code is based on is still in
> development, the amount of time it takes to write or modify code far
> outweighs a few seconds of performance gain or loss.
>
> I've found my work to be far more productive when I use Matlab than
> when I use C++, simply because I can experiment and test new ideas
> far more quickly.
>
I think that yields for all modern scripting languages: interactive +
80% reduction of code

> My question is: how does NumPy compare to Matlab with respect to
> actually writing, modifying and debugging code?
>
although I've only 3 weeks experience with SciPy/Numpy/Python,
here are my experiences:
- writing: SciPy is much better: more procedures in 1 file, OOP, very
easy to write any calculation fully vectorized
(some may find this a disadvantage: syntax of Python is more relaxed:
more syntaxes are possible, index of an array is automatically limited
at its bounds)
- modifying: see also writing, SciPy is very modular, and both
embedding and encapsulation with all kinds of languages are possible
- debugging: about equal, there are some real IDE's, in which
conditional breakpoints, variable tracking are possible.
Above all, you can rewrite MatLab routines almost 1:1 to SciPy,
of course you can get more out of Scipy, by writing "Pythonion".

Until now I found only 2 disadvantages:
- Simulink and Powersim is missing (but I don't think it's too
difficult to write that in Python ;-)
- there seems to be nobody who knows Python

cheers,
Stef Mientki

Peter Wang

unread,
Jan 18, 2007, 1:07:07 PM1/18/07
to
stef wrote:
> Until now I found only 2 disadvantages:
> - there seems to be nobody who knows Python

Do you mean in the scientific community, or in general? In the
computing community, Python is extremely well-established, with big
players like Google using it extensively. Python is used everywhere
from networking applications (like bittorrent) to massively-multiplayer
RPGs.

In the scientific/academic arena, there is a large community of users
of python and numpy/scipy, including national labs and various smaller
research institutions. There is also an annual conference at CalTech
(SciPy) in the fall.

So, not quite nobody, but certainly not nearly as many people as the
Matlab community. :)

-peter

Stef Mientki

unread,
Jan 18, 2007, 2:21:50 PM1/18/07
to
Peter Wang wrote:
> stef wrote:
>> Until now I found only 2 disadvantages:
>> - there seems to be nobody who knows Python
>
> Do you mean in the scientific community, or in general? In the
> computing community, Python is extremely well-established, with big
> players like Google using it extensively. Python is used everywhere
> from networking applications (like bittorrent) to massively-multiplayer
> RPGs.
>
> In the scientific/academic arena, there is a large community of users
> of python and numpy/scipy, including national labs and various smaller
> research institutions.

Not in the Netherlands.
The last past months I visited 4 universities,
following at each a promotional day to get new students,
and all I saw was MatLab (90%) and LabView (10%).
Only at the information departments they use sometimes Python.
Now the funny thing is that these figures for MatLab and LabView
correlates very good with the inverse of the price:
MatLab = €40, LabView = €2500,
so if these guys knew Python and knew the price of Python .... ;-)

cheers,
Stef Mientki

Mark

unread,
Feb 1, 2007, 9:04:21 AM2/1/07
to
you may see that "no one" uses python but that doesn't stop you from
using it
I got into python from using Gentoo-linux (and digging around
portage) and the more I used it the more I started seeing how I could
use it in place of some basic manipulation (which I do in matlab)

further investigation and I came across NumPY and Matplotlib and I
havn't looked back since.

My deployment (and also stored on mem stick) is:
Python+numpy+matplotlib+scipy+pygtk

it is alot quicker to knock togeher a script to manipulate numbers
and alot more flexable then matlab script. So much so that while I
still use simulink (nothing comes close), all the data I want to
manipulate is stored to a file and then manipulated & plotted via
python

so far got a couple of people in my dept using Python for quite a few
things (as well as hardware iteraction... via USB)

stef

unread,
Feb 1, 2007, 9:47:25 AM2/1/07
to
Mark wrote:
> you may see that "no one" uses python
:-)

> but that doesn't stop you from
> using it
> I got into python from using Gentoo-linux (and digging around
> portage) and the more I used it the more I started seeing how I could
> use it in place of some basic manipulation (which I do in matlab)
>
> further investigation and I came across NumPY and Matplotlib and I
> havn't looked back since.
>
> My deployment (and also stored on mem stick) is:
> Python+numpy+matplotlib+scipy+pygtk
>
isn't that about the same as the "Enthought" edition ?

> it is alot quicker to knock togeher a script to manipulate numbers
> and alot more flexable then matlab script. So much so that while I
> still use simulink (nothing comes close), all the data I want to
> manipulate is stored to a file and then manipulated & plotted via
> python
>
> so far got a couple of people in my dept using Python for quite a few
> things (as well as hardware iteraction... via USB)
>
We do real time data-acquisition with (NI) USB cards through Python ;-)

cheers,
Stef Mientki

Dan Mac

unread,
Feb 1, 2007, 9:50:16 AM2/1/07
to
You know I really like the principle of using Octave. It's free (in
both senses) but Matlab is so much nicer. The Matlab experience is
what really set's it apart (aside from it's price).

I'm sure the company I work for (with upwards of 8,000 engineers)
probably spends hundreds of thousands of dollars on maintenance fees
every year. Sure Octave would save tons of money, but it just
doesn't compete. And I think that rather than catching up with
Matlab, it is falling further behind.

I suppose that as more people use Matlab, Mathworks generates more
revenue and can drive improvements even quicker.

NOW IF THEY'D ONLY LET ME TAKE ADVANTAGE OF MULTIPLE PROCESSORS ON MY
OWN DESKTOP. The 2007a prerelease attempt at this is only
half-hearted.

stef

unread,
Feb 1, 2007, 9:54:41 AM2/1/07
to

> My deployment (and also stored on mem stick) is:
> Python+numpy+matplotlib+scipy+pygtk
>
> it is alot quicker to knock togeher a script to manipulate numbers
> and alot more flexable then matlab script. So much so that while I
> still use simulink (nothing comes close),
SciCos perhaps ?
or
Python + Modelica ?

david bateman

unread,
Feb 2, 2007, 7:44:17 PM2/2/07
to
On Feb 1, 3:50 pm, "Dan Mac" <lesrica...@DonTsPamMyGmail.com> wrote:
> You know I really like the principle of usingOctave. It's free (in

> both senses) but Matlab is so much nicer. The Matlab experience is
> what really set's it apart (aside from it's price).
>
> I'm sure the company I work for (with upwards of 8,000 engineers)
> probably spends hundreds of thousands of dollars on maintenance fees
> every year. SureOctavewould save tons of money, but it just

> doesn't compete. And I think that rather than catching up with
> Matlab, it is falling further behind.
>
> I suppose that as more people use Matlab, Mathworks generates more
> revenue and can drive improvements even quicker.
>
> NOW IF THEY'D ONLY LET ME TAKE ADVANTAGE OF MULTIPLE PROCESSORS ON MY
> OWN DESKTOP. The 2007a prerelease attempt at this is only
> half-hearted.


Dan,

Does the above really help anyone? You stated you don't think octave
stacks up, but not why? What is your problem and why exactly doesn't
octave meet your needs? Now that would be useful information.

D.

us

unread,
Feb 2, 2007, 9:30:29 PM2/2/07
to
Boris:
<SNIP never-ending search for ML-alternative...

> Hi, is there any alternative software for Matlab...

in brief: NO, there isn't
anyone who tells you otherwise shall show you that the alternative is
capable of this:

% at the command prompt, type
makepizza(gcf,...
'position','myhome',...
'flavor','margherita',...
'size','singlewithoutfemalefriend',...
'deliverytime',datestr(clock),...
'deliverymode','myscreen',...
'payment',{'visa',your_visa_number});
% -now- keep your plate ready for what's popping
% out of your screen...
% for all the very many possible options, type
help makepizza;

us

Anonymous ;)

unread,
Apr 4, 2007, 5:20:38 PM4/4/07
to
Another good free (but not open source) MATLAB clone is Sysquake LE.
It is my favourite among the M-clones. It is small (2 Mb) but don't
let that fool you; it has most of the power of base MATLAB plus some
of the toolboxes in addition to features that MATLAB does not have
(such as interactive graphics). In some features it is behind MATLAB,
but most of the important stuff is there. Very powerful and actually
faster than MATLAB (I believe because most functions are implemented
as "built-ins", that is, precompiled rather than m-script files
(.sq-files). I use it as a quick prototyping calculator on machines
that don't have a licensed copy of MATLAB installed. IT is easy to
write code that will run on both systems.

FreeMat is another open-source system worth checking out but it still
needs time to mature. It can be sufficient for some uses, though.

Another thing most people won't tell you is that you can use,
sometimes with very little modification, m-files from the immense
MATLAB and MATLAB-compatible libraries such as octave's, FreeMat's,
Sysquake's, etc., to solve problems so as to avoid having to
re-invent the wheel.

John Marcovici

unread,
Apr 4, 2007, 10:33:15 PM4/4/07
to
I'm surprised no one has mentioned IDL. I no longer use it because
everyone in my group uses Matlab, but IDL is very cool and nearly as
easy to use as Matlab. If you've done FORTRAN programming then you
can write IDL with your eyes closed.

It's not AS flexible as Matlab, but it is quite flexible. One
advantage over Matlab is that you do have the option to create
"projects" and then actually compile them. Is it faster? Probably,
but I can't perform a shoot out since my code has all gone away as
well as my IDL. Naturally it is not free either. But it's cool and I
hope it's still thriving. I may not use it, but, like Alaska, I like
knowing it's there.

Steve.A...@ricardo.com

unread,
Apr 5, 2007, 4:44:32 AM4/5/07
to
Alternatives to Matlab?

I've always been disappointed that none of the alterntives has a
Simulink equivalent. But I downloaded the most recent scilab/scicos
the other day and was pleasantly surprised by how good it now is. But
most of all, there is a committment to support Modelica, which will
place it ahead of Simulink in terms of modelling tools.

Rob S

unread,
Apr 5, 2007, 10:55:06 PM4/5/07
to
Good question, a bit mutinous for this newsgroup, but I like it!

One alt not mentioned yet is R. It's a free derivative of S-language
(written by the same folks) and is quite elegant. It's mainly
mathematical, and probably doesn't have all the toolbox capabilities
as Matlab. However, I don't use all the toolboxes, and I find
R-language to be powerful. I think more Universities should teach
it.

<http://www.r-project.org/>

Xaero Chang

unread,
Apr 6, 2007, 9:09:17 AM4/6/07
to
Boris wrote:
>
>
> Hi, is there any alternative software for Matlab? Although Matlab
> is
> powerful & popular among mathematical & engineering guys, it still
> costs too much & not publicly open. So I wonder if there's similar
> software/lang that is open & with comparable functionality, at
> least
> for numerical aspect. Thanks!
>
>
Scilab highly recommended!
In fact Scilab and Matlab are "brothers"

Amir Ibrahim

unread,
Apr 8, 2007, 10:01:25 PM4/8/07
to
Well, at the end of the day, the toolboxes + simulink + java/activeX
= Matlab is un-beatable to me.

Yeah, the other tools can be used for limited applications, but if
you want ONE tool to do it all, it is MATLAB :)

This is just the way it is: You GET what you PAY for :)

Cheers..

Chris

unread,
Apr 14, 2007, 7:43:04 AM4/14/07
to
Modelica
Scilab (Scicos)

John Henry wrote:
>
>
> Bill Gates will have you jailed! :-)
>
> On a more serious note, is there any alternative to Simulink
> though?
>

> sturlamolden wrote:
>>and is infinitely
>> more expensive.
>>
>> Does anyone wonder why I am not paying for Matlab maintenance
> anymore?
>>
>> Sorry Mathworks, I have used your product for years, but you
> cannot
>> compete with NumPy.
>>
>>
>> Cheers,
>> Sturla Molden
>
>

Anonymous ;)

unread,
Apr 20, 2007, 10:09:00 AM4/20/07
to
LabView (not free) and FlowDesigner (free).

Others exist too but I don't know much about them.

Laks

unread,
Apr 20, 2007, 12:38:53 PM4/20/07
to
Anonymous ;) wrote:

PV-WAVE by VNI group

Anonymous ;)

unread,
May 7, 2007, 1:04:34 AM5/7/07
to
Lush seems like an interesting alternative. Cool thing is that you
can mix lush and C code!

Per Jacobsen

unread,
Sep 12, 2016, 5:35:11 PM9/12/16
to
Sure... MLAB (www.parotruno.com)


"Boris" <auhg...@gmail.com> wrote in message <1161613941.5...@e3g2000cwe.googlegroups.com>...
Reply all
Reply to author
Forward
0 new messages