The parent makes a good point. Many of those Point of Sale terminals would probably make better voting machines than the expensive $100,000 each voting machines.
- Each of those point of sale terminals has a printer (for paper records). - Each has been thoroughly analysed to minimize the likelihood of hacking. - At least here in Canada, many of the communications are encrypted. - Due to widespread use, we have much empirical data on how hard / easy each machine is to hack. - Some have even been developed to minimize EMI emissions, so they don't broadcast everyones PIN (vote) around the room. - Many of the chips inside have been developed to resist hacking. They are designed so people can't easily get access to the firmware and encryption codes. They are designed to resist unauthorized reprogramming and remain a useful (functional) device.
All told, they would be a pretty inexpensive starting point if you wanted to build a secure voting system.
> Lastly "widely used" in the same context as AS/400 is really an oxymoron.
That's what I always thought, until I ran into an evil cult of AS/400 priests, and really regretted it. They were phenominally impressed with this new language called "VisualBasic". After that, my career sort of went to hell, and hasn't recovered its coolness since. On the otherhand, I have caught on to a wierd kind of employer speak which seems to sell things.
I always thought the botnet problem stemmed from a fundamental problems in Windows security. With Windows NT, we could secure the file system, secure printers, and secure network shares. We still could not secure the processor. The processor would run whatever code that happened to be loaded. Internet Explorer allows anyone that can figure out how to get the smallest piece of executable code onto your system a chance to run it.
Since Windows NT, we have Windows 2000 and Windows XP. Each seemed to progressively water down the security model until today, where every XP user is pretty much logged in with Admin rights.
We can secure the file system. Why can't we effectively limit what code the CPU executes?
It would differentiate you from the pile. I would still be looking for something in a "real" programming language, like C, C++, VB, C#, or something Web Related (HTML, Python). I would be wondering why you wrote something in Haskell? You better have a reason for picking a language widely used neither on a Windows Platform, nor on an AS/400 platform, nor on a Linux platform.
The biggest resume mistake that I have ever seen is when everyone in some college / university program takes a course where *EVERYONE* has to format the resume exactly the same way. The result is that the entire classes resumes look almost identical.
After I read the first two of those resumes, every single one of them gets weeded out.
You really need to do something on the first page that clearly gives me a reason to hire you. When reading through a stack of resumes, I am looking for a reason to hire you. Why are you better than everyone else? If you can't give me a reason to hire you in the first page, then you are out. I am not reading the second page.
Incidentally, I went to one of these photostat resume courses once. I did a resume on blue paper. I was held up as an example of the worst possible resume you could write. That resume netted me a job interview with a prestigious high-tech company at the time.
Lesson: avoid having the exact same resume format/content that your classmates have.
When hiring a minimal work experience, projects outside of school and work is often a strong indicator of talent. It also really reduces the list of applicants.
Often, the students that like technology enough to play are the students that you want in a technology project. Engineers need to want to do the work; they need to like the field. If you can find an applicant that likes the material, then that is the person you want to hire. These people will be motivated employees.
On the other hand, it is also depressing to go through a list of 3rd year software engineering students and realize that none of them have ever coded anything significant for fun. You really want to find the exception that has wrote a Windows program in C++ (or anything else) before. I get really sceptical when I hear students talk about Eiffel, Scheme, and Haskell programming ability. Those are good training languages, but have you ever coded anything real? I want the student that has coded a real program. A program written for fun. A program that was not a compulsory part of a mandatory course.
I use the following rule when determining if an ASSERT should be used or an if-statment should be used:
Does the condition you are testing for provably not exist in the release build?
If the problem might occur in the release build, you need an if-statment. Somehow, I either succeed in proving I don't need the ASSERT or if at all (because the condition will not happen), or I put in an if-statment. Asserts have very limited value if you are building real-time code where every fault is significant, must be properly dealt with, and must be traced back to the source.
The last time I checked thoroughly, the bank-client agreement specifically included a line to the effect of "the bank bears no responsibility for transactions taken including those in error". Originally, it was a line to deal with someone cashing a post-dated cheque early, but the statement also covers all sorts of other errors too. Here in Canada at least, the banking agreements say the bank is not responsible for transactions in error.
Once, it happened that a bank cashed a cheque in the wrong amount. We were a multi-national business client. The bank wouldn't fix it. Once a cheque clears, it is very difficult to reverse the transactions.
My understanding is only AC electromagnets are suitable for degaussing. It would take a large AC magnet to be sure of degaussing a hard drive completely. I don't think the small ones intended for degaussing CRT TV's would be effective. You would need one intended for the application.
Degaussing works by exposing the magnetic target to very strong fields. This makes everything follow the field of the electromagnet. Slowly the electromagnetic field intensity is reduced until you are left with essentially random fields. These random fields cancel each other out leaving no net magnetic moment. As gauss = magnetic field, no net magnetic field = degauss. Hence the term "Degauss".
Speaking as an engineering professional, user's are what ultimately make or break a project. They determine if it will succeed or fail.
Often you can ship a project without user approval. The people that will use the program/design/machine will not see the results of your labour until it is installed and operational at the customers site. As such, users do not have much impact on many of the initial stages of the project.
People forget that users are the ones that actually use your project. If they raise hell, or if they refuse to use your new technology, then the project is often left unfinished. The company will eventually see the project as a failure. Often the vendor is blamed. It can then be really hard to ever sell another program to that company again.
Users make or break an engineering project. Users determine if you will ever sell a second piece of software to a company again.
The x86 has way better instruction set than MIPS. Look at all those instructions, each with varying side-effects depending on status bits. The x86 instruction set has so many classic and vital instructions, like AAA (Ascii Adjust Accumulator).
Thoroughly covering the x86 architecture covers so much of CPU history: - 8-bit processors (8080A / 8085), - 16-bit processors (8086), - better 16-bit processors (80286), - 32-bit implementations (80386), - 16-bit addressing (8080 / 8085), - segmented addressing (8088 - 80286), - flat 32-bit addressing (80386), - COBOL currency style instructions (AAA and DAA), - FORTRAN floating point (FMUL), and - C style instruction set optimizations (CMOV). Covering the x86 instruction set reveals aspects of almost every historical computer language and programming language in existence! It takes students years to learn the architecture.
The MIPS architecture is comparatively clean, simple, and obvious. You can teach it in just one course, and cover so much less material. The x86 obviously has the superior instruction set. Besides, the x86 processors consume so much more power (watts and transistors) to do the same things as the MIPS architecture. Obviously, MIPS is just a bad design.
[sarcasm = off]
DOS is still in use in embedded applications
on
FreeDOS 1.0 Released
·
· Score: 1
I occasionally use DOS in embedded applications. DOS can actually be faster than Windows. DOS provides near direct hardware access. In Windows, you have so much stuff happening, that it is almost impossible to do anything with low latencies. Effectively, you have two choices: build some custom micro-controller board that can be programmed in assembly (or C), or run DOS on a PC and program in assembly (or C).
For one off systems, custom developing your own hardware costs way more than just using an obsolete PC. Besides, if the idea works out, you can port the code to a custom developed micro-controller board later.
If I remember correctly, as part of the BlackBerry lawsuit, a consultant was hired by NTP to go over his prior work with pagers. NTP had him sign an NDA. The consultant couldn't figure out why the hell NTP would hire him, as his work tended to show that RIM's positions were valid.
In any case, money was money. Essentially, he signed the NDA, NTP paid him, and then they said "now you can't tell RIM what you know..."
Essentially, they simply hired him so he would sign the NDA, then RIM could not find out about what he had done. As such, RIM could not use his technologies at trial against NTP.
On my display, some math notation is missing
on
Divine Proportions
·
· Score: 1
In screen, some of the math notation is missing. It might be confusing for someone trying to follow his proof.
Specifically: On the first line: sin B = sqrt(7) / 4 On the third line: sin (45+B) = (3 + sqrt(7)) / (4 * sqrt(2)) On the fourth line: d = 5 sin B/sin BDC = 5 * sqrt(7)/4 * (4*sqrt(2))/(3 + sqrt(7))*(3-sqrt(7))/(3-sqrt(7)) The (3-sqrt(7))/(3-sqrt(7)) comes from an effort to complete the square.
On the fifth line: d = 5*sqrt(2)*(3 * sqrt(7) - 7)/2 = 3.313693059
Law of Cosines isn't taught everywhere
on
Divine Proportions
·
· Score: 1
The law of cosines is only taught in some jurisdictions. Everywhere else, they appear to use some tortured workaround based on right triangles. This sucks, the law of cosines makes for a really quick solution when used appropriately.
Incidentally, in some countries they don't teach the vector cross-product either. This really makes a mess of vector math when you try to read many North American textbooks. Some branches of physics make frequent use of the vector cross-product.
I am looking at analyzing code for some high-reliability applications. For many applications, it is very difficult to determine the correct outputs for a given set of inputs. Specifically, most of the mathematical proving falls victim to the fact that in the end some poor engineer is developing the specification. At high reliability levels, the engineer may not even know all the fault modes of the inputs, so cannot accurately specify the correct outputs for all fault cases.
Things get worse, if you assume you have statistical failures on each of the inputs. Then the accuracy of the outputs can become governed by how accurately the statistical model describes the type and likelihood of faults on the inputs. Eventually, you reach the conclusion that no matter what we build, somehow, somewhere, it will be vulnerable to a fault, and we are simply doing a fault minimization exercise. We can't prove correctness. We can just minimize the severity and impact of the faults.
I did a computer architecture course a number of years ago. One day, we came to the consensus that the X86 architecture was an example of every computer architecture in existence. You want load store: look at all those MOV AX, xxxx instructions. You want register RISC, look at all those registers AX, BX, CX, DX, SI, DI, SP, BP. You want stack based: look at the FPU. You want vector parallel processing, look at those MMX/SSE instructions. You want symmetric multi-processing, look at those dual cores.
The course went quickly downhill after this observation. No one could figure out how incorporating every processor architecture into one product was a good thing...
You need to find out what is really happening. Often, the users are experiencing problems. I deal with industrial applications. Generally, I assume the users are having problems, and I am not getting accurate enough descriptions to debug with.
Often, the problems are real. It is just the cause that is not obvious.
We had a T.A. automatically grade assignments at the school where I worked. He wrote an automatic scanner to count the number of words in the comments, and to automatically run the programs and compare the output. He then assigned grades appropriately, computing the grade only on the number of words in the comments.
He then quite proudly stood up in front of the class as explained to them what he had done. He had no idea what was about to happen. Essentially, everyone in the class simultaneously worked out that it didn't matter what they put in the comments. They just needed to boost the word count. The class turned red and almost rioted. The professor's jaw dropped.
The professor recalled the assignments and had them regraded by a different T.A. After that day, the original T.A. was never allowed to mark another assignment.
I would agree with the statement that the prototype algorithms could be completed in Matlab. If you do that, then complete the algorithm development in Matlab. You really don't want to switch languages mid-way through algorithm development.
The practical problem that I have seen more than once, in a research situation, is that the researchers try to complete the application in Matlab. The result is usually a disaster for a full-fledged high-performance application. Matlab does math well, but other things disastrously.
For instance, the user interfaces in Matlab are generally not of production quality. VB and C++ really shine when it comes to user interface generation. Traditionally, most of the application development will go into designing a well laid out user interface.
Alternatively, are you doing a real-time servo control application? Have you ever tried to get Matlab to give deterministic interrupt response in the millisecond or microsecond range? Matlab wasn't intended to be used for real-time control code. It was intended to generate the parameters for control systems that could later be coded in C or C++.
Will your application scale? I encountered a situation where a series of six matrices were multiplied together. If you did the expression literally, then it generated an intermediate 50,000,000 by 50,000,000 square matrix. If you broke the expression into symbolic equations, it generated a 1,000 by 1,000 matrix. That is a huge reduction in computational complexity.
Just because some researchers can knock out a quick prototype in Matlab, does not mean that the prototype will scale nicely into a finished application. Wait until the researchers can deliver an algorithm, and then code the algorithm in C++ using the best available computational techniques.
I 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.
Slashdot Mirror
The parent makes a good point. Many of those Point of Sale terminals would probably make better voting machines than the expensive $100,000 each voting machines.
- Each of those point of sale terminals has a printer (for paper records).
- Each has been thoroughly analysed to minimize the likelihood of hacking.
- At least here in Canada, many of the communications are encrypted.
- Due to widespread use, we have much empirical data on how hard / easy each machine is to hack.
- Some have even been developed to minimize EMI emissions, so they don't broadcast everyones PIN (vote) around the room.
- Many of the chips inside have been developed to resist hacking. They are designed so people can't easily get access to the firmware and encryption codes. They are designed to resist unauthorized reprogramming and remain a useful (functional) device.
All told, they would be a pretty inexpensive starting point if you wanted to build a secure voting system.
But Microsoft's chip is so fast, it will make Windows Vista run quickly. Oh wait, nothing is fast enough for that.
Agreed.
> Lastly "widely used" in the same context as AS/400 is really an oxymoron.
That's what I always thought, until I ran into an evil cult of AS/400 priests, and really regretted it. They were phenominally impressed with this new language called "VisualBasic". After that, my career sort of went to hell, and hasn't recovered its coolness since. On the otherhand, I have caught on to a wierd kind of employer speak which seems to sell things.
Shoot me soon.
I always thought the botnet problem stemmed from a fundamental problems in Windows security. With Windows NT, we could secure the file system, secure printers, and secure network shares. We still could not secure the processor. The processor would run whatever code that happened to be loaded. Internet Explorer allows anyone that can figure out how to get the smallest piece of executable code onto your system a chance to run it.
Since Windows NT, we have Windows 2000 and Windows XP. Each seemed to progressively water down the security model until today, where every XP user is pretty much logged in with Admin rights.
We can secure the file system. Why can't we effectively limit what code the CPU executes?
It would differentiate you from the pile. I would still be looking for something in a "real" programming language, like C, C++, VB, C#, or something Web Related (HTML, Python). I would be wondering why you wrote something in Haskell? You better have a reason for picking a language widely used neither on a Windows Platform, nor on an AS/400 platform, nor on a Linux platform.
The biggest resume mistake that I have ever seen is when everyone in some college / university program takes a course where *EVERYONE* has to format the resume exactly the same way. The result is that the entire classes resumes look almost identical.
After I read the first two of those resumes, every single one of them gets weeded out.
You really need to do something on the first page that clearly gives me a reason to hire you. When reading through a stack of resumes, I am looking for a reason to hire you. Why are you better than everyone else? If you can't give me a reason to hire you in the first page, then you are out. I am not reading the second page.
Incidentally, I went to one of these photostat resume courses once. I did a resume on blue paper. I was held up as an example of the worst possible resume you could write. That resume netted me a job interview with a prestigious high-tech company at the time.
Lesson: avoid having the exact same resume format/content that your classmates have.
Agreed
When hiring a minimal work experience, projects outside of school and work is often a strong indicator of talent. It also really reduces the list of applicants.
Often, the students that like technology enough to play are the students that you want in a technology project. Engineers need to want to do the work; they need to like the field. If you can find an applicant that likes the material, then that is the person you want to hire. These people will be motivated employees.
On the other hand, it is also depressing to go through a list of 3rd year software engineering students and realize that none of them have ever coded anything significant for fun. You really want to find the exception that has wrote a Windows program in C++ (or anything else) before. I get really sceptical when I hear students talk about Eiffel, Scheme, and Haskell programming ability. Those are good training languages, but have you ever coded anything real? I want the student that has coded a real program. A program written for fun. A program that was not a compulsory part of a mandatory course.
Maybe they mean Stargate SG-1 is the longest currently running consecutive Sci-Fi show?
I use the following rule when determining if an ASSERT should be used or an if-statment should be used:
Does the condition you are testing for provably not exist in the release build?
If the problem might occur in the release build, you need an if-statment. Somehow, I either succeed in proving I don't need the ASSERT or if at all (because the condition will not happen), or I put in an if-statment. Asserts have very limited value if you are building real-time code where every fault is significant, must be properly dealt with, and must be traced back to the source.
The last time I checked thoroughly, the bank-client agreement specifically included a line to the effect of "the bank bears no responsibility for transactions taken including those in error". Originally, it was a line to deal with someone cashing a post-dated cheque early, but the statement also covers all sorts of other errors too. Here in Canada at least, the banking agreements say the bank is not responsible for transactions in error.
Once, it happened that a bank cashed a cheque in the wrong amount. We were a multi-national business client. The bank wouldn't fix it. Once a cheque clears, it is very difficult to reverse the transactions.
My understanding is only AC electromagnets are suitable for degaussing. It would take a large AC magnet to be sure of degaussing a hard drive completely. I don't think the small ones intended for degaussing CRT TV's would be effective. You would need one intended for the application.
Degaussing works by exposing the magnetic target to very strong fields. This makes everything follow the field of the electromagnet. Slowly the electromagnetic field intensity is reduced until you are left with essentially random fields. These random fields cancel each other out leaving no net magnetic moment. As gauss = magnetic field, no net magnetic field = degauss. Hence the term "Degauss".
Speaking as an engineering professional, user's are what ultimately make or break a project. They determine if it will succeed or fail.
Often you can ship a project without user approval. The people that will use the program/design/machine will not see the results of your labour until it is installed and operational at the customers site. As such, users do not have much impact on many of the initial stages of the project.
People forget that users are the ones that actually use your project. If they raise hell, or if they refuse to use your new technology, then the project is often left unfinished. The company will eventually see the project as a failure. Often the vendor is blamed. It can then be really hard to ever sell another program to that company again.
Users make or break an engineering project. Users determine if you will ever sell a second piece of software to a company again.
What do you have against x86?
The x86 has way better instruction set than MIPS. Look at all those instructions, each with varying side-effects depending on status bits. The x86 instruction set has so many classic and vital instructions, like AAA (Ascii Adjust Accumulator).
Thoroughly covering the x86 architecture covers so much of CPU history:
- 8-bit processors (8080A / 8085),
- 16-bit processors (8086),
- better 16-bit processors (80286),
- 32-bit implementations (80386),
- 16-bit addressing (8080 / 8085),
- segmented addressing (8088 - 80286),
- flat 32-bit addressing (80386),
- COBOL currency style instructions (AAA and DAA),
- FORTRAN floating point (FMUL), and
- C style instruction set optimizations (CMOV).
Covering the x86 instruction set reveals aspects of almost every historical computer language and programming language in existence! It takes students years to learn the architecture.
The MIPS architecture is comparatively clean, simple, and obvious. You can teach it in just one course, and cover so much less material. The x86 obviously has the superior instruction set. Besides, the x86 processors consume so much more power (watts and transistors) to do the same things as the MIPS architecture. Obviously, MIPS is just a bad design.
[sarcasm = off]
I occasionally use DOS in embedded applications. DOS can actually be faster than Windows. DOS provides near direct hardware access. In Windows, you have so much stuff happening, that it is almost impossible to do anything with low latencies. Effectively, you have two choices: build some custom micro-controller board that can be programmed in assembly (or C), or run DOS on a PC and program in assembly (or C).
For one off systems, custom developing your own hardware costs way more than just using an obsolete PC. Besides, if the idea works out, you can port the code to a custom developed micro-controller board later.
If I remember correctly, as part of the BlackBerry lawsuit, a consultant was hired by NTP to go over his prior work with pagers. NTP had him sign an NDA. The consultant couldn't figure out why the hell NTP would hire him, as his work tended to show that RIM's positions were valid.
..."
In any case, money was money. Essentially, he signed the NDA, NTP paid him, and then they said "now you can't tell RIM what you know
Essentially, they simply hired him so he would sign the NDA, then RIM could not find out about what he had done. As such, RIM could not use his technologies at trial against NTP.
In screen, some of the math notation is missing. It might be confusing for someone trying to follow his proof.
Specifically:
On the first line: sin B = sqrt(7) / 4
On the third line: sin (45+B) = (3 + sqrt(7)) / (4 * sqrt(2))
On the fourth line: d = 5 sin B/sin BDC = 5 * sqrt(7)/4 * (4*sqrt(2))/(3 + sqrt(7))*(3-sqrt(7))/(3-sqrt(7))
The (3-sqrt(7))/(3-sqrt(7)) comes from an effort to complete the square.
On the fifth line: d = 5*sqrt(2)*(3 * sqrt(7) - 7)/2 = 3.313693059
The law of cosines is only taught in some jurisdictions. Everywhere else, they appear to use some tortured workaround based on right triangles. This sucks, the law of cosines makes for a really quick solution when used appropriately.
Incidentally, in some countries they don't teach the vector cross-product either. This really makes a mess of vector math when you try to read many North American textbooks. Some branches of physics make frequent use of the vector cross-product.
I am looking at analyzing code for some high-reliability applications. For many applications, it is very difficult to determine the correct outputs for a given set of inputs. Specifically, most of the mathematical proving falls victim to the fact that in the end some poor engineer is developing the specification. At high reliability levels, the engineer may not even know all the fault modes of the inputs, so cannot accurately specify the correct outputs for all fault cases.
Things get worse, if you assume you have statistical failures on each of the inputs. Then the accuracy of the outputs can become governed by how accurately the statistical model describes the type and likelihood of faults on the inputs. Eventually, you reach the conclusion that no matter what we build, somehow, somewhere, it will be vulnerable to a fault, and we are simply doing a fault minimization exercise. We can't prove correctness. We can just minimize the severity and impact of the faults.
I did a computer architecture course a number of years ago. One day, we came to the consensus that the X86 architecture was an example of every computer architecture in existence. You want load store: look at all those MOV AX, xxxx instructions. You want register RISC, look at all those registers AX, BX, CX, DX, SI, DI, SP, BP. You want stack based: look at the FPU. You want vector parallel processing, look at those MMX/SSE instructions. You want symmetric multi-processing, look at those dual cores.
...
The course went quickly downhill after this observation. No one could figure out how incorporating every processor architecture into one product was a good thing
You need to find out what is really happening. Often, the users are experiencing problems. I deal with industrial applications. Generally, I assume the users are having problems, and I am not getting accurate enough descriptions to debug with.
Often, the problems are real. It is just the cause that is not obvious.
Why doesn't Microsoft make the mod chip?
That way, Microsoft could recover the console subsidy and let amateur (home) developers try to develop software for the XBox?
We had a T.A. automatically grade assignments at the school where I worked. He wrote an automatic scanner to count the number of words in the comments, and to automatically run the programs and compare the output. He then assigned grades appropriately, computing the grade only on the number of words in the comments.
He then quite proudly stood up in front of the class as explained to them what he had done. He had no idea what was about to happen. Essentially, everyone in the class simultaneously worked out that it didn't matter what they put in the comments. They just needed to boost the word count. The class turned red and almost rioted. The professor's jaw dropped.
The professor recalled the assignments and had them regraded by a different T.A. After that day, the original T.A. was never allowed to mark another assignment.
I would agree with the statement that the prototype algorithms could be completed in Matlab. If you do that, then complete the algorithm development in Matlab. You really don't want to switch languages mid-way through algorithm development.
The practical problem that I have seen more than once, in a research situation, is that the researchers try to complete the application in Matlab. The result is usually a disaster for a full-fledged high-performance application. Matlab does math well, but other things disastrously.
For instance, the user interfaces in Matlab are generally not of production quality. VB and C++ really shine when it comes to user interface generation. Traditionally, most of the application development will go into designing a well laid out user interface.
Alternatively, are you doing a real-time servo control application? Have you ever tried to get Matlab to give deterministic interrupt response in the millisecond or microsecond range? Matlab wasn't intended to be used for real-time control code. It was intended to generate the parameters for control systems that could later be coded in C or C++.
Will your application scale? I encountered a situation where a series of six matrices were multiplied together. If you did the expression literally, then it generated an intermediate 50,000,000 by 50,000,000 square matrix. If you broke the expression into symbolic equations, it generated a 1,000 by 1,000 matrix. That is a huge reduction in computational complexity.
Just because some researchers can knock out a quick prototype in Matlab, does not mean that the prototype will scale nicely into a finished application. Wait until the researchers can deliver an algorithm, and then code the algorithm in C++ using the best available computational techniques.
I 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.