prototyping and migrating code to production: MATLAB, C, C++, asm

On 9/28/2013 9:49 PM, robert bristow-johnson wrote:
>
> forgot to thank you all.  it was mostly to inform a software manager and
> you guys 100% reinforced what i was saying to him.
>
> i would still be interested in hearing from Vlad what he does going
> sorta "MATLAB commando".  no tools other than the ones you make
> yourself, Vlad?  (i actually sorta did that previous to the mid 90's,
> but my homemade tools were crude.  i could draw graphs, load and display
> and playback simple AIFF and WAV files and write them, do basic
> elementary functions, and had a crude homemade Remez exchange alg and
> crude homemade matrix operations.)

Sorry for being brief, I am currently busy fixing client project. At the 
beginning, they did common mistake of playing with graphic IDE instead 
of developing code and algorithms. Now it is finally falling apart, and 
the timeline is approaching.

Graphic tools are sale tools.

Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

On 9/29/2013 7:45 AM, mnentwig wrote:
>>> to inform a software manager
>
> I've seen too many proprietary software tools that give a very polished
> _illusion_ of making problems disappear, when in reality they are just
> hidden or postponed. I would take a late-adopter attitude, stay clear of
> non-proven tools or methodologies. Spinning your own tools isn't good for
> pretty powerpoint slides but usually gets the job done. And you have the
> competence (=consultants) in-house.

Oh. Finally, the word of experienced person. As opposed to mumble of 
pompous windbag or idiots ravings.

On 29/09/13 13:45, mnentwig wrote:
>>> to inform a software manager
>
> I've seen too many proprietary software tools that give a very polished
> _illusion_ of making problems disappear, when in reality they are just
> hidden or postponed. I would take a late-adopter attitude, stay clear of
> non-proven tools or methodologies. Spinning your own tools isn't good for
> pretty powerpoint slides but usually gets the job done. And you have the
> competence (=consultants) in-house.

Too bloody true :(

On Sun, 29 Sep 2013 10:25:07 -0500, Vladimir Vassilevsky
<nospam@nowhere.com> wrote:

>On 9/28/2013 9:49 PM, robert bristow-johnson wrote:
>
>> i would still be interested in hearing from Vlad what he does going
>> sorta "MATLAB commando".  no tools other than the ones you make
>> yourself, Vlad?  

<...>

>Sorry for being brief, I am currently busy fixing client project. At the 
>beginning, they did common mistake of playing with graphic IDE instead 
>of developing code and algorithms. Now it is finally falling apart, and 
>the timeline is approaching.
>
>Graphic tools are sale tools.

My most recent contract stipulated that proof-of-concept was to be
written in MATLAB, but that the deliverable software was to be
written in C. I took a lot of heat for "writing a MATLAB script
that looked like a C program", but after the flashy
proof-of-concept demonstration, the translation to C was much
simplified.

The most difficult problem was the off-by-1 indices.

Greg

On Friday, September 27, 2013 1:01:59 AM UTC+2, robert bristow-johnson wrote:
> okay guys, what do you do, if you start with an alg that works pretty 
> 
> good in MATLAB/Octave/MathCad/Mathematica/whatever, and you wanna make 
> 
> production code out of it.  let's pretend the production code will be C. 
> 
>   what do you do?
> 
> 
> 
> rewrite it yourself, line by line?
> 
> 
> 
> use http://www.mathworks.com/products/matlab-coder/ ?
> 
> 
> 
> something else? (i guess i would also be interested in hearing from Vlad 
> 
> about what he does instead of what the silly Matlabies do.)
> 
> 
> 
> thanks for opinions.

the same as most of you, but on a related note, on my todo list is to try orcc rvc-cal and a python llvm generator called numba.
both being young and fast moving projects.

> r b-j                  rbj@audioimagination.com
>
> "Imagination is more important than knowledge."

On 9/29/13 9:58 AM, Greg Berchin wrote:
> On Sun, 29 Sep 2013 10:25:07 -0500, Vladimir Vassilevsky
> <nospam@nowhere.com>  wrote:
>
>> On 9/28/2013 9:49 PM, robert bristow-johnson wrote:
>>
>>> i would still be interested in hearing from Vlad what he does going
>>> sorta "MATLAB commando".  no tools other than the ones you make
>>> yourself, Vlad?
>
> <...>
>
>> Sorry for being brief, I am currently busy fixing client project. At the
>> beginning, they did common mistake of playing with graphic IDE instead
>> of developing code and algorithms. Now it is finally falling apart, and
>> the timeline is approaching.

i think i understand what that is about.

>> Graphic tools are sale tools.

my only difference with you, here, Vlad is (as Greg mentions) the proof 
of concept.  getting the *alg* right before making the effort to code 
it.  i don't want to waste effort coding an alg that sounds like crap 
and using a tool like MATLAB or Octave gives me some opportunity to test 
how it sounds with less effort than coding it up in C and then coding up 
testing methodologies.

one case in point (that i think i dare mention), over the years 
(decades) i have written a few monophonic pitch detectors (maybe not in 
the league of the Melodyne guys).  this is, at least for me, a 
"frame-by-frame" sorta operation: plop down a frame pointer, window the 
audio, do your magic, get your parameters you seek, bump the frame 
pointer ahead another, say, 512 samples and do it again.  with MATLAB or 
Octave i have been able to plot intermediate data (say the output of an 
FFT or the output of an AMDF or something), check and see if my alg is 
making the decisions i want it to make and fix it or adjust thresholds 
or whatever.  *that* is what i need graphic tools.

the other thing i have done is port some data from the production 
platform (usually as ASCII) to MATLAB or Octave and use the analysis 
tools there (like plotting and FFT) to check for numerical correctness 
and check also on sanity (like when the input or intermediate data in 
the target appears to be pure excrement).

perhaps the best would be a *painless* (and getting GNU to work for you 
is not in any manner painless) library of C or C++ classes, so you could 
do complex math and matrix math nearly as easy as with MATLAB.  but you 
would also need a set of good plotting functions, including a 
3-dimensional plotting function (like surf() in MATLAB) to visualize 
this data.

a free C++ class lib that is as easy to use as most MATLAB tools would 
be the coolest because there might be very little effort needed to port 
to the production platform.

> My most recent contract stipulated that proof-of-concept was to be
> written in MATLAB, but that the deliverable software was to be
> written in C. I took a lot of heat for "writing a MATLAB script
> that looked like a C program",

what about, errrr, looks like you address it below...

> but after the flashy proof-of-concept demonstration, the translation
> to C was much simplified.
>
> The most difficult problem was the off-by-1 indices.

don't get me started, Greg.  that is *still* (after 2 decades) the most 
inexcusable thing about MATLAB, which Octave and R (and who else?) 
evidently like to emulate.  now, again, i think i'm gonna cross-post 
this.  see if the MathWorks folks want to weigh in.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

>
>I've seen too many proprietary software tools that give a very polished
>_illusion_ of making problems disappear, when in reality they are just
>hidden or postponed. 


It sounds like you should be able to mention a lot of software tools
then....


I would take a late-adopter attitude, stay clear of
>non-proven tools or methodologies. Spinning your own tools isn't good for
>pretty powerpoint slides but usually gets the job done. And you have the
>competence (=consultants) in-house. 
>	 

Can you mention some tools you have written as alternative to some obvious
public domain tools which you have categorized as non-proven?


	 

_____________________________		
Posted through www.DSPRelated.com

>Can you mention some tools you have written as alternative to some
obvious
>public domain tools which you have categorized as non-proven?

I hate to disappoint, but I'm not doing any "categorizing" for you. Please
re-read my post. Then decide for yourself, you're the expert on your own
work.

BTW, don't want to put "proven" stamps anywhere, but gsl has always worked
for me, and I've gotten myself into hot waters by using FFTW in code that
suddenly had to be licensed to 3rd parties.

 



	 

_____________________________		
Posted through www.DSPRelated.com

Am 27.09.2013 01:01, schrieb robert bristow-johnson:
>
> okay guys, what do you do, if you start with an alg that works pretty
> good in MATLAB/Octave/MathCad/Mathematica/whatever, and you wanna make
> production code out of it.  let's pretend the production code will be C.
>   what do you do?
>
> rewrite it yourself, line by line?
>
> use http://www.mathworks.com/products/matlab-coder/ ?
>
> something else? (i guess i would also be interested in hearing from Vlad
> about what he does instead of what the silly Matlabies do.)
>
> thanks for opinions.
>

I know of companies who are generating C code from Simulink models.

The prototypes I came across where usually rewritten to the language of 
choice. If your prototype is a little bit larger and the combination of 
MATLAB and C/C++ is used, the mex-DLL-interface functionality of MATLAB 
can help you to do a rewrite step by step and still use your MATLAB 
environment for testing.

Though I would not advise MATLAB for bigger projects because it is hard 
to keep the code in a maintainable structure.

On Sunday, September 29, 2013 12:58:24 PM UTC-4, Greg Berchin wrote:
> On Sun, 29 Sep 2013 10:25:07 -0500, Vladimir Vassilevsky
> 
> <nospam@nowhere.com> wrote:
> 
> 
> 
> >On 9/28/2013 9:49 PM, robert bristow-johnson wrote:
> 
> >
> 
> >> i would still be interested in hearing from Vlad what he does going
> 
> >> sorta "MATLAB commando".  no tools other than the ones you make
> 
> >> yourself, Vlad?  
> 
> 
> 
> <...>
> 
> 
> 
> >Sorry for being brief, I am currently busy fixing client project. At the 
> 
> >beginning, they did common mistake of playing with graphic IDE instead 
> 
> >of developing code and algorithms. Now it is finally falling apart, and 
> 
> >the timeline is approaching.
> 
> >
> 
> >Graphic tools are sale tools.
> 
> 
> 
> My most recent contract stipulated that proof-of-concept was to be
> 
> written in MATLAB, but that the deliverable software was to be
> 
> written in C. I took a lot of heat for "writing a MATLAB script
> 
> that looked like a C program", but after the flashy
> 
> proof-of-concept demonstration, the translation to C was much
> 
> simplified.
> 
> 
> 
> The most difficult problem was the off-by-1 indices.
> 
> 
> 
> Greg

I was the project scientist on a large post-processor for sonar data. I used Matlab to code all the algorithms. The matlab code was used for: unit testing, included in the software design documentation, and was given to the coders since many of them didn't know much about DSP.

The matlab code mimicked the overall software design, so it wasn't how most people would implement the algorithm in matlab - but it duplicated all the glue that as used around any particular algorithm. As an example I couldn't filter data with the matlab command "firfilt" - because the coders in their libraries don't have that function.

I anticipated the off by 1 problem, so in the matlab code I wrote the loop in the typical matlab way, but created an auxiliary variable which mimics how you'd do it in C. As an example:
for ind=1:length(Vec) %This is self documented matlab
    c_ind = ind-1;  %C version of zero based index
    blah , blah blah  

end

Cheers,
Dave