Slashdot Mirror
Managing Parallel Development in Two Languages?
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."
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 know that any problems you have are in the code.
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.
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?
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
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.
- November/016220.html
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
The above link should be of help.
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.
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.
Monstar L
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
No, *THE* language for zealots today is Ruby. With a syntax that makes Perl seem easy and Fortran modern, a complexity that makes C++ seem simple, features of an uselessness that make Lisp seem practical, zealots are all abandoning Python for Ruby these days.
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 your HR department and send in a resume. A company that's balancing "getting it right" with "getting it out the door" is common enough for my liking.
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
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.
I think that they're looking for better performances, porting it to python won't give a great improvement from this point of view. And MATLAB has a _HUGE_ collection of librieries and toolboxes of mathematical functions, even if python comes "with batteries included", it does not feature builtin functions such as coniugate gradient method solver, for example. So it won't be nor faster nor (a lot) easier. Maybe, porting to octave would free him from vendor lock-in, if octave is mature enough.
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.
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++.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
octave 2.9 is pretty awsome. We use it (for solving a lot of Lp problems, with some branch-and-bound), and it works beautiful.
As for the question... I would question the wisdom in abandoning octave (or matlab) at all, but if you do need to do it, do it in small steps. At least, that is the best way in my experience.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
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
Drop matlab. Use http://itpp.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.
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.
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 are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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 will be points where people are multiplying a diagonal matrix, and all the zero elements are actually multiplied. A nice "matrix" expression involving huge matrices can be reduced to a much simpler set of individual element math, and so on. Even if you don't use matrices, similar problems can exist in the Laplace, Fourier and Z-Domains. Performing optimizations on the mathematical expressions can often yield 100:1 speedups, because the expressions are written for theoretical simplicity and not computational simplicity. In the end, you need to sit down with a piece of paper (or a symbolic math package), and figure out the minimum set of computations required to accomplish your goal. These computations can be coded into C++ using well-established math libraries. The result is a much more efficient program. For a fast real-time system, you need to optimize the mathematics. Additionally, the user interface portions of the program are typically much larger and more important than the mathematical portions of the program. A full-fledged programming environment like C++ is generally superior to Matlab. I have seen both commercial Matlab and C++ programs. C++ programs show a much superior "user experience", and are much easier to sell.
Besides, can't you write the same program in a shorter way using APL?
I don't think so otherwise someone would have submitted it.
If you want to obfuscate
I don't. The idea was to make it as short as possible, not as unreadable as possible. If I wanted to make it unreadable, I'd use Perl, like you suggested.
I'll probably be modded down for this...
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 than a general one - C++ isn't going to beat Matlab for ease of developing most purely mathematical algorithms any time soon - but a lot of people who invent factors of something-very-big difference have no idea what they're talking about.
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++. For example, using C++'s default indexing strategy for matrices will do horrible things to your performance on many modern systems, because of the way caching works. Even something as simple as calculating the length of a vector using Pythagoras's Theorem in a naive way can cause horrible bugs. This sort of thing is dealt with on auto-pilot when you're using tools like Matlab, but if you're writing in a low-level language like C++ then you need to be on top of it.
If you want more specific advice about how easy/difficult it is to implement a particular aspect of mathematics in C++, you'll need to supply some more details, but I'm sure there are people reading this who could help.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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 one program - especially if that one program is under your control. There's a lot of corners you can cut, like error reporting and full support for the more esoteric source language constructs. Plus you can special case constructs you'll use, but don't want to implement fully flexible support for.
You may also, if your source language is high level, want to indirect through another pre-existing high level language compiler that targets C or C++, since that would be a narrower conceptual divide to cross. Example, matlab to Haskell, and use GHC to turn it into C.
Eventually after a while, such a compiler may even become a product in itself.
--
Error 500: Internal sig error
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, a free matlab clone, and numpy, 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.
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 more copies and driving down the developer time per unit sold...
Again, as with any project, the decisions need to be made based on the requirements and the desired output.
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.
This should have read, "So it won't be either faster or (much) easier." This could be rewritten in ways providing a choice between "either/or" or "neither/nor" but "nor/nor" doesn't make sense. There is also the misuse of "a lot" to mean either many or much.
My own imperfect skills in grammar were not drilled into me by nuns with their rulers across my knuckles, but by the fact that most of the reading materials available had been either properly written, or properly edited. I absorbed these rules more through osmosis than that anyone ever taught them to me, or even tried to.
But isn't it obvious that the less children are exposed to proper grammar, the less they will be able to absorb the proper principles, and so the less they will even try to produce it? Our language just might deteriorate into nonsense if everyone doesn't take steps to preserve it.
--
I don't want to rule the world... I just want to be in charge of mayonnaise.
Depending on how you're using it, you could replace Matlab with GNU Octave.
Avoiding proprietary dependencies (especially expensive ones like Matlab) is generally a good idea.
http://outcampaign.org/
Good question. I'll answer that if you answer this: every time I get to a street intersection, should I turn right, turn left, or go straight ahead? The answer to both is: it depends. Where do you want to go? If the argument is a basic type that will not be changed, use a value, if it needs to be changed, use a reference, if it's a large structure or array, use a pointer.
A language that ignores such details will not be necessarily safer or easier to code. For instance, should strings be mutable or not? C++ lets you choose, use the "const" modifier to make a string immutable. In languages where this property is fixed you cannot just ignore it, you may have to work around it, at the cost of possible bugs or inefficiency. When I was learning Python, I spent a lot of time in a program because a string wasn't changing when I tried to modify it. After I found out that strings in Python are immutable by design, I had to redesign my program.
C++ hard to learn, but there is a consolation, you only have to learn it once. The biggest problem in learning C++ isn't the complexity of the language itself, but the learning curve. In other languages you can start small and learn as you go, but to be effective in C++ you have to learn many details before you start using it efficiently. OTOH, the syntax is rather well-behaved, you don't have the anomalies you find in Perl, for instance, where variable types depend on the first character of the name, or in Ruby where a block of code is delimited by an "end" in some circumstances and by braces in other cases.
After you have become experienced, coding in C++ is easier than in more "helpful" languages, because you always have the choice of the best method to do everything. Knowing C++ is like riding a cross-country motorcycle. You can go to places you can't reach with either a bus (easier to ride), or a Ferrari (faster in well paved roads with light traffic).
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 things disastrously.
For instance, the user interfaces in Matlab are generally not of production quality. VB and C++ really shine when it comes to user interface generation. Traditionally, most of the application development will go into designing a well laid out user interface.
Alternatively, are you doing a real-time servo control application? Have you ever tried to get Matlab to give deterministic interrupt response in the millisecond or microsecond range? Matlab wasn't intended to be used for real-time control code. It was intended to generate the parameters for control systems that could later be coded in C or C++.
Will your application scale? I encountered a situation where a series of six matrices were multiplied together. If you did the expression literally, then it generated an intermediate 50,000,000 by 50,000,000 square matrix. If you broke the expression into symbolic equations, it generated a 1,000 by 1,000 matrix. That is a huge reduction in computational complexity.
Just because some researchers can knock out a quick prototype in Matlab, does not mean that the prototype will scale nicely into a finished application. Wait until the researchers can deliver an algorithm, and then code the algorithm in C++ using the best available computational techniques.
I'm a software visionary. I don't code.
Matlab is morphing into a Java scripting language. You know why the Matlab UI takes so long to load these days? Its written in Java, so it needs to load a Java VM when it launches with all of the attendant byte code checking of loaded classes.
Did you know that you can launch Java apps from the Matlab command prompt? That you can also create object instances of individual Java classes and invoke function calls on them? That Matlab automatically manages conversions of array types between the Matlab environment and Java objects? That as of Matlab 7 that Matlab can host Java Swing widgets inside Figure Window GUI's in Matlab?
Forget about C++ GUI's, Python, Ruby, all the stuff people are telling you. Develop your application-specific widgets in Java Swing. Host them in your Matlab GUI for now. When you are ready, release stand-alone Java Swing apps using those same Java widgets. Continue to support Matlab as a scripting environment for your stuff.
Need to do some hard-core numerics in C++? The Java implementations may be fast enough. But if you really need C++, link into it from your Java widgets using JNI. You will need to compile your C++ modules for your different target platforms, but the compiled modules will have different names (YourModule.dll under Windows, libYourModule.so under Linux) so you can distribute all of the modules along with the Java class file that calls them and have cross-platform capability. The JNI takes some mastering, but it is no harder than what you do to write MEX files to call C/C++ directly from Matlab, and there are tons of documentation on the Web.
The people telling you to do a C++ GUI don't know what they are talking about -- you are probably doing a Matlab GUI and may be calling down to C++ in MEX functions. There are C++ solutions -- Qt, wxWidgets, (gasp, choke) MFC/ATL/WTL -- but they will look quited unfamiliar to what you are doing right now. Do your GUI as Swing widgets and you will get Matlab interoperability, a path to ween yourself from Matlab, and a way to operate on all the platforms that have Matlab.
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.
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++ for some reason you should probably simply convert to C++. This is assuming you don't have a requirement that would make it advantageous to keep mathlab around. Such a requirement might be: business team would like to code in a high level language to facilitate simple reqeuests. I've used this in the past to minimize maintenance costs.
No message. No message.
BSD, go for it
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I don't get he lock in myth... /. people seem to worry about that a lot. Fact is that any choice made OSS/Proprietary/DIY/other presents some kind of lock in.
Here at
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.
Made me laugh! (and zealots don't laugh at themselves...and don't try and tell me that yours is a meta troll - my brain is starting to hurt!)
I'm a software visionary. I don't code.
It's funny, because I think pointers are essential to programming. That's because in my software projects I usually start with a sketch of the data structures. I draw in a piece of paper all the structures (or "tables" as the database people like to call them). Then I draw the relationships among those structures, by drawing lines with arrowheads from one structure to another. That way it's immediately obvious how changing field "x" in object "y" will affect object "c". SQL people would call those "foreign keys", OO people call them "messages", but to me they are pointers.
Of course, what I have just described is immediately obvious to anyone who knows about object oriented programming. However, the efficiency is orders of magnitude lower in OO. Sending a message from an object to another involves some function being executed in the CPU, having the same relationship appear as a pointer from one structure to another involves exactly *zero* effort from the CPU. No matter how fast the CPUs may become in the future, there is no way they will be able to beat that infinite division by zero.
Programmers often learn this the hard way when they start doing GUI work. They use the SetPixel message, or whatever the GUI programming environment offers, only to learn that it's painfully slow for large images. In C++ GUI libraries, such as MFC or Qt, you have the alternative to use an array containing those pixels and use a pointer to the array as an argument to the drawing function. Of course, there's a trade-off between ease of use and efficiency. By using the SetPixel message you let the drawing object worry about details such as bits per pixel. In C++ at least you have a choice, use the highest level functions whenever possible, but go down into the little details when needed.
This is something that all the OO people should learn: there are no objects in a computer other than memory, register, arithmetic and logic units, etc. Any type of logical relationship must be translated into reading bytes from memory, performing operations on them, and writing the result to the memory. In some cases it may be faster to develop a software if you can express those operations in a more abstract way, but if your solution involves waiting for years until a fast enough CPU becomes available, then it's much quicker to develop your program in a lower level. C++ lets you choose the level of programming that you need to do.
Let's start with facts, shall we?
t /Download/33872_91012v25_NA_INDV.pdf
Here's the price sheet: https://tagteamdbserver.mathworks.com/ttserverroo
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 price.
As for US programmers costing $15/hour, GET REAL. Last time I looked, minimum rate for an entry-level new college grad was $50K, or $25/hr. Furthermore, you have to add overhead to that hourly rate: the guy typically will cost the company his raw salary AGAIN, in benefits, physical plant, support resources (desk, power, light, PC, network, copy paper...).
Figure a quarter of a million dollars a year per programmer or engineer, total burdened cost, and you aren't that far off.
There is an easy cross-check for this. Look at a healthy technology company, one whose principal product is software development, so that cost of good sold (raw materials, subcontract, etc., is negligible. Divide total sales by number of employees, and that gives you an upper bound on what the employees are costing the company. Look at an UNHEALTHY company, do the same calculation, observe that the unhealthy company is NOT succeeding in making enough money to cover the cost of the employees, and you have a lower bound. When I did this exercise in Dallas a few years ago, I found that the magic number was somewhere between $200,000/yr and $300,000/yr. That's $100/hr-$150/hr. At that rate, $1900 for a copy of Matlab, amortized over 2000 hours, is $1/hr: less than 1% of the total.
And, if you want to get picky, figuring maintenance at 20% of purchase price per year, you're looking at $4000/5 years, or $800/year, or about forty cents an hour, or about three dollars a day. Bathroom breaks cost more.
If you want to do cost arguments, always start with real numbers, not made-up ones.
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 freezing options.
I'm using wxPython for the GUI which I can also program in both Python and C++.
I have to admit, the Matlab people will have a hard time letting go of their favorite
tool. One job I had in the past ended up simply installing a full Matlab installation
on every machine we wanted or main C++ software to work on. This was just to take
some regularly spaced data and put it on a regular grid. (Today I'd use natgrid or
a smoothed delaunay from Python and have a free, fast implementation in no time.)
-Jim
Celebrate Excellence!
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./ Other prototyping languages will be available in the future, like Python.
Dude, that's a circular argument if I ever saw one. Let me condense it.
It's not circular. One cost is sunk and the other is variable. If they sell more copies they can more easily amortize the sunk cost and actually, you know, make real long term profit.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Like someone else said, I was working under the assumption that each customer would need to have their own copy of matlab to run the product. So in a sense, you need to bundle it - or at least from the customer point of view, the cost of the product inlcludes the matlab.
In my (possibly incorrect) view, the choice seemed to be to develop using matlab and spend less time developing, or to develop in C++ and spend more time developing. I was saying that it may be cheaper on a per-unit basis to pay the developers to do the c++ work since you won't have to bundle the cost of matlab with your product. That, of course, depends on whether it is indeed necessary to bundle matlab, and how much it's going to take to develop in c++.
As for in-house, I was then approaching it from the point of view that possibly they weren't selling the system, but building it for in-house use. At that point, it becomes an issue of not having multiple units to spread your fixed costs across.
So, it's not nearly so absolute. It depends on how many units you really think you can sell and how much money you would spend developing the c++ compared to the matlab license and whether you have to bundle it with a product you intend to sell.
If you do have to bundle matlab, then the advantage of the c++ route is that the marginal cost of the nth unit is nearly 0. If you do have to bundle matlab, then it is nearly $10,000...
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 - Peter
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 should conform to.
--
Thorbjørn Ravn Andersen "...and...Tubular Bells!"
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 Physical architecture will be influenced by that nasty thing called reality: performance, time/functionality tradeoffs, clients' hardware, legal requirements, that sort of thing.
you can use C++ if you want but i would advise against it unless you have strong historical/legacy lockins. for Maths work, Python's "NumPy" library actually runs faster than the standard C++ libraries (plus it can near-transparently use C/C++ libraries), and you avoid 99% of the time-wasting faff that C++ forces on the coders. so you develop several orders of magnitude faster. a lovely lovely language which slots straight into your mathematical environment.
e.g.: http://www.linuxjournal.com/article.php?sid=3882
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, 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 it in Frink, as opposed to, say, Java or C++. Later, I may port the algorithm to Java for some speed gain.
Frink and Matlab tend to try to preserve normal mathematical notation, which will make your mathematics people happy, and which be easier to read. When I need to refresh my memory about how an algorithm works, it's easier to go back and read the Frink code, not the Java code.
My advice is to try and maintain the algorithms both in Matlab format and C++ format, so that each accurately reflects what the other is doing. Yes, it's more work, but the code in one language will generally be a lot simpler than the other, so it shouldn't take much time. This will make it easier to prototype and test. The Matlab code will generally be more transparent for mathematical algorithms, and you'll be able to see, test, and fix bugs in the Matlab implementation more easily, whether you originally found the bug in the C++ version or the Matlab version. And you can share test suites and validate them against each other.
I don't agree with the people who think that the mathematicians can do all the high-level work in Matlab, and then just hand the work off to lower-level programmers to transliterate into C++. It's very common that an innocuous function in Matlab has huge amounts of very complex code behind it which you'll have to reproduce in C++. This often takes deep mathematical knowledge. For example, you might be using a Matlab function to factor numbers, but do you really know how to factor big numbers fast? Lots of work and user testing has been put into making sure the Matlab functions return the right results. Can you say the same about your C++ code?
There's lots of low-level understanding necessary for this transliteration, and of course the common annoyances where all of your expressions like 1/2 magically become zero when you port to C++!
Make your computer ten thousand times larger--try Frink