Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Minor math mistakes? Engineer

  1. Feb 13, 2012 #1
    If I'm making minor errors on my math tests, is it wise to continue majoring in engineering? With these small mistakes?
  2. jcsd
  3. Feb 13, 2012 #2
    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.
  4. Feb 13, 2012 #3
    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)
  5. Feb 13, 2012 #4
    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".
  6. Feb 13, 2012 #5
    Gee, thank you for making me feel guilty about my quick pace when working on mathematical problems. *wink*
  7. Feb 13, 2012 #6
    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.
  8. Feb 13, 2012 #7
    If you are doing well on the tests, I wouldn't worry about it.
  9. Feb 13, 2012 #8
    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.
  10. Feb 13, 2012 #9
    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.
  11. Feb 13, 2012 #10
    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.
  12. Feb 14, 2012 #11
    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.
  13. Feb 14, 2012 #12


    User Avatar
    Science Advisor
    Homework Helper

    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...
  14. Feb 14, 2012 #13

    Vanadium 50

    User Avatar
    Staff Emeritus
    Science Advisor
    Education Advisor

    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.
  15. Feb 14, 2012 #14
    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 [Broken]
    Last edited by a moderator: May 5, 2017
  16. Feb 14, 2012 #15
    A simple conversion error.

    On a more damning scale: http://failures.wikispaces.com/L'Ambiance+Plaza]L'Ambiance[/PLAIN] [Broken] 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).
    Last edited by a moderator: May 5, 2017
  17. Feb 14, 2012 #16


    User Avatar
    Science Advisor

    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".
  18. Feb 15, 2012 #17
    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.

    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.
    Last edited: Feb 15, 2012
  19. Feb 15, 2012 #18
    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.
    Last edited: Feb 15, 2012
  20. Feb 15, 2012 #19
    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.
    Last edited: Feb 15, 2012
  21. Feb 15, 2012 #20
    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.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook