From: Joel Eriksson (jen_at_ettnet.se)
Date: 2001-12-27 09:02:24
On Sat, Dec 22, 2001 at 04:23:12PM -0000, sademade wrote:
> > As someone pointed out earlier, making portable libraries for the
> > signal processing etc is of highest priority. I would suggest coding
> > those routines in C. Wrappers for VB, C++, Delphi, etc can be based
> > on the C-library functions.
>
> What would be the problem to produce those with Matlab and it's
> C-generator Matcom ? No-one has answered what is problem with
> that idea, as it should be fastest way to produce it fastest,
> taking time out from having to fool months with it and do it
> in days, instead.
Does Matcom generate independent code or does it interface with
Matlab? If it generates independent code then I have nothing
against starting out with Matcom-generated code.
The signal processing code is the most critical piece of code
in the entire project and should therefore be made as portable
_and_ efficient as possible. It should compile cleanly for
embedded systems as well as Win32, etc.
> Matlab and matcom is out there running on linuxes too, and once
> generated, the code is royalty free open code, and C++. What
> is the big problem with that, how is hand-coding the routines
> from scratch as per some signal processing books faster, and
> easier or more portable than C++ source code from mat+com ?
It's definitely not faster or easier, but if we end up depending
on Matlab being installed doing it the easy way it would be worth
the effort to hand-code the routines from scratch. There may be
a golden middle-way though.
If we have defined an interface for feeding data to the signal
processing code and getting the info we want from it then we can
start out with Matcom-generated code that is adapted to that
interface and make a hand-coded replacement later. The important
thing is that those building applications on top of the base
library will not be forced to change their code.
> Definitely several of this list members would have access to
> those tools, and could take the DSP/SP routines out of the way
> in matter of days instead of months, that way, and all very very
> portable. Tested and proven case.
Be my guest and go ahead, but please don't release anything with
a sloppy interface. The end applications should not be dependent
on Matlab.
The people that are experienced with EEG-measuring and know what
data that is interesting and what may be a suitable representation
for it should work out an interface together with the developers.
> Appreciate, Sade M.
-- Joel Eriksson
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:36 BST