>"I've been involved in projects like this too. Very few people have the
>skill set needed to develop and implement projects like this alone. The
That's the case here. The system consists of a variety of chemistries,
chemical separation methods, electromechanical subsystems with embedded
control and data acquisition software, data analysis and user console
programs. The software inherits specific requirements from each of these
subsystems. There's need for both people and tools that bridge between
the several disciplines--one of the reasons matlab came into use.
>As Matlab is interpretive and C++ compiled, I assumed that the need for
>both was performance. If I was shooting for
>performance, perhaps my last choice would be either C or
>C++. That's another issue entirely.
Actually, performance issues are mostly answered now by the fast
processors and disk drives.
>I obviously don't grasp entirely the process that Ben describes except
>that I get the feeling it meets an input that it should like, but
>doesn't. This requires some algorithmic adjustment. I further assume
>that his regression test data simply assures any new algorithmic change
>didn't undo some previous.
Right. Clean, low noise data is easy, but additions to the code to handle
the times when the chemistry didn't work well or the sample prep was
inadequate multiply the code several fold. What makes it harder too is
the need to do it all automatically--no human intervention permitted.
>He doesn't have a problem generating test data, the one that the use of
>predicate logic addresses, he just has a problem with the processing
>algorithms. I assume that these
>algorithms get expressed as formal mathematical logic
>equations. This is the lingua franca that allows this form of
>communication between the two groups. Rewriting it to a logical
>equivalent form in C++ source is a clerical process. You have to
>question why are we wasting people resources in doing this.
Tools exist to do the translation automatically, but I'm told they're not
good enough yet to be really useful. The programmers translating matlab
to C have developed their own toolboxes of C replacements for matlab
idioms and structures. There's enough similarity between matlab M code
and C that pieces of the M code are often pasted in and edited into C in
place. The translation step is usually pretty quick, but subtle errors
that take awhile to discover also happen.
But seems that my contributions here are a diversion from the issues Lynn
is raising which to my understanding is how to make developing open source
more accessible and efficient. I admit that I'm much more a tool user
than tool builder, but I'm also motivated to participate in the community
collaboration.
Ben A
--
-----------------------------------------------------------
Benedict G. Archer
-----------------------------------------------------------
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
>> Next Message >>
Return to [ 21 |
February |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
