Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Managing Parallel Development in Two Languages?

Cliff posted more than 8 years ago | 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."

cancel ×


Sorry! There are no comments related to the filter you selected.

Works well (0, Flamebait)

Anonymous Coward | more than 8 years ago | (#15762517)

As long as none of the languages used is Python, which gets the Zealots out...

Ruby is worse (1, Funny)

Anonymous Coward | more than 8 years ago | (#15762590)

As long as none of the languages used is Python, which gets the Zealots out...

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.

Re:Ruby is worse (1)

MarkByers (770551) | more than 8 years ago | (#15762670)

Ruby is great. I cannot imagine what would make you say those things.


Help me with my Ruby Sudoku Solver []

Re:Ruby is worse (1)

mangu (126918) | more than 8 years ago | (#15762798)

Ruby is great. I cannot imagine what would make you say those things.

Probably stuff like

def r a;!(i=a=~/0/)?p(a):((?1..?9).map-(0..80).map{|j|a[ j]+(i-j)%9*

has something to do with people being turned off by Ruby... Besides, can't you write the same program in a shorter way using APL?

If you want to obfuscate, at least you should try to do it in a beautiful and elegant way, like this Perl program. []

Who said anything about obfuscation? (1)

MarkByers (770551) | more than 8 years ago | (#15762847)

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.

Re:Ruby is worse (2, Interesting)

jlarocco (851450) | more than 8 years ago | (#15763275)

Give me a break. Nobody writes Ruby that way.

Ruby is far from perfect, and it's not for everyone, but that can be said for any language. You could at least try to criticize it for its faults, not some guy who programs like a moron.

OMFG!!!1 C is a bastardization. Only crazy zealots program in C, cause they're always doing stuff like this [] or this. [] You'd have to be a zealot to use C!

See how stupid that looks?

Re:Ruby is worse (1)

crmartin (98227) | more than 8 years ago | (#15763050)

How did you miss insulting C, Prolog and ML?

Re:Ruby is worse (1)

Javaman59 (524434) | more than 8 years ago | (#15764777)

No, *THE* language for zealots today is Ruby.
No, zealotry is not the same as enthusiasm, or simple fadishness. Whether or not the current enthusiasm for ruby is warranted, it is only enthusiasm, not zealotry. FWIW, enthusiasm can be appealing, where zealotry turns people off, and that is why ruby is getting so much attention.

Only zealots would respond to an obvious troll n/m (1)

oSand (880494) | more than 8 years ago | (#15765234)

No message. No message.

Re:Only zealots would respond to an obvious troll (1)

Javaman59 (524434) | more than 8 years ago | (#15765455)

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!)

Mathworks already went with Java (2, Interesting)

Latent Heat (558884) | more than 8 years ago | (#15764888)

What you really want for this project is Java. Really.

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, 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.

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

Anonymous Coward | more than 8 years ago | (#15762532)

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.

Re:Do one thing at a time. (1)

try_anything (880404) | more than 8 years ago | (#15763727)

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.

Re:Do one thing at a time. (0)

Anonymous Coward | more than 8 years ago | (#15763838)

If someone is developing something in Matlab I assume that what they are doing is non-trivial, like processing a signal for instance. They probably start by using Matlab's tool kits and block sets. Their problems may go a bit beyond transcription. For instance, can they expect the same floating point results from Matlab and C++. That one could provide some strange and annoying results. Finding a library with the functions available in Matlab could be a challenge. People are implementing some amazing stuff in Matlab and from what I've seen, transcribing it to C++ is a little more difficult than mere transcription.

Here's a good one; a very faithful rendition of 802.11 done in Matlab. e/ []

Re:Do one thing at a time. (1)

try_anything (880404) | more than 8 years ago | (#15763900)

They expect to transition their entire codebase to C++, so I assume they don't depend on Matlab libraries that they don't have the means (and rights) to port to C++ as well -- either that or they're willing to interface their C++ code to the Matlab libraries they depend on.

Start High, Then Low (3, Insightful)

Webz (210489) | more than 8 years ago | (#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.

Re:Start High, Then Low (1)

scum-e-bag (211846) | more than 8 years ago | (#15762615)

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.

Re:Start High, Then Low (1)

DrSkwid (118965) | more than 8 years ago | (#15762734)

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.

Re:Start High, Then Low (1)

Eustace Tilley (23991) | more than 8 years ago | (#15762858)

Development time is the best metric only if you are using trivial amounts of hardware.

Re:Start High, Then Low (2, Informative)

swillden (191260) | more than 8 years ago | (#15763004)

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

What GNU code do you mean? There are many official GNU projects, some very elegant, some rather crufty, most a mixture of both. Your comment makes no sense.

Sounds good in theory (0)

Anonymous Coward | more than 8 years ago | (#15765578)

I've seen this philosophy in practice at companies several times and it never worked out that way.

Prototype in VB, production in C.

Prototype in ColdFusion, production in Java.

The problem is that once the prototype works, management sees it and says "Ship it!" You can tell them over and over that it isn't maintainable or extensible or robust and all they see is the pretty UI and they think "I like pie" or whatever goes through their heads and they say again "Ship it!" If it is missing critical features (and it probably is - it is a prototype after all) they say "You created all this in just 3 weeks - you can surely add the missing features in a couple of days. Then ship it!"

So you either end up with

1) an absolute mess of a product because this was supposed to be a prototype and the thing is a series of nasty hacks, the programmers who have to maintain it are basically living in hell until they give up and find a better job. Their replacements curse them forever for their incompetence and can't believe anyone would be so stupid.

2) programmers have been hit by the 1st case so many times that they let management call what they do prototyping, but work as if it is production code for version 1.0. They may be constrained by the language in some ways, but overall life is actually not bad.

In neither case does anyone ever go back and rewrite the application in the lower level language. At least that has been my experience.

Proprietry lock-in (0)

gormanly (134067) | more than 8 years ago | (#15762537)

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 chance of both flourishing and enduring.

Good luck!

Re:Proprietry lock-in (1)

Bastard of Subhumani (827601) | more than 8 years ago | (#15762562)

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 (3, Interesting)

antifoidulus (807088) | more than 8 years ago | (#15762580)

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 (5, Interesting)

jellomizer (103300) | more than 8 years ago | (#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.

Re:Proprietry lock-in (1)

hazem (472289) | more than 8 years ago | (#15763648)

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.

Re:Proprietry lock-in (0)

Anonymous Coward | more than 8 years ago | (#15765178)

"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..."

Dude, that's a circular argument if I ever saw one. Let me condense it.

"It'll be cheaper because more people will buy it because it will be cheaper."

Yeah. Just sell it for cheaper in the first place if that makes you more money.

It's not like developer time is a variable cost and Matlab a fixed cost. Matlab's costs can also be accounted for on a per-unit basis.

This is very much an absolute-terms argument.

Let us say these engineers are paid $50 an hour, and Matlab costs $5000 for each year of licensing.

If Matlab saves 100 hours in aggregate, then Matlab is the cheaper solution.

I honestly don't know where you're coming from in distinguishing in-house versus selling the product. Unless I'm missing some arcane part of the tax code of your country, that shouldn't make any difference whatsoever. $1 spent on in-house stuff is the same amount of money as $1 spent on product.

Re:Proprietry lock-in (0)

Anonymous Coward | more than 8 years ago | (#15766060)

I think he (she?) is assuming you bundle a copy of Matlab with each copy of the software sold. Don't ask me why.

Re:Proprietry lock-in (1)

GigsVT (208848) | more than 8 years ago | (#15766367)

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.

Re:Proprietry lock-in (1)

hazem (472289) | more than 8 years ago | (#15766629)

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...

Re:Proprietry lock-in (2, Insightful)

try_anything (880404) | more than 8 years ago | (#15763790)

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.

Re:Proprietry lock-in (1)

john.r.strohm (586791) | more than 8 years ago | (#15765637)

Let's start with facts, shall we?

Here's the price sheet: /Download/33872_91012v25_NA_INDV.pdf []

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.

Re:Proprietry lock-in (1)

DrSkwid (118965) | more than 8 years ago | (#15762743)

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.

Re:Proprietry lock-in (1)

Javaman59 (524434) | more than 8 years ago | (#15764658)

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?

Re:Proprietry lock-in (1)

DrSkwid (118965) | more than 8 years ago | (#15765341)

BSD, go for it

GNU Octave (1)

Schraegstrichpunkt (931443) | more than 8 years ago | (#15763992)

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.

The myth of lock-in (1)

Anonymous MadCoe (613739) | more than 8 years ago | (#15765404)

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.

The easy way (0)

Xamusk (702162) | more than 8 years ago | (#15762558)

Use Python []

If everyone is thinking alike, then somebody isn't thinking. (George S. Patton)

Re:The easy way (2, Informative)

josephdrivein (924831) | more than 8 years ago | (#15762606)

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.

Re:The easy way (3, Insightful)

EsbenMoseHansen (731150) | more than 8 years ago | (#15762692)

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.

Re:The easy way (1)

polymath69 (94161) | more than 8 years ago | (#15763845)

I am not picking on you, but the thing that I am about to say is one that I wish appeared on the record more often.

So it won't be nor faster nor (a lot) easier.

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.

Can you do modules in Matlab? (1)

Da Gawd Fatha (952678) | more than 8 years ago | (#15762563)

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. November/016220.html []

The above link should be of help.

Re:Can you do modules in Matlab? (1)

OoberMick (674746) | more than 8 years ago | (#15762762)

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. If on the other hand you are writing something like a ODE solver that can be used in many different ways you might find this is exactly the way to go. Let MATLAB be the glue.

Sahibs (0, Offtopic)

A.Chwunbee (838021) | more than 8 years ago | (#15762566)

Esteemed sahibs, is one of the languages being Urdu?

Software wants to be free (3, Funny)

Anonymous Coward | more than 8 years ago | (#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.

Re:Software wants to be free (0)

Anonymous Coward | more than 8 years ago | (#15763676)

Dumb fucking zealot. That isn't how the business world works you idiot. Maybe one day you'll get out of mom and dad's basement and realize that.

Re:Software wants to be free (0)

Anonymous Coward | more than 8 years ago | (#15789952)

What's good about C++? (1)

aersixb9 (267695) | more than 8 years ago | (#15762579)

Although C++ is the current standard, it seems very inefficient to start a large project over in a new language, unless the old language has a flaw that prevents the products from getting marketed. I would be extremely hesitant to replace the language everybody is familiar with, and which all the product writing and debugging was already completed in...unless I absolutely had to. I'm not familiar with matlab, so I can't say if C++ is either a better solution, or a solution that is so much better that it's worth starting over...although if it is the second case, I would discard matlab and only use one language, so that testing and coding could be done with ~20-50% less effort...I've tried knowing and coding in two languages at the same time, and it's extremely difficult, I always forget what function names are associated with which languages, and that kind of thing. Plus you'll need to do the testing/debugging/coding twice for everything with two languages...

Choose one language for development. (4, Interesting)

jellomizer (103300) | more than 8 years ago | (#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.

Re:Choose one language for development. (2, Informative)

maxume (22995) | more than 8 years ago | (#15762765)

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.

Re:Choose one language for development. (1)

drgonzo59 (747139) | more than 8 years ago | (#15764061)

"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 change. But it will not be random (as in %50 of the time C++ team get something done fast and 50% Matlab team gets something done faster)! In reality the Matlab team will always be ahead of the C++ team. According to the post it already is! That means that C++ will just have to catch up to the Matlab team. Which is not too bad. The Matlab team will always be in charge of implementing new features, testing the concept, verifying the Math. They will spit out the results then the C++ team will just have to match it. Besides Matlab is common enough of a skill if you know where to look for those people

This situation has its own advantages (1)

rocjoe71 (545053) | more than 8 years ago | (#15762592)

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 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.

Why do this at all? (4, Insightful)

kognate (322256) | more than 8 years ago | (#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? (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15762872)

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 and dirty" programming styles. You just don't have to wory about what is habbening behind the curtain, much different than when programming in c++.

If some guys in your team claim they already worked in c++ and they think migration won't be any problem, be sure to check wether they really had programming experiences with a PROJECT OF THIS SCALE. It is much more difficult to build a complex application in c++ than in matlab without producing unreadable unreliable and malfunctioning spaghetti-code. This is something especially non-IT researchers (such as me) tend to overlook.

And if it's a piece of software that will require user interaction, be sure to either have the GUI and the program framework up and running before the migration of the "worker" code starts or else have an IT PROFESSIONAL evaluate how much work it will be to create the GUI for your application. Because creating a GUI to your application is MUCH more difficult than creating one in matlab (calculate the time in minutes you needed to do it in matlab times thousand).


Re:Why do this at all? (1)

tepples (727027) | more than 8 years ago | (#15763031)

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 [] free to distribute?

Re:Why do this at all? (1)

try_anything (880404) | more than 8 years ago | (#15763767)

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).

Re:Why do this at all? (1)

Midnight Warrior (32619) | more than 8 years ago | (#15764611)

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 training taught me to understand what a scientist says, but I never really developed the mindset to be a scientist. Neither could do the other's job to everyone's satisfaction. I serve in roles similar to that in my job where I bridge everyone's needs and goals.

We have faced this decision recently with a Matlab-like program called IDL, by RSI Inc (now called ITT [] ). Our future work is getting so big and monstrous that IDL cannot deal with the datasets we need to process. Fundamentally, our scientists love the language - mostly. The CS people think it sucks as a language. But the language developers wisely provided ways to bridge their work with your code, and vice versa. They even developed an IDL-JAVA bridge a couple of years back. They have rudimentary support for XML (one of our coders rebridged that to Xerces a bit better) and he also bridged in HDF5 [] better than they did.

Still, our original concept of build it in IDL and optimize the hard parts in C just simple isn't going to cut it now. So now we will build the framework in C++ and let them add plugins that use IDL. C++ provides access to importing/exporting all the nasty data types, user interface, and handles the bulk of memory management. C++ also provides an easy bridge to a multitude of other languages.

It's tough, but the scientists are going to get the flexibility to poke and prod with new ideas, while the C++ folks keep the production users happy.

Learn C++ first... (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15762607)

...and you wouldn't ask such trollish questions.

Compile the Matlab (3, Informative)

jabuzz (182671) | more than 8 years ago | (#15762613)

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.

Re:Compile the Matlab (1)

Hast (24833) | more than 8 years ago | (#15765763)

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 the C/C++ code is done for one script let everyone use that instead for their research. That way everyone benefits from the speed increases.

Naturally to make a complete stand alone program you'll have to reimplement some stuff that are not critical wrt profiling. But you may be able to use the built in .m -> c functionality for that.

I'm also sure you can find a lot of info on this online. Matlab is *the* standard tool for numerical research and a lot of people have been playing with it.

Do it in C++ from the start (2, Interesting)

mangu (126918) | more than 8 years ago | (#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++.

Re:Do it in C++ from the start (1)

OoberMick (674746) | more than 8 years ago | (#15762852)

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 method it is hard. Interpreted languages like MATLAB don't exist because people don't want to write user interfaces they exist because the maths is difficult and complicated.

Re:Do it in C++ from the start (4, Insightful)

mangu (126918) | more than 8 years ago | (#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++ [] . 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.

Re:Do it in C++ from the start (1)

twistedcubic (577194) | more than 8 years ago | (#15770678)

  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.

Visual Basic? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15762644)

I heard that CS dudes who come fresh from the university can do everything with Visual Basic...

Button's, Textfields... I'm sure you'll need Textfields... even numbers are Text!!!

Re:Visual Basic? (0)

Anonymous Coward | more than 8 years ago | (#15765177)

Nope, VB is no longer the proprietary, "compiled" to p-code/byte-code/non-CPU-code language of choice by colleges anymore, Java is.

It depends on what you're developing (1)

stienman (51024) | more than 8 years ago | (#15762697)

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.


Bass ackwards (1)

Latent Heat (558884) | more than 8 years ago | (#15764904)

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.

Re:Bass ackwards...actually, retrograde (1)

creatools (990501) | more than 8 years ago | (#15766881)

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

Use ITPP C++ library which maps perfetly to matlab (2, Informative)

smogzer (643417) | more than 8 years ago | (#15762701)

Drop matlab. Use [] 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... (3, Insightful)

occamboy (583175) | more than 8 years ago | (#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.

skip them both (0)

Anonymous Coward | more than 8 years ago | (#15762771)

Just go straight to FORTRAN. Most of the numerical analysis you'd need is already implemented very efficiently.

Drop Matlab (1)

Cassini2 (956052) | more than 8 years ago | (#15762803)

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.

mexy (0)

Anonymous Coward | more than 8 years ago | (#15762862)

so you can implement most important bits of you algorithm in C++ and make them callable from matlab using mex, you have a nice environment for playing around, also to check correctness of C++ results against Matlab.

One thing though, make sure you're C++ stuff has an interface/data structures you're happy to use from C++, once you've got that then wrap with mex. Otherwise, if you make things that rely on mex's matrix data structures it hurts, and makes lots of work useless when you move to all C++...i see... it is obvious.

The simple solution (0)

Anonymous Coward | more than 8 years ago | (#15762910)

Do your broadcast in the majority language, such as English here in the states, than use subtitles for the next runner up, such as Spanish. Man, the solution was so obvious. You really need to get out more. - Getting Real (-1, Offtopic)

RobK (24783) | more than 8 years ago | (#15763190)

Go to and BUY a copy of the book "Getting Real".

The solution is NOT ruby or rails or another tool or asking slashdot. It's getting down to business. "Getting Real" *WILL* change your perspective and make some of the most difficult questions easy to answer. []

In fact, get the site license, it's cheap and you can share it with others so that everyone can have a clue.

It's that good. - Getting Real (-1)

Anonymous Coward | more than 8 years ago | (#15763691)

Spam! You're spamming dude! Your question is OFF TOPIC!

don't repeat yourself (0)

Anonymous Coward | more than 8 years ago | (#15763216)

Well, I haven't used MATLAB since my master's thesis, and C++ makes me break out in painful red welts, so don't believe anything I say. But in my 10+ years of programming, I've learned many important lessons. One of them is, if you can help it, Don't Repeat Yourself. Parallel development in different languages?? Ouch!

Another lesson I've learned is, Premature Optimization is Bad. If there's a way you can call C++ from MATLAB or vice-versa, do it. Even if it requires shipping massive libraries or doing ugly things like sending data between two running processes. Of course in the case of MATLAB (commercial product) this might not be as practical as combining C++ and Ruby for instance, but consider it.

As posters above have alluded, there will come a point in the parallel development where, for instance, a one-line function call in MATLAB will take a massive investment to implement in C++ from scratch, and so forth. Trying to maintain parallel branches in different languages is just a recipe for trouble.

So, try and keep things as disjoint as possible. If you do decide to do things in both languages, be aware that the increase in cost may actually be a factor of 3 or 4, not just a factor of 2.

We need more information (1)

Anonymous Brave Guy (457657) | more than 8 years ago | (#15763264)

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.

Re:We need more information (1)

Viol8 (599362) | more than 8 years ago | (#15789645)

"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?

Re:We need more information (1)

Anonymous Brave Guy (457657) | more than 8 years ago | (#15789924)

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.)

Don't drop MATLAB (3, Interesting)

vijayiyer (728590) | more than 8 years ago | (#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.

Re:Don't drop MATLAB (1)

No. 24601 (657888) | more than 8 years ago | (#15763801)

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 a high-level prototype for your application/logic written in MATLAB first. Once the idea has been properly simulated, then you can go and design everything in an performance optimized language like C/C++.

Do the Prototype then Drop Matlab (1)

Cassini2 (956052) | more than 8 years ago | (#15764273)

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.

Compiler (1)

Julian Morrison (5575) | more than 8 years ago | (#15763389)

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.

Similar Situation (4, Insightful)

robbyjo (315601) | more than 8 years ago | (#15763399)

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 [] , LAPACK [] , ATLAS [] , 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 / values. Often times, prototypes breaks under certain datatype. When this happen, ask the scientist to fix it (rather than you fix it for him). Make sure that both prototype and the C++ program yield the exact same result.
  • Related to the fact that prototypes are often poorly designed... If a scientist invents a new algorithm that can take another class of algorithms, he often test it with one instance of such algorithm and claim it works. The problem is then, for the C++ programmers, you will need to make sure that it does work for ALL instances of the algorithm class that his algorithm is intended to perform at. The problem can be divided into two cases:
    1. A scientist claim that he invents a function f that can take any function g that belongs to the function class G. To be more succinct: The scientist invents f, such that f(g(x)) will yield the input that he wants, where g(x) is in G. Example of the function f is randomized analysis such as permutation analysis or bootstrap analysis, where they can be combined another analysis. In this case, f invokes g(x) multiple times while randomizing or perturbing the x a little bit, then aggregate the result of g(x) to yield the final result.
    2. A scientist claim that he invents a function g(x) which return an output compatible to x where it can be feed into any other algorithm class that can take x. An example of g(x) is an algorithm that can fill in missing data in x.

  • For the first case, it's often that the scientist pick one g(x) from a bazillion others out of class G. Then, you are required to make f(x) work with any g(x) which should belong to class G that you already make. This can create complication since you don't know what to expect. My suggestion is to work with the scientist. Scientists often dislike when things collapses like a house of cards when his algorithm can't combine with another algorithm which belongs to class G. (It should, since he claims to be so). Iron out the kinks.
  • For the second case, it's often much easier to work with. You just need to pay attention on the speed / accuracy.
  • GUI. Prototypes often doesn't have GUI or only have really buggy rudimentary GUI. Scientists often don't like to deal with the trinkets. They want the results / numbers. GUI can be a big issue on how you should present your program to the user. You will want to consult BOTH the UI expert and/or the scientist. If your final program is going to be used by scientists, then you should ask the scientists on how he/she would use that program. GUI programming for research environment takes a LOT of time.

Re:Similar Situation (2, Insightful)

mangu (126918) | more than 8 years ago | (#15764095)

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 working data. Rewriting everything to use SVD in those cases was a real PITA, since many functions used QR internally and one had to modify the Matlab toolboxes library code. I ended with many adapted functions, like invfreqs_svd instead of invfreqs, for instance.

My conclusion was that, although it did textbook examples perfectly, Matlab wasn't robust enough to handle real-life problems.

Re:Similar Situation (0)

Anonymous Coward | more than 8 years ago | (#15764412)

Get real dude. Matlab is version 14 already. It tackles quite a lot of real-life problems. The only problem I'm complaining about is speed.

C++ (0)

Anonymous Coward | more than 8 years ago | (#15763437)

This isn't an answer to what you asked, and it's a comment that will probably be seen as trollish and immature by many. Plus, there isn't much chance you will follow this. Nevertheless, I strongly believe it, and I have to give you my advice...

Avoid C++ at nearly any cost. It's a complete disaster of a language, and it's worth a significant cost to use something else. C++ is the direct cause of a significant chunk of what's wrong with the state of software in the last decade.

Think about the complexity C++ forces you to deal with. For example: every time you write a function, should it take its arguments by value, by reference, or by pointer? Or by pointer to pointer? Or by smart pointer? If smart pointer, which smart pointer? Should the arguments be const? Etc. Just one example of something that just about every other modern language deals with for you, but you must tediously do it EVERY TIME in C++.

Alternatives? I assume you are using C++ because efficiency of execution is a major concern (if it's not, shame on you for even considering C++!). I would recommend looking into OCaml in that case. It's a statically typed, nonpure functional language with full support for class-based OO programming. And it's brutally fast, especially considering how high level it is.

If efficiency of execution is not a serious concern, then hey, it's pretty trivial to find something that would be better than C++.

Re:C++ (2, Insightful)

mangu (126918) | more than 8 years ago | (#15764192)

For example: every time you write a function, should it take its arguments by value, by reference, or by pointer?

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).

Re:C++ (0)

Anonymous Coward | more than 8 years ago | (#15764962)

(I am the same poster as your parent.)

A few years ago I decided to learn C++ for real. So I did. For a while I had a love/hate relationship with it. The STL, for instance, is great in many ways. The genericity of its iterator concept and its algorithms is great and it's a shame that more people haven't picked up on it.

But gradually I realized that it really was just the mess I sometimes thought it was. Even the C++ experts more or less admit as much. They are constantly apologizing for various features of C++ that they recommend not be used. (export, dynamic exception checking, most macros, autoptr, valarray, C-style casts, etc...) Scott Meyers says in the foreward to Herb Sutter's Exceptional C++ "I fell into the traps he (and C++) laid before me more often than I'd like to admit." That's what it's like to work with C++. The language works against you.

Scott Meyers pointed out elsewhere that what irritates him about C++ is that in C++ you don't just have rules about what is good practice and then occasionally exceptions to those rules... but you then also have exceptions to the exceptions, and sometimes even exceptions to those!

"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."

I certainly wouldn't uphold either Ruby or Perl as paragons of a sensible syntax, but the C++ syntax is a complete catastrophe (Perl's pretty horrible too, but Ruby isn't that bad). Try writing a parser for C++. Seriously. Try. It's a seriously big project. And that's insane. The incomplete C++ grammar in the back of Stroustrup's TC++PL is 20 pages long. INCOMPLETE. It's impossible to provide a complete grammar in something like BNF form because certain aspects of parsing the language depend on its semantics. This is absurd.

My experience has been that people who are serious fans of C++ (and even moreso Java, though Java zealots fortunately seem to be rarer nowadays) simply don't have enough experience with other languages to really be qualified to decide which is better (apologies if this doesn't apply to you). Haskell, OCaml, Standard ML, Erlang, Scheme... C++ programmers ignore these languages to their peril.

How often have I been programming in one of those languages and thought "Darn, if only I had pointers!" or "Drat, the way parameter passing works in this language isn't what I want!" or "Curses, I need more control over the memory management here!"? NEVER. Not once.

You're right that C++ gives you more control over some details of how things work. But 99.5% of the time, those details are irrelevant to the problem at hand, and C++ forces you to deal with them constantly anyway.

Re:C++ (1)

mangu (126918) | more than 8 years ago | (#15765633)

How often have I been programming in one of those languages and thought "Darn, if only I had pointers!"

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.

Matlab's prices (1)

Circuit Breaker (114482) | more than 8 years ago | (#15763445)

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.

Depends on Program Complexity (1)

Ksigpaul (665724) | more than 8 years ago | (#15764989)

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.

Code generation? (0)

Anonymous Coward | more than 8 years ago | (#15765116)

I am currently working in an environment where a large part of our system is developed, simulated, and tested in Matlab. After the design has been passed we generate source code to combine with the rest of the system. I know that Matlab can generate C/C++ and Ada, maybe something like this would work in your case.

Ultimatly you would not have to "switch" at all. You could generate the Matlab relavent modules, place some C++ wrappers around them and plug them into your system. In the end it would allow you to keep the Matlab simulation environment and not have to go through a lot of effort to baseline a release when changes are needed.

Free Matlab work-alikes? (1)

MrBlic (27241) | more than 8 years ago | (#15765694)

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.)


check out Star-P (1)

starpdude (990506) | more than 8 years ago | (#15766013)

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 [] Other prototyping languages will be available in the future, like Python.

Prototype in one language first (1)

Thunderbear (4257) | more than 8 years ago | (#15768262)

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.

keep 2 languages (1)

Saltation (756369) | more than 8 years ago | (#15770413)

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.: []

Prototype in the most straightforward language (1)

eliasen (566529) | more than 8 years ago | (#15787560)

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++!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>