Managing Parallel Development in Two Languages?

Works well by Anonymous Coward · 2006-07-21 23:37 · Score: 0, Flamebait

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

Do one thing at a time. by Anonymous Coward · 2006-07-21 23:47 · Score: 2, Insightful

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. by try_anything · 2006-07-22 07:32 · Score: 1

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. by Anonymous Coward · 2006-07-22 08:10 · Score: 0

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. http://www.mathworks.com/matlabcentral/fileexchang e/loadFile.do?objectId=3540&objectType=file
Re:Do one thing at a time. by try_anything · 2006-07-22 08:36 · Score: 1

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 by Webz · 2006-07-21 23:49 · Score: 3, Insightful

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 by scum-e-bag · 2006-07-22 00:46 · Score: 1

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.

--
Does it go on forever?
Re:Start High, Then Low by DrSkwid · 2006-07-22 01:46 · Score: 1

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.

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Re:Start High, Then Low by Eustace+Tilley · 2006-07-22 02:33 · Score: 1

Development time is the best metric only if you are using trivial amounts of hardware.
Re:Start High, Then Low by swillden · 2006-07-22 03:26 · Score: 2, Informative

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.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.

Proprietry lock-in by gormanly · 2006-07-21 23:50 · Score: 0

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 by Bastard+of+Subhumani · 2006-07-22 00:11 · Score: 1

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.
Re:Proprietry lock-in by antifoidulus · 2006-07-22 00:25 · Score: 3, Interesting

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
Re:Proprietry lock-in by jellomizer · 2006-07-22 01:01 · Score: 5, Interesting

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.
Re:Proprietry lock-in by DrSkwid · 2006-07-22 01:49 · Score: 1

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
Re:Proprietry lock-in by hazem · 2006-07-22 06:58 · Score: 1

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 by try_anything · 2006-07-22 07:51 · Score: 2, Insightful

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 by Javaman59 · 2006-07-22 13:48 · Score: 1

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?

--
I'm a software visionary. I don't code.
Re:Proprietry lock-in by Anonymous Coward · 2006-07-22 18:41 · Score: 0

"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 by DrSkwid · 2006-07-22 20:52 · Score: 1

BSD, go for it

--
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Re:Proprietry lock-in by john.r.strohm · 2006-07-23 00:45 · Score: 1

Let's start with facts, shall we?

Here's the price sheet: https://tagteamdbserver.mathworks.com/ttserverroot /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 by Anonymous Coward · 2006-07-23 03:59 · Score: 0

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 by GigsVT · 2006-07-23 06:00 · Score: 1

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.
Re:Proprietry lock-in by hazem · 2006-07-23 07:34 · Score: 1

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

The easy way by Xamusk · 2006-07-22 00:10 · Score: 0

Use Python

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

Re:The easy way by josephdrivein · 2006-07-22 00:41 · Score: 2, Informative

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 by EsbenMoseHansen · 2006-07-22 01:26 · Score: 3, Insightful

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.
Re:The easy way by polymath69 · 2006-07-22 08:15 · Score: 1

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.

--

--
I don't want to rule the world... I just want to be in charge of mayonnaise.

Can you do modules in Matlab? by Da+Gawd+Fatha · 2006-07-22 00:12 · Score: 1

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

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

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

The above link should be of help.

Re:Can you do modules in Matlab? by OoberMick · 2006-07-22 01:59 · Score: 1

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.

Software wants to be free by Anonymous Coward · 2006-07-22 00:15 · Score: 3, Funny

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 by Anonymous Coward · 2006-07-22 07:09 · Score: 0

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 by Anonymous Coward · 2006-07-26 23:43 · Score: 0

http://en.wiktionary.org/wiki/joke

What's good about C++? by aersixb9 · 2006-07-22 00:23 · Score: 0

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. by jellomizer · 2006-07-22 00:28 · Score: 4, Interesting

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.

Re:Choose one language for development. by maxume · 2006-07-22 02:00 · Score: 2, Informative

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.

--
Nerd rage is the funniest rage.
Re:Choose one language for development. by drgonzo59 · 2006-07-22 09:25 · Score: 1

"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

Ruby is worse by Anonymous Coward · 2006-07-22 00:31 · Score: 1, Funny

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 by MarkByers · 2006-07-22 01:13 · Score: 1

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

---

Help me with my Ruby Sudoku Solver

--
I'll probably be modded down for this...
Re:Ruby is worse by mangu · 2006-07-22 02:09 · Score: 1

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* (i/9^j/9)*(i/27-j/27|i%9/3-j%9/3)*9}).map{|k|r$` 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.
Re:Ruby is worse by crmartin · 2006-07-22 03:43 · Score: 1

How did you miss insulting C, Prolog and ML?
Re:Ruby is worse by jlarocco · 2006-07-22 04:50 · Score: 2, Interesting

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?

--
Maybe not
Re:Ruby is worse by Javaman59 · 2006-07-22 14:44 · Score: 1

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.

--
I'm a software visionary. I don't code.

This situation has its own advantages by rocjoe71 · 2006-07-22 00:34 · Score: 1

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.

--
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)

Why do this at all? by kognate · 2006-07-22 00:35 · Score: 4, Insightful

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? by Anonymous Coward · 2006-07-22 02:37 · Score: 1, Insightful

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

Daniel.
Re:Why do this at all? by tepples · 2006-07-22 03:36 · Score: 1

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? by try_anything · 2006-07-22 07:43 · Score: 1

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? by Midnight+Warrior · 2006-07-22 13:21 · Score: 1

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.

Compile the Matlab by jabuzz · 2006-07-22 00:45 · Score: 3, Informative

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 by Hast · 2006-07-23 01:56 · Score: 1

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 by mangu · 2006-07-22 00:50 · Score: 2, Interesting

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 by OoberMick · 2006-07-22 02:30 · Score: 1

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 by mangu · 2006-07-22 02:52 · Score: 4, Insightful

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 by twistedcubic · 2006-07-24 05:07 · Score: 1

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

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

It depends on what you're developing by stienman · 2006-07-22 01:28 · Score: 1

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

Use ITPP C++ library which maps perfetly to matlab by smogzer · 2006-07-22 01:30 · Score: 2, Informative

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.

Been there, Done That... by occamboy · 2006-07-22 01:36 · Score: 3, Insightful

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 by Anonymous Coward · 2006-07-22 02:01 · Score: 0

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

Drop Matlab by Cassini2 · 2006-07-22 02:11 · Score: 1

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.

Who said anything about obfuscation? by MarkByers · 2006-07-22 02:29 · Score: 1

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

mexy by Anonymous Coward · 2006-07-22 02:34 · Score: 0

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 by Anonymous Coward · 2006-07-22 02:55 · Score: 0

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.

don't repeat yourself by Anonymous Coward · 2006-07-22 04:35 · Score: 0

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 by Anonymous+Brave+Guy · 2006-07-22 04:47 · Score: 1

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.

Re:We need more information by Viol8 · 2006-07-26 21:18 · Score: 1

"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 by Anonymous+Brave+Guy · 2006-07-26 23:32 · Score: 1

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

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

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Re:We need more information by Viol8 · 2006-07-27 00:46 · Score: 1

If its not on the axis then its just "sqrt((x2 - x1) * (x2 - x1) + (y2 - y1) * (y2 - y1))"
obviously calculating the subtractions first. And for 3D you just add in "+ (z2 - z1) * (z2 - z1)".
Not sure why you need to re-arrange the equation especially since the normal version
contains 2 subtractions and 2 multiplications whereas yours contains 1 division, 2 mults
and 1 addition. Can't see how that would be faster.
Re:We need more information by Anonymous+Brave+Guy · 2006-07-27 01:54 · Score: 1

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

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Re:We need more information by Viol8 · 2006-07-27 02:31 · Score: 1

Pythagorus's theorum is accurate. Wtf are you talking about?
Re:We need more information by Anonymous+Brave+Guy · 2006-07-27 03:51 · Score: 1

Pythagoras is accurate. A naive numerical implementation is not.

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

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

Really, if you're interested in what you're missing here, go check out an introductory numerical analysis textbook. They usually start by explaining the way floating point numbers are represented within a modern computer, and the kinds of errors that can creep into floating point calculations as a result. Getting things like Pythagoras and quadratics right (or rather, not unnecessarily wrong) are typical "case studies".

This sort of thing is one of the big differences between coding maths in a low-level programming language and coding maths with a dedicated tool like Matlab: with the dedicated tool, it's probably going out of its way behind the scenes to choose the most accurate algorithms for you, while if you choose to code things up low level, you have to do that sort of thing for yourself. It can be done, but it requires a much greater understanding of how computers do maths (which is not the same as how mathematicians do it).

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Re:We need more information by Viol8 · 2006-07-27 20:51 · Score: 1

Since when is division in IEEE 754 any more accurate than multiplication? Your example in C++ would be no more accurate than the standard method. Sorry.
Re:We need more information by Anonymous+Brave+Guy · 2006-07-27 23:16 · Score: 1

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

Really, this is elementary stuff. The fact that you keep missing the point doesn't mean there isn't a point, it just means you're not sufficiently familiar with the field to understand the danger. Please go and skim the first couple of chapters of a good numerical analysis textbook.

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Re:We need more information by Viol8 · 2006-07-28 00:51 · Score: 1

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

FYI I do 3D graphics programming so I do have a clue about this but I guess we'll just have to agree to disagree.
Re:We need more information by Anonymous+Brave+Guy · 2006-07-28 01:11 · Score: 1

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

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

We'll obviously have to agree to disagree on this one, so I leave you with one final thought: if you're not missing anything and I'm the one who doesn't understand, then why does Numerical Recipies in C++ use a function called pythag that implements the method I'm talking about (complete with checking relative sizes of the inputs and taking absolute values, as a real implementation must), and why do languages as diverse as Java and Tcl provide hypot functions in their libraries, with documentation explicitly noting that they avoid risks of intermediate underflow/overflow?

--
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.

Don't drop MATLAB by vijayiyer · 2006-07-22 04:59 · Score: 3, Interesting

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 by No.+24601 · 2006-07-22 07:54 · Score: 1

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

Compiler by Julian+Morrison · 2006-07-22 05:21 · Score: 1

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 by robbyjo · 2006-07-22 05:25 · Score: 4, Insightful

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

--

--
Error 500: Internal sig error

Re:Similar Situation by mangu · 2006-07-22 09:38 · Score: 2, Insightful

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 by Anonymous Coward · 2006-07-22 11:41 · Score: 0

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++ by Anonymous Coward · 2006-07-22 05:41 · Score: 0

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++ by mangu · 2006-07-22 10:17 · Score: 2, Insightful

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++ by Anonymous Coward · 2006-07-22 16:23 · Score: 0

(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++ by mangu · 2006-07-23 00:44 · Score: 1

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 by Circuit+Breaker · 2006-07-22 05:42 · Score: 1

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.

GNU Octave by Schraegstrichpunkt · 2006-07-22 09:04 · Score: 1

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/

Do the Prototype then Drop Matlab by Cassini2 · 2006-07-22 10:42 · Score: 1

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.

Mathworks already went with Java by Latent+Heat · 2006-07-22 15:44 · Score: 2, Interesting

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

Bass ackwards by Latent+Heat · 2006-07-22 15:52 · Score: 1

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.

Depends on Program Complexity by Ksigpaul · 2006-07-22 16:41 · Score: 1

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? by Anonymous Coward · 2006-07-22 17:59 · Score: 0

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.

Re:Visual Basic? by Anonymous Coward · 2006-07-22 18:40 · Score: 0

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

Only zealots would respond to an obvious troll n/m by oSand · 2006-07-22 19:37 · Score: 1

No message. No message.

The myth of lock-in by Anonymous+MadCoe · 2006-07-22 21:49 · Score: 1

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.

Re:Only zealots would respond to an obvious troll by Javaman59 · 2006-07-22 22:36 · Score: 1

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.

Sounds good in theory by Anonymous Coward · 2006-07-23 00:18 · Score: 0

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.

Free Matlab work-alikes? by MrBlic · 2006-07-23 01:26 · Score: 1

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!

check out Star-P by starpdude · 2006-07-23 03:42 · Score: 1

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.

Re:Bass ackwards...actually, retrograde by creatools · 2006-07-23 09:41 · Score: 1

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

Prototype in one language first by Thunderbear · 2006-07-23 20:56 · Score: 1

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

keep 2 languages by Saltation · 2006-07-24 04:32 · Score: 1

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

Prototype in the most straightforward language by eliasen · 2006-07-26 11:20 · Score: 1

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

Slashdot Mirror

Managing Parallel Development in Two Languages?

108 comments