Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Managing Parallel Development in Two Languages? 108

Posted by Cliff from the does-double-the-work-mean-double-the-gain dept.
Abhaga asks: "I work for a technology startup and our research work is mostly done in Matlab. The technology has matured, and now we are looking to build prototypes and products in C++. However, the dilemma is about the further research work/enhancements to the system. Should they be done in Matlab and continuously ported to C++, or is it better to move to C++ once and for all, at this point of time? Anyone having experience with similar things, what should we keep in mind while deciding on one or other."
This discussion has been archived. No new comments can be posted.

Managing Parallel Development in Two Languages? More

Managing Parallel Development in Two Languages?

Comments Filter:

  • Do one thing at a time. (Score:2, Insightful)

    by Anonymous Coward
    Every development project should have a proof of concept phase. You need to know that the underlying idea will work. Get something working however you can. Once you have done that you always have a fallback position that you know works. That's the stage where you use Matlab.

    Trying to write C++ code and develop the math at the same time means that you have four times the trouble debugging. If you have a problem you won't be sure whether it's in the math or the code. If you get the math right first, you
    • Trying to write C++ code and develop the math at the same time means that you have four times the trouble debugging.

      Actually, if functional units are done in sequence, then the debugging in the second language will be trivial. After writing, testing, and debugging the Foo function in Matlab, the C++ work will be little more than transcription.

      If you can interface Matlab to C++, you can even use the same tests for both codebases.

  • Start High, Then Low (Score:4, Insightful)

    by Webz ( 210489 ) on Saturday July 22, 2006 @07:49AM (#15762536)
    With neither experience in parallel development or MATLAB, here's something I've read before (regarding Ruby and C++)...

    Start in whatever language happens to be easiest/most high level. Easiest in that whatever helps you express your final product the fastest. Then, when this prototype is up and running, go ahead and reprogram it in C++ for speed.

    Think of using the first language as a roadmap, where you can concentrate on organizing your thoughts and getting user requirements out of the way. Done purely in C++, you may be subject to premature optimization or just wasting time re-inventing constructs and concepts that are trivial in the other language.
    • Hardware processing power will always get faster. This is more important than elegant code when building commercial applications. It is also one of the more important things I learnt while studying at university. Thankfully GNU code is not designed this way, and hence, it is faster than commercial software.
      • If hardware is always getting faster then development time is the best metric.
        Elegant code reduces development time.

        Are you calling GNU code elegant ?
        No-one I know that has to cope with GNU code would call it elegant.

  • Well, starting out developing using a proprietry environment such as Matlab is not the smartest move if it's so easy to implement your code in C++. What happens if TheMathWorks double their licensing fee? Triple it? Go bust?

    Using a properly-defined (ie. by an ISO/IEC standard) language is a much smarter thing to do. Choosing one with several available compilers, supported on different OS / CPU platorms helps too.

    Try to make your project as independant as possible, and it will stand a much better chanc

    • If you're doing it first in Matlab and then using that as a spec to reverse engineer in C++ it doesn't sound very parallel to me. I guess whether or not it's worth doing the prototyping stage depends on how much it costs, compared to what scre-ups it helps you avoid. Maybe a few more details in the question would help?

    • Re:Proprietry lock-in (Score:4, Interesting)

      by antifoidulus ( 807088 ) on Saturday July 22, 2006 @08:25AM (#15762580) Homepage Journal
      Wow, talk about being penny wise and pound foolish. I know this isn't popular here on /., but if you are worried about the cost of matlab, then honestly your organization doesn't have a snowball's chance in hell.
      If you can save time by using Matlab, even in your very unlikely scenario, the extra cost of the software is still dwarfed by the cost of programmers time as well as the potential losses of being 2nd to market. Unless the software is prohibitively expensive(which Matlab isn't), you need to go with what can get the job done the fastest with the fewest errors.

    • Re:Proprietry lock-in (Score:5, Interesting)

      by jellomizer ( 103300 ) * on Saturday July 22, 2006 @09:01AM (#15762647)
      Remember US Programmers are payed between 15-150 an hour say MatLab licenses cost $10,000 and Major Upgrades every 2 year.
      So that is $5,000 a Year of software cost. Now the programmer will work a 35 hour work week. Now the Cheap Programmer year cost is $26,250 a year and the expensive programmer $262,500 a year. So programmers are more expensive then licenses. So if this tool can make a programmer twice as productive then it is worth the license. So unless the programmer is getting like $3.00 an hour which is less then most outsourcing. The costs to do it in C++ vs. Paying for a license is worth it.


      • That's only true if they're developing for their own in-house work. But if they're trying to sell this product to other people, going the Matlab route just took $10,000 off their margin. If they want to make a profit, they need to sell their product for $10,000 + [developer time per unit] + [desired profit].

        If they go the c++ route, they only have to sell it for [developer time per unit] + [desired profit]. The developer time might be more, but with the lower price, they have a better chance of selling m
      • Matlab also allows the expensive guys with math PhDs to work quickly in a pleasant, familiar, supportive environment. Those guys are smart enough to learn C++ and deal with memory management and templates (often helpful for supremely efficient math code), but it's not a good use of their time if it can be avoided. If you need C++, let the cheap programmers transcribe the Matlab work into C++ and do the tedious job of debugging in C++, while the math guys stay happy and productive in Matlab.
      • Let's start with facts, shall we?

        Here's the price sheet: https://tagteamdbserver.mathworks.com/ttserverroot /Download/33872_91012v25_NA_INDV.pdf [mathworks.com]

        RIGHT NOW, the single-copy United States price for Matlab for commercial use is $1900. The various add-on toolboxes cost anywhere from a few hundred dollars to several thousand dollars.

        Those are ONE-TIME purchase prices, not annual license fees. Annual maintenance contracts, which get you upgrades as they become available, are typically around 1/5 of the purchase
    • There is also a properly defined language for communication, English. And in English we spell it "independent".

      Your proprietry English that contains "independant" will probably go out of business and you will wither and perish.
      • There is also a properly defined language for communication, English. And in English we spell it "independent".

        Your proprietry English that contains "independant" will probably go out of business and you will wither and perish.
        Well spotted! I would like to re-use parts of your post, modify it, and even sell it. I trust it is GPL'd?

    • Depending on how you're using it, you could replace Matlab with GNU Octave [octave.org].

      Avoiding proprietary dependencies (especially expensive ones like Matlab) is generally a good idea.

    • I don't get he lock in myth...
      Here at /. people seem to worry about that a lot. Fact is that any choice made OSS/Proprietary/DIY/other presents some kind of lock in.
      Moving from one product to another is alwais costly, the cost of the licences is normally not relevant. Actually in most cases (exceptions exist, so annedotal evidence of e opposite can be presented) these costs are actually not significant.

      Don't worry about the lock in, do worry about what a product can do for you.
  • Well., I dont know about matlab. If you were using python, you could have built a prototype first using python., then start optimizing it by converting the bottlneck modules to C++/C.

    See whether Matlab provides something like that. If it does not., you'll be wasting a lot of time converting it all to C++ and then continuing research on a C++ base., which means half your R&D team would have to be re-educated.

    http://mail.python.org/pipermail/python-list/1999- November/016220.html [python.org]

    The above link should be o

    • Well., I dont know about matlab. If you were using python, you could have built a prototype first using python., then start optimizing it by converting the bottlneck modules to C++/C.

      Yes you can do this, I believe you can even call MATLAB routines from within this code. The question is, is worth it. Unless you really have multiple ways of using the same code in different ways (say an ode solver) then you just end up with one big function written in C++ and the trival code to call this function in MATLAB.

  • Software wants to be free (Score:3, Funny)

    by Anonymous Coward on Saturday July 22, 2006 @08:15AM (#15762568)
    Get rid of all your Matlab code and rewrite in pure GNU Octave. The parallel development can be done in C with some assembler thrown in. Oh and be sure to license everything under GPL version 3. Then sit back and watch the money roll in off support, donations, and t-shirt sales.

  • Choose one language for development. (Score:5, Interesting)

    by jellomizer ( 103300 ) * on Saturday July 22, 2006 @08:28AM (#15762588)
    Mixing two languages together will cause problems, Technical/Buisness/Political.

    Political: Undoubtedly you will get some changes and fixes that are really easy in one language and a real pain for an other one. So say it takes 5 Minutes in MatLab and could take a week in C++or Vice Versa. Most people don't get this fact especially non professional programmers. So one side group will get a fast change and the other will get the slow change. Thus makes the other group feel like their side isn't as well supported thus making you look really bad.

    Business: Maintaining the application will always require people with skill sets in both. Matlab is a rather uncommon skill set while as of right now C++is fairly common. But finding people willing to do both is much harder. As time goes on and as one language leaves common use finding people with these skill sets combined will be very hard and expensive to keep.

    Technical: Reported bugs will be need to check on both systems and bug will appear in one system and not the other. But when a bug is reported you will need to check on both systems. And sometime you can easily fix on system and the other requires a major rework. Getting performance on one system to be equivalent to the other will be difficult.

    I think you are about to enter a quagmire which you will not come out looking good in. If you do succeed you will probably get a neutral reaction to you work. So it is a Loose/Tie situation. I would spend more time descussing other options. Going one way or the other. Not 2 products that do the same thing but differently.
    • You have missed the point. They are using C++ to speed up stuff that is initially written in matlab. There are not two separate systems deployed, but a prototype and a product.
    • "I would spend more time descussing other options. Going one way or the other. Not 2 products that do the same thing but differently."
      It seems that unless Matlab has some sort of relatively cheap VM for their code (don't think they do) then this company should just switch to C++ right way if they want to release a product and make money off of it. But I don't think that's the right answer. You mentioned how there will be different bugs and how one group will get a fast change and the other will get a slow c
  • Just like writing an essay, it's always better to work with a first draft and a final draft.

    Utilizing two languages in the development process guarantees that however complete the Matlab version is, you still require a port over to C++. This becomes a natural opportunity to refactor and re-analyze the original work as you proceed to your final draft.

    What's astonishing to me is that your management seems to tolerate you writing the application twice. If that's really so, please tell me where to contact you

  • Why do this at all? (Score:5, Insightful)

    by kognate ( 322256 ) on Saturday July 22, 2006 @08:35AM (#15762594)
    First, ask yourself why you want to port existing code to a new language? Presumably, the people who are writing
    the Matlab code have a facility with Matlab and are subject matter experts that are doing the heavy lifting (algorithmically speaking). Are the C++ coders the same people? If they're not, can you afford to spend the time/staff to do the porting? Should the
    original code even be in Matlab in the first place?

    You can call matlab libraries from C++ code, which would seem to be the best of both worlds. Then you wouldn't have to port anything.

    Lastly, this is not the kind of question that will get answered well on Slashdot. People who have never used matlab will make assumptions and not understand that it is very unlikely that C++ will have the kind of simulation and and capabilities that Matlab does. Besides, a lot of the time Matlab people (scientists, engineers, quants, etc) may be comfortable working Matlab but not C++, so you do what you can to make it possible for them to work. Also, the suggestion that Mathworks will raise pricing and hold your work hostage is laughable: They already do that, their pricing is crazy.

    • Re:Why do this at all? (Score:1, Insightful)

      by Anonymous Coward
      I'd say it strongly depends on what it is and who the people are that will have to do the porting. (btw. I'm working with matlab as well as c++ in a research environment that is largely matlab-dominated.)

      You have to realize that the speed at which the developement team works will break in significantly once they start to migrate to c++ (and it will stay below the former speed !!). Matlab is a very powerful tool when it comes to numerical tasks or data evaluation. It is also very forgiving regarding "quick a
    • You can call matlab libraries from C++ code, which would seem to be the best of both worlds. Then you wouldn't have to port anything.

      Unless you want to distribute your application to people who don't have MATLAB. Or is the MATLAB runtime engine [mathworks.com] free to distribute?

    • Lastly, this is not the kind of question that will get answered well on Slashdot. People who have never used matlab will make assumptions and not understand that it is very unlikely that C++ will have the kind of simulation and and capabilities that Matlab does.

      Absolutely correct. Coincidentally, yesterday at the bookstore I saw a book on network programming in Matlab, which was a big surprise (to my non-Matlab-using mind).

    • This has to be done because not everyone is a scientist with an experimental, discovery mindset. Everyone is also not a C++ programmer (or Java, Perl, C, C#, etc.) and thus proficient at error checking and dealing with a variety of system interaction. Face it, people hire scientists to develop things no one else is doing, but who learned programming as a necessary evil. People hire professional developers to glue or reform that prototype effort into something a customer wants. I found that my college tr

  • Compile the Matlab (Score:4, Informative)

    by jabuzz ( 182671 ) on Saturday July 22, 2006 @08:45AM (#15762613) Homepage
    Have you looked into using the Matlab compiler to convert your Matlab code into C/C++. Just keep developing in Matlab and solve your problems.
    • It seems like a lot of the other people giving "advice" in this thread has no experience with Matlab.

      Many of the built in functions in Matlab are coded in eg C. And as you mention Matlab even has built in functionality for porting code to C from the Matlab scripting language.

      I'd advice the OP to go that route. Profile your code and begin by moving over the parts that are eating the majority of your cycles. Design it similar to the .m files you already have and you can use them for testing your new code.

      Once

  • Do it in C++ from the start (Score:3, Interesting)

    by mangu ( 126918 ) on Saturday July 22, 2006 @08:50AM (#15762629)
    I have done what you said, writing prototypes in Matlab first and porting it later to C++, and it hasn't worked too well. I have found that the two languages are too different, there are always new bugs appearing in the ported code. In my experience, the time spent in developing the math is less than the time spent in the user interface anyway, so I don't see too much problem in developing the math in C++, if you choose a good set of libraries.


    However, having said that, I must say that I *do* write small prototypes first, only I do it in C rather than other languages. I also use plenty of small scripts, mostly in Perl, to perform auxiliary operations. But the main code that constitutes the algorithms used in the program should be prototyped as close to the end code as possible. There is no way you could develop an algorithm in Matlab or Python or Ruby and consider its testing a validation for a deliverable program written in C++.

    • In my experience, the time spent in developing the math is less than the time spent in the user interface anyway, so I don't see too much problem in developing the math in C++, if you choose a good set of libraries.

      No offensive, but if the maths your doing is easier than writing a ui then you are either doing very simple maths or very complicated user interfaces!

      Seriously, if you're implementing an algorithm to solve a 2nd order differential equation using the finite element method or using the shooting

      • Re:Do it in C++ from the start (Score:5, Insightful)

        by mangu ( 126918 ) on Saturday July 22, 2006 @10:52AM (#15762905)
        if you're implementing an algorithm to solve a 2nd order differential equation using the finite element method or using the shooting method it is hard


        Hard? Only if you cannot or don't want to use existing libraries for C++ [diffpack.com]. Now try to find a pre-packaged solution for "they want a button for downloading the data in the same dialog that lets them open an Excel spreadsheet" or any of the infinite other changes one always gets to do in any non-trivial GUI.


      •   No offensive, but if the maths your doing is easier than writing a ui then you are either doing very simple maths or very complicated user interfaces!

        There are lots of people here who do math/science for a living who disagree with this. Nobody codes algorithms they don't understand, and coding algorithms you undertsand well is trivial in most general purpose languages that include math libraries. Really.
  • It depends on what you're developing.

    Develop the algorithms in matlab. Develop the UI in C++. Use matlab to create loadable modules that can be called from your C++ program.

    Matlab is not ideal for developing the UI. C++ is not ideal for developing math algorithms.

    Beyond that, do what makes sense for your program and developers.

    -Adam
    • I would develop or port the algorithms in C++. Numeric algorithms are the most portable, straightforward, readable form of C++ code. It is the GUI part that gets gnarly in C++.

      I would do the UI in Matlab or at least keep the UI in Matlab because that is what the dude probably has. The thing to migrate the UI part in is Java Swing -- you can incorporate custom Java Swing widgets into a Matlab GUI.

      • Latent Heat, a while ago you stated "Suppose a transformer wall wart uses 4 watts and you can replace it with a solid-state ferrite switcher that uses .5 watts." I didn't know any other way to contact you than this off-topic reply. My apologies. I googled for various permutations of "solid-state ferrite switcher" without success - but I'm very interested. Please give me a bit more detail. You can respond in this brand spanking new slashdot id or directly to pbuck at his dot com. Thanks in advance - Pe
  • Drop matlab. Use http://itpp.sf.net/ [sf.net] and stay out of gsl, it's way too complicated to do simple things like matrix operations. For plotting there are great tools for python.

  • Been there, Done That... (Score:4, Insightful)

    by occamboy ( 583175 ) on Saturday July 22, 2006 @09:36AM (#15762715)
    I assume that the algorithms and math are in Matlab. Matlab is much better than C++ for developing and unit testing math "stuff". However, shipping Matlab libraries with your application means a more complicated setup, licensing issues - and it will look pretty "bush league" (try it you'll see what I mean). Also, I'm guessing that your "domain experts" are more comfortable with Matlab than with C++ - which is why you're asking this question.

    I would continue to develop algorithms in Matlab, and use the Matlab compiler to move the algorithms to C++ for integration with the C++ "presentation layer" code. Then compile and ship an all-C++ product.

  • I have seen this problem before. If performance is a priority, you need to drop Matlab. The problem is, that Matlab allows all sorts of high-level mathematical abstractions, like Matrix Math. These abstractions make the theoretical math simpler, but the computational complexity (run-time) of the resulting program much higher. If you start following what the Matlab program is actually doing, you discover that many practical mathematical constructs have all sorts of crucial mathematical identities. There

  • I don't see how to give a meaningful answer to the general questions asked here without some more context.

    For what it's worth, I write high-performance, somewhat high-level maths libraries in C++ for a living. You can do a lot of things more easily in C++ than some people would expect, particularly if you have access to the right libraries (someone already mentioned diffpack, and there are also ports of BLAS and LAPACK for linear algebra, and many others). Of course a dedicated tool will usually be better

    • "calculating the length of a vector using Pythagoras's Theorem in a naive way can cause horrible bugs."

      sqrt(x * x + y * y)

      Not sure how many ways there are to do that unless you roll your own sqrt() function.
      Care to expand on it?

      • That's exactly not the way to do it: consider what happens if one of x and y is much greater than the other, as for example if you have a vector very slightly misaligned with the x- or y-axis.

        To avoid this problem, you can rearrange as x*sqrt(1+(y/x)*(y/x)), or the same but pulling y out, depending on which is bigger. (In practice you'd calculate y/x only once, of course.)

        • If its not on the axis then its just "sqrt((x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1))"
          obviously calculating the subtractions first. And for 3D you just add in "+ (z2 - z1) * (z2 - z1)".
          Not sure why you need to re-arrange the equation especially since the normal version
          contains 2 subtractions and 2 multiplications whereas yours contains 1 division, 2 mults
          and 1 addition. Can't see how that would be faster.

          • Speed isn't the point; accuracy is. I'm afraid I don't have time right now to explain the details, but please refer to a good textbook such as Numerical Recipes and you'll find all the background there.

            • Pythagorus's theorum is accurate. Wtf are you talking about?

              • Pythagoras is accurate. A naive numerical implementation is not.

                You know, this whole discussion is exactly what I was talking about when in my original post I wrote:

                However, be aware that programming serious maths using C++ is a skill in itself. A guy with general C++ experience and general maths experience is not nearly the same thing as a guy who has experience writing mathematical code in C++. [...] Even something as simple as calculating the length of a vector using Pythagoras's Theorem in a naive

                • Since when is division in IEEE 754 any more accurate than multiplication? Your example in C++ would be no more accurate than the standard method. Sorry.

                  • The point isn't whether division is more accurate than multiplication under normal circumstances, it's the vulnerability to destructive overflow/underflow. If that happens, doing things the naive way will be very much less accurate than a proper implementation based on the alternative approach I gave.

                    Really, this is elementary stuff. The fact that you keep missing the point doesn't mean there isn't a point, it just means you're not sufficiently familiar with the field to understand the danger. Please go a

                    • There is a point. You just happen to be wrong in this instance with regards to C++. Your example is just a liable to suffer from overflow and underflow as the standard since it also uses multiplication and division PLUS you have the added issue of divide by zero to take account of.

                      FYI I do 3D graphics programming so I do have a clue about this but I guess we'll just have to agree to disagree.

                    • FYI I do 3D graphics programming so I do have a clue about this

                      I could have guessed that: your focus throughout this discussion has been on speed rather than accuracy. That's fair enough in your line of work, but not really relevant to this debate, where "serious" maths appears to be the order of the day.

                      We'll obviously have to agree to disagree on this one, so I leave you with one final thought: if you're not missing anything and I'm the one who doesn't understand, then why does Numerical Recipies in

  • Don't drop MATLAB (Score:4, Interesting)

    by vijayiyer ( 728590 ) on Saturday July 22, 2006 @12:59PM (#15763304)
    Your algorithm developers will curse you if you stop the use of MATLAB. I use it every day in a mostly Fortran/C shop, and I can get work done in a small fraction of the time it takes the fortran folks. In one case it took me 35 lines of code to do what would take hundreds of lines in fortran. If I need fast runtime, I port it after I've done the development. Writing it twice in this manner is still _far_ quicker than writing it in C or C++ the first time. Ignore the slashdotters who think MATLAB is bad because it's proprietary - I can assure you that they've never used it in a production environment, and don't understand that time == money.
    • Writing it twice in this manner is still _far_ quicker than writing it in C or C++ the first time. Ignore the slashdotters who think MATLAB is bad because it's proprietary - I can assure you that they've never used it in a production environment, and don't understand that time == money.

      I have to agree with this statement. Of course, it all depends on the kind of math you are doing. In general, MATLAB is better for prototyping new math-intensive algorithms (e.g. matrix math) and it might make sense to have

      • I would agree with the statement that the prototype algorithms could be completed in Matlab. If you do that, then complete the algorithm development in Matlab. You really don't want to switch languages mid-way through algorithm development.

        The practical problem that I have seen more than once, in a research situation, is that the researchers try to complete the application in Matlab. The result is usually a disaster for a full-fledged high-performance application. Matlab does math well, but other th

  • Your best option if you have a "model" fully expressed in one language, but want a "deliverable" in another, would be to use some sort of translation process. Effectively, a compiler, although it may be a "manual" compilation process, where you go through and line-for-line write code that does in one language what's expressed in the other. Best of all, would be some automatic compiler - it's not so hard to write one, if you're targeting C++ rather than raw assembler, and if you know it only has to compile o

  • Similar Situation (Score:5, Insightful)

    by robbyjo ( 315601 ) on Saturday July 22, 2006 @01:25PM (#15763399) Homepage
    I've been in similar situation, except that we chose Java as opposed to C++ for the "lower" level language. For the higher level langauge, we have both Matlab and R. We're also dealing with research situation. Here's my experience...
    • Prototypes are best done in higher level language, in this case, Matlab. Hands down. You want to test a new research methodologies fast. You don't want to get bogged down by unneccessary programming constructs. Moreover, it's the scientist's job who do the prototyping (since he invents the algorithm, right?). Scientists are more familiar with Matlab than C++ or Java.
    • Be aware that prototypes are ALWAYS poorly structured. More often than not, they're more like spaghetti code and/or copy and paste. Prototypes are just prototypes. They're just proof of concepts that a particular method works.
    • Consequently, you may want a cadre of C++/Java developers to do the structuring. It's more like 4 low level developers per 1 scientist who does the prototyping. Often times the scientists don't know low level languages well. So, it's the C++/Java developers' job to figure out the scientist's program. Of course, the scientist would have to explain how the algorithm / source code works. On the contrary, reading MatLab / R is NOT as hard as what people says here (they must be smoking cracks. Don't listen to them). The only trouble is to familiarize yourself with Matlab / R API, which can be cryptic for some.
    • With respect to libraries, Matlab / R have a throng of ready made scientific libraries. Of course, for C++ you can use GSL [gnu.org], LAPACK [netlib.org], ATLAS [netlib.org], etc. But the problem is that sometimes the library call does NOT correspond one-to-one. So, you'll need to tinker around to find out how each library call behaves. Moreover, for some operations, like Matrix / Vector operations, are very simple in Matlab / R, since matrices / vectors can be treated as if they were scalars. Be careful in porting those.
    • In addition, you'll need to profile the library call. Make sure you actually GAIN speed with such library calls (or else you'll need to use something else). In addition, speed is NOT the only concern. Accuracy is VERY important. You don't want to use a speedy library with expense of accuracy. In scientific programs, this tradeoff is OFTEN NOT desirable. Make SURE the libraries have the same accuracy level. This is often the grounds to dismiss some unknown library who only claims that they're fast. Losing one degree of accuracy is often a BIG issue in scientific library. For example: If a library is at least 10^-16 accurate may not be acceptable as opposed to a library with an accuracy of at least 10^-17. Think of simulations, which may have millions upon millions of iterations. One degree difference in accuracy often makes a HUGE difference in the final result. Therefore, it is OFTEN more desirable to obtain an open source library where you can inspect the algorithm and point out places where a library call may lose accuracy.
    • Familiarize yourselves with many scientific algorithms that improves accuracy. In Matlab or R, they autodetect pathological situations where accuracy can lose. You'll need to do that manually in C++. For example: If you have a nearly singular matrix, you'll need SVD for better accuracy. In general, you can use QR decomposition. If the accuracy is not really an issue, LU decomposition might be enough. In Matlab / R, it can detect the matrix automatically when you try to invert the matrix and use the appropriate algorithm. Pay attention to that. Make sure your C++ program also behaves similarly.
    • You MUST make A LOT of regression tests. If it is possible, make the prototype run with the same file format as in the final product. If it isn't possible, convert the file format first and then confirm with the scientist that both of them are exactly the same. Make sure that for all tests, both returns the same numbers

    • Re:Similar Situation (Score:3, Insightful)

      by mangu ( 126918 )
      If you have a nearly singular matrix, you'll need SVD for better accuracy. In general, you can use QR decomposition. If the accuracy is not really an issue, LU decomposition might be enough. In Matlab / R, it can detect the matrix automatically when you try to invert the matrix and use the appropriate algorithm.

      Then Matlab must have improved a lot since I last used it (Version 4). A problem I had was that matrices were well behaved with small test cases, but became ill conditioned when we used actual worki

  • Have a look at Matlab's compiler -- it used to generate decent C++ code when I looked at it a few years back. And there are alternatives to matlab, including freemat [sourceforge.net], a free matlab clone, and numpy [sourceforge.net], a numerical python extension. Neither will be plug-and-play but they are both close enough to potentially be worth the switch in the future.
  • This is a very common problem in every company: it's called legacy code. Your decision is a trade-off between the plusses and minusses of both languages and the costs associated with supporting both. If you have 10,000's of lines of code in Mathlab you should consider a C++ solution that would integrate with Mathlab to prevent the need to convert it. This would also be supported if most of your development is much faster in mathlab. If your legacy code is trivial, comparatively, and you have to go to C+

  • There are alternatives to Matlab that are similar, and can be resold in commercial
    apps without any license or royalty issues.

    I would personally use Python / NumPy & SciPy / Matplotlib in a heartbeat. There are even
    tutorials for people who are used to Matlab on the subtle syntax differences.

    You can even use SWIG (or Boost_python) to integrate your high level code with your
    low level code in the same application. You can then distribute the result on
    Windows, Mac or Linux with different bundling or freezi
  • If you are prototyping in Matlab and want to take the matlab code to production, in parallel, without the re-write, Star-P from Interactive Supercomputing can help - check it out at http://www.interactivesupercomputing.com./ [www.intera...puting.com] Other prototyping languages will be available in the future, like Python.
  • In order to make a prototype, you should use the language that makes it possible to test out code the fastest. Here it is mathlab. GUI's are often prototyped in excel or Photoshop, for this purpose, instead of C++.

    It also allows you to ensure that the prototype is rewritten when being implemented. It is not often that prototype design choices are the best for production, so needing to port guarantees that all code is revised, and you have a working implementation to give test results that the product sho
  • i have experience in similar math-driven environments so can offer relevant thoughts.

    a math-centric or faff-minimising prototyping environment is crucial whilst constructing the math models which you'll later be putting into Production. you want to absolutely minimise the Drag of the tool on the thought process. you can use MatLab or Excel or a piece of paper.

    then take the result as being the Specification (Logical) which will feed into your development. your Production-ready code's particular Phys

  • This sounds like a reasonable prototyping/porting approach, really. I do much the same thing. For several years, I've been working on a programming language/calculating tool called Frink [futureboy.us], and when I'm trying to write new code that may eventually be part of Frink, say, efficiently calculating the Riemann Zeta function, or factoring large numbers, I'll usually first write the prototype function in the Frink language itself, and get it working. It's much less effort, and usually far more legible, to write

Slashdot Top Deals

If you have a procedure with 10 parameters, you probably missed some.

Close