Are minor math mistakes a major problem for engineering students?

[CrossFit415]

If I'm making minor errors on my math tests, is it wise to continue majoring in engineering? With these small mistakes?

 

[micromass]

What kind of mistakes??

In any case, you should learn to double or triple check your work. If you make a mistake as an engineer, then your bridge will collapse. This is no reason to stop with your major in engineering, but you should work on it.

 

[Chunkysalsa]

I find that the more problems you do the less minor mistakes you make. I remember making tons of mistakes in circuit analysis (all tiny sign errors or calculation errors), after dong a ton of problems I noticed I rarely made mistakes.

Either way, if you make mistakes often then check your work often. Everyone makes mistakes. One of my professors offers up a dollar to anyone who can find a typo or mistake in his lecture notes (and he's starting to go broke).

I often check my computations with software (wolfram alpha and MATLAB work great)

 

[moouers]

What kind of mistakes??

In any case, you should learn to double or triple check your work. If you make a mistake as an engineer, then your bridge will collapse. This is no reason to stop with your major in engineering, but you should work on it.

Indeed. I am usually one of the last people done with any test requiring mathematics. It's not because I am slow or didn't study, but because I just double check every problem and triple check the problems that caused any amount of confusion or uncertainty. I don't know how much time you generally have left before the test must be turned in, but if you have plenty of time left, I would suggest either slowing down or double checking your work...maybe even combine both!

Off-topic...micromass, I absolutely love your signature: "I am become the supreme onion, the saddener of worlds".

 

[Hobin]

In any case, you should learn to double or triple check your work. If you make a mistake as an engineer, then your bridge will collapse. This is no reason to stop with your major in engineering, but you should work on it.

Gee, thank you for making me feel guilty about my quick pace when working on mathematical problems. *wink*

 

[twofish-quant]

In any case, you should learn to double or triple check your work. If you make a mistake as an engineer, then your bridge will collapse.

It doesn't work this way.

Humans are fallible and if you are in a project in which one human arithmetic mistake can cause a catastrophe then there is something seriously wrong with the way that the project is managed. Humans make mistakes, and if you have a situation in which a math mistake causes a disaster, then you are *doomed* because someone *will* make an calculation error.

The mistakes that case disasters are generally conceptual or management ones.

 

[twofish-quant]

If I'm making minor errors on my math tests, is it wise to continue majoring in engineering? With these small mistakes?

If you are doing well on the tests, I wouldn't worry about it.

 

[DivisionByZro]

It doesn't work this way.

Humans are fallible and if you are in a project in which one human arithmetic mistake can cause a catastrophe then there is something seriously wrong with the way that the project is managed. Humans make mistakes, and if you have a situation in which a math mistake causes a disaster, then you are *doomed* because someone *will* make an calculation error.

The mistakes that case disasters are generally conceptual or management ones.

I don't think micromass was meaning it literally. I simply think he was emphasizing the necessary skill of double/triple checking one's work. I am sure nobody can argue of the importance of being able to re-check ones work, in any field.

 

[twofish-quant]

I simply think he was emphasizing the necessary skill of double/triple checking one's work. I am sure nobody can argue of the importance of being able to re-check ones work, in any field.

I can. If you focus too much on minor math mistakes, then you miss thinking about the major conceptual or process issues that will cause bridges to fall down. Getting the numbers right is pointless if you are using the wrong formula or misunderstanding the situation.

There's a fun scene in the movie Apollo 13, when the engineers had to make a critical calculation by hand, and what happened was that they gave it to several different people to each calculate it separately, and they had some confidence in the answer when they independently came up with the same answer. I've been in similar "real life" situations, and if there is a safety/business critical calculation, you *never* want one person to do it. Typically *dozens* of people go through the calculations before it gets pushed to production.

A lot of my views of this are influenced my testing environment. When I was an undergraduate, the graders would take off small amounts for math mistakes, but you'd get major points removed if you misunderstood the problem. Part of the point of tests is to teach a culture to point out which mistakes are indeed "minor" and which mistakes can cost lives or billions in losses.

 

[Angry Citizen]

If I'm making minor errors on my math tests, is it wise to continue majoring in engineering? With these small mistakes?

I wouldn't sweat it. I personally can't stand the modern engineering education system that relies so heavily on computational prowess. That's not to say computation isn't important - especially since it gives you an idea of what the answer "should" look like, so you can know when the computer spits out a wrong answer. I'm a very slow calculator because I take my time and try not to make stupid errors, which means I'm very reliable in my answers. But I'm penalized on tests for not rushing through things.

 

[sweetpotato]

Whether micromass's comment was literal or not, I have to agree with twofish here. As an engineer I make minor mistakes all day long. I catch a lot of these mistakes myself, but the remainder of the mistakes are caught by the senior engineer who reviews my work, the technicians, and in the very system by which my company tests our product- the testing procedures. Everything ends up being checked, and double-checked, and triple-checked, and tested, many times over by many different people. This is the way good engineering works. Relying only on yourself to check your work is not only ineffective, it can be dangerous in engineering. Good engineering and management practices do not allow this.

 

[AlephZero]

Everything ends up being checked, and double-checked, and triple-checked, and tested, many times over by many different people. This is the way good engineering works. Relying only on yourself to check your work is not only ineffective, it can be dangerous in engineering. Good engineering and management practices do not allow this.

Sure, but relying on other people to find your mistakes can be career limiting, especially if you make a lot of mistakes.

In my experience engineering gets much more interesting in situations where you learn by testing that what you designed hasn't "read the textbooks and learned how to behave properly". That's when you find out which of your colleages can think, and which of them can only put numbers into formulas...

 

[Vanadium 50]

It doesn't work this way.

Sometimes it does. (I would submit that as a former theorist and present quant, you are not an expert in engineering.)

Yes, if a calculation is important, multiple people will do it. And multiple people can make mistakes. This is unusual, but not unheard of, and the probability of two people making a mistake is not independent:

• It's easy to make a mistake on a tough problem than a simple one.
• Some mistakes (like sign errors) in a problem are easy to duplicate, so two people can get the same wrong answer.
• If you add a check step at the very end, just to make sure (perhaps even after multiple people have done it independently) , the person doing the check has a harder time to spot a problem that the person starting from scratch.
• It is human nature that when one is not solely responsible for something that the error rate goes up. Joe knows if he makes a mistake Bob will catch it.

I personally have spotted such an error on a large construction project (that would have had serious - possibly even fatal - consequences) very late in the game, and after it had been signed off by multiple PE's. I spotted it entirely by accident.

There is a limit to how much you can gain by trying to get the individual error rate down, and there is a limit to how much you can gain by additional parallelism. So it's important to push on both fronts as hard as you can if you have safety concerns.

Getting back to the OP, making minor math errors is not a reason not to become an engineer, but it is a reason to improve your proficiency with mathematics.

 

[micromass]

I'm sure you all heard of this: http://articles.cnn.com/1999-09-30/tech/9909_30_mars.metric_1_mars-orbiter-climate-orbiter- spacecraft -team?_s=PM:TECH

 

[Travis_King]

A simple conversion error.

On a more damning scale: http://failures.wikispaces.com/L'Ambiance+Plaza]L'Ambiance[/PLAIN] Plaza Collapse

But no, small mistakes should not discourage you from becoming an engineer. Everyone makes mistakes. But you should work to limit them. Slow down. There's no need to rush through problems in real life (despite the pressure you feel during tests). Look things over, see if the numbers make sense in general. If you are suspending a car from a crane, and you calculate that you need a counter weight of 1,000,000 lbs, well, something doesn't seem right. (obviously this doesn't translate for tiny errors, but then that is why you use factors of safety in design).

 

[chiro]

For the OP if you want to understand examples of how mistakes are made in a particular field, it would be helpful if you looked at the specific protocols that are in place for that field.

It is not surprising that mistakes are made and that as a result protocols are made to attempt to prevent such mistakes or similar mistakes from happening again.

It is not perfect of course, but it would really give an insight into avoiding the kinds of errors that all kinds of people in the field have made in the past.

Also probably one of the best pieces of advise I have ever heard about mistakes is the simple carpenter line: "measure twice and cut once".

 

[twofish-quant]

Sometimes it does. (I would submit that as a former theorist and present quant, you are not an expert in engineering.)

I do have some experience in deploying mission critical software in which a mistake could cost vast sums of money (i.e. billions). There's a process for doing this. It's an exercise in software engineering. There's also the topic of financial engineering, which could also cause large problems if done wrong.

I personally have spotted such an error on a large construction project (that would have had serious - possibly even fatal - consequences) very late in the game, and after it had been signed off by multiple PE's. I spotted it entirely by accident.

One thing that reduces the error rate is that doing a post-mortem analysis of what went wrong. If you have a situation in which someone *almost* deployed something with a critical error and it was discovered by accident, then this is unacceptable. You go back into the process and figure out what kept the error from being discovered early in the process. One reason to accept that "people are human" is that it becomes easy to find someone to blame, fire that person, find someone else, and go through the cycle.

Something else that you can do is to come up with an expected defect rate based on previous experience with the same sort of software. If you do testing, and you don't find bugs, then at that point you need to be very suspicious, because if the number of defects is below expectations that probably means that your testing is insufficient.

If you rely on luck to prevent accidents, then your luck will run out.

 

[twofish-quant]

Sure, but relying on other people to find your mistakes can be career limiting, especially if you make a lot of mistakes.

Sometimes you don't want to rely on people. A lot of our systems run automated tests on anything that gets checked in, and if there is a deviation, then e-mails get sent out, and people look at the issue. Also, you can run automated tests before anything gets checked in, but there is a balance between throughness and time (i.e. if you want to run everything against the full test suite, it takes three to five days to run).

This does a good job of removing the "flip the sign" type of error. It doesn't do a very good job of "the market behaves in an unexpected way" sort of errors. There are now a ton of new processes (most of them government required) that were put in place after the financial crash to deal with the second type of issue.

There's also a lot of back and forth in the specification stage. You write a formula, and then someone in another part of the company reviews that formula, and asks tough questions about that, and then you document the questions and the answers, and all this happens before anyone writes code. There's also the policy stage where you think about incentives and disincentives. You don't want an environment in which people feel like they will get punished for calling attention to a mistake, particularly if it is one that they made, because once you have this environment, people will not bring up mistakes and issues.

 

[twofish-quant]

It is human nature that when one is not solely responsible for something that the error rate goes up. Joe knows if he makes a mistake Bob will catch it.

I don't think this is true. Also, in my work environment "Bob" is an automated system. The automated system spits out reports that indicate something unexpected, and which point a human being looks back at it and sees if its good-unexpected or bad-unexpected. Computers can do a lot of checks a lot more reliably than human beings.

There are also some processes that are designed to prevent mistakes. One skill that would be useful to learn is double-entry bookkeepping. The accountants have figured out a way of entering accounting data that makes it more difficult to cause the numbers to go off because of math mistakes.

There are also some quick checks that I've found to be useful:

1) set everything to either 0, 1, or -1 It's a very fast way of checking if you have a sign error
2) try to find a conserved quantity and make sure that that quantity doesn't change as you go through the math
3) for anything that's multiple choice, it's often faster to plug the choices back into the equation than to work out the problem
4) calculate lower and upper bounds. For example, if you have a (simple expression) + (complex expression) where complex expression is positive, you can calculate simple expression, and get a lower bound
5) don't put in numbers until the end.

 

[sweetpotato]

[*] It is human nature that when one is not solely responsible for something that the error rate goes up. Joe knows if he makes a mistake Bob will catch it.
[/LIST]

However, there is also the factor of ego/professional pride. Joe knows that if he makes too many stupid mistakes, Bob will think he is a poor engineer (as well as get annoyed over having to fix them all). As a "Joe" (junior engineer) at my company, I try extremely hard to catch all my mistakes myself, because I don't want to look bad.

 

[twofish-quant]

However, there is also the factor of ego/professional pride. Joe knows that if he makes too many stupid mistakes, Bob will think he is a poor engineer (as well as get annoyed over having to fix them all). As a "Joe" (junior engineer) at my company, I try extremely hard to catch all my mistakes myself, because I don't want to look bad.

That's where corporate culture comes in. The places that I've worked at made a very important part of culture to regard mistakes as "expected." Once you regard mistakes as expected and part of the system, then you can deal with them rationally rather than trying to cover them up. In fact if you don't find defects in your own code, then either you are a perfect human being or a lousy tester. Which is more likely?

One other aspect is that when large sums of money are involved, you don't want anyone person making calculations. If you have one person writing code and there are no control mechanisms involved, its *trivially* easy to insert code that would create a deliberate "mistake" (if (account.owner == "twofish-quant") {account.amount = 1000000; account.credit_card_debt = 0.0; account.mortage_debt = 0.0 }).

More subtlely, code-wise there is nothing to keep you from flipping a sign, under/overpricing a security by 0.1% and then having a friend buy and sell said security. There are a ton of processes to make sure that doesn't happen.

You want your code to be subject to control mechanisms, because if money disappears, it's good to be able to prove that you didn't do it since you didn't have the keys to the vault, and any time you are within 1000 feet of critical code, there are twenty other people with you.

Some of these control mechanisms have been developed after "bad experiences". A good example of what bad things can happen if people are both willing and able to cover up their mistakes is Nick Leeson and the collapse of Barings. If the corporate incentives are such that people want to cover up mistakes and the responsibilities are set up so that people can, then by the time people figure out something is wrong, you are looking at billions of dollars in losses.

One curious thing is that some of the processes that banks use to avoid mistakes (deliberate or honest) are similar to those in theoretical astrophysics. Typically you want to have independent groups do the same calculation since they are going to do it in slightly different ways, and if they get the same answer, then you have more confidence that it's real. Also, there is a lot "double entry bookkeepping" in computational astrophysics. What you do is to calculate conserved quantities like energy, baryon number, and lepton number, and if those change, you know that there is a problem.

 

[chiro]

One other aspect is that when large sums of money are involved, you don't want anyone person making calculations. If you have one person writing code and there are no control mechanisms involved, its *trivially* easy to insert code that would create a deliberate "mistake" (if (account.owner == "twofish-quant") {account.amount = 1000000; account.credit_card_debt = 0.0; account.mortage_debt = 0.0 }).

Haha, looks like a better variant of the Office Space plan: better fill in those TPS reports!