Should Devs know how maths works?

[edmurphy99]

the ancient one, he who speaks of floppy disks I first used the PDP-7

[Lost User]

n.podbielski wrote:

I think it's not really dev work

Math is not your work, it's knowledge that makes you better at your work. It's not required for drawing forms or manipulating Xml, but it helps a lot when you need to implement/understand an algorithm. Try writing your own BigInt in .NET 2, or Google for 'encryption' in VB6 - the latter will most likely give examples that perform a calculation on a string. It helps in understanding that a Guid is merely a large number, why there's a difference in text-encodings, and why the or is used in C# to "add" enums together (BindingFlags.Public | BindingFlags.Instance)

Bastard Programmer from Hell :suss:

[Joe Simes]

Danny Martin wrote:

I am SO glad I'm not a Computer Scientist...

Me too!! And actually every person I've ever met that calls him/herself a Computer Scientist (with a BS in CS) has been a complete and pretentious twat! :-D

The environment that nurtures creative programmers kills management and marketing types - and vice versa. - Orson Scott Card

[Dan Neely]

Does it really matter. Y2K cash flinging had gutted the dept and most of the entry level courses were being taught by moonlighters. This one was confused because his calculatoridiot box had rounded the last displayed digit from 0 to 1, making him think it wasn't repeating. :doh:

3x12=36 2x12=24 1x12=12 0x12=18

[fgjsdhgsdhg3432423423234]

Anyone who write software need to know a little to be able to deal correctly with float. Too many supposed devs tell me "How come my number is not 0?!?!?" :rolleyes: I might be biased though, since I work mostly on embedded system...

[stiphy31]

I agree with the don't know and don't need to know parts, but I think a developer who could "care less" about how his code is actually being executed on the machine is not going to be a very good developer. In my experience good developers ALWAYS care about how things work because that's the only way to make things work better. And isn't that what development is really about, building things to make the world work better? Don't get me wrong, a developer who prioritizes getting his work done over figuring out how it works is a responsible developer. There are many things that I don't understand, wish I had time to investigate more fully, but probably never will. This isn't because I "care less" it's because I prioritize my activities and knowing how some particular thing works may be a lower priorty item in my queue. Personally, I am a 10+ year developer who's had quite a bit of success. I stopped taking math classes in High School with Pre-Calculus. I major'd in communications with only a minor in Computer Science that required no mathematics training. My years learning the in's and out's of the TV news business has served me better than if I spent those years learning how maths work as I now write software for the TV news business. My understanding of the business is much more important in creating useful products than understanding how a computer adds two numbers under the covers. BUT, when I have to dig deeper I do so willingly...when it came time to understand a hex dump I reprioritized my queue and learned how to do it etc. So my answer to the original question is devs should know how maths work if they've ever needed to know how maths work. Sean

[Alan Balkany]

Programmers SHOULD know how a computer does math. That's why this is covered in college courses. A few examples: 1. Overflow and underflow. If a clueless, self-taught "programmer" assumes an int is an "integer", they're oblivious to the possibility of overflow, and their code is a time bomb, waiting for a case that goes over the 32-bit limit. 2. Floating-point arithmetic. I've met programmers that think (floatNum / 7) * 7 == floatNum. They're oblivious to the fact that floating-point numbers are an approximation of real numbers that aren't a power of 2. 3. Efficiency. Programmers that have a clue how a computer does math know things, such as floating-point multiplication is faster than division, and integer math is faster than floating-point math. 4. Round-off error. The limited precision of computer math causes the order of operations to be significant, even when mathematically the order doesn't matter.

[KurtPW]

I might fit into the above category. I code and I take it very seriously. I did not start my working like as a coder, in fact far from it. I have no formal education as a coder but I have taught myself enough to get where I am. I constantly strive to improve my code and expand what I know. On those very rare occassions when I have free time I read as many tech articles and/or books on coding and theory as I can. But my math skills are still pretty poor. I know this and I accept that I will have to do crunchtime research every time a hex issue or binary issue pops up. No, it's not the best approach but it can work. I am at my job six years now and am writing some pretty important software for my client. FWIW, I am also thankful that there are folks smarter than I am willing to share what they know about these topics. Please remember that not everyone who doesn't do well at math is a script-kiddy slacker parasite just waiting to have you do their work for them. I realize that is NOT what you said, but I have to admit to frequently getting that feeling from many of the posts here on different topics. Maybe you math folks are just smarter than us none-too-good at math folks? I am willing to concede that point. But I would wager that many of us DO know that a clear understanding of the basics of computer math is important and that we DO try. We don't always succeed, but we try. Kurt

[MarvinMartian]

Data General 1401 as best I can recall. Had to toggle in a JPUN to kickstart the KSR terminal.

[BrainiacV]

You got me beat. Late '60s PDP-8/I PDP-8/I display[^] But then made up for it by being a computer operator for three Univac 418's. Univac 418's[^] That's me, mid '70s, with three computers to oversee, I had to be fast enough to be two places at once :laugh: Later, when I wrote the Biorhythm cartridge for the Bally Home Arcade (later Astrocade), I had to write a multi-byte binary multiply and divide math package to do the date calculations. I wish I had known how to do that in high school on the PDP-8/I, I ended up using the EAE (Extended Arithmetic Element) hardware to do date calculations. Turns out, every once in a while, a divide would take too long and the processor would then miss interrupts (really, really bad for the timesharing system it was running).

Psychosis at 10 Film at 11

[Quirkafleeg]

Don't all programmers start from this? http://en.wikipedia.org/wiki/File:Principia_Mathematica_theorem_54-43.png[^]

[Lost User]

BrainiacV wrote:

operator for three Univac 418's

I graduated as operator from the LEO III to a Univac 1108, thence to programming and the rest is history ...

The best things in life are not things.

[SeattleC]

Depends what you mean. Do you mean, "Do I know how addition and subtraction occur in 2's complement?" Do you mean, "Do I know what assembler instructions propogate the carry?" Do you mean, "Do I know how a carry-lookahead adder is implemented in logic gates?" These are pregressively deeper and deeper knowledge of how a computer does math(s). I've needed to know how 2's complement math works frequetly in my career. I've obviously had to know what assember instructions do the math and just how they work at least once or twice. I happen to know how a carry lookahead adder works, but I've never had to use that knowledge, since I prefer to keep my big clumsy fingers out of the actual hardware. The first topic were covered in detail in my CS undergrad coursework in the late '70's. The middle topic I got exposed to during a horrible machine-language project for pay in the late '70's. I'm talking M6800 machine language, 16kbytes RAM, no disk, paper tape, patch-the-binaries-because-the-source-code-didn't-fit-in-RAM, ahh-run-screaming! The third topic, I first encountered in 9th grade, when I was so bored in school that I began designing computer circuits to avoid falling asleep. I had this "Build Your Own Working Digital Computer" book. The topic was also covered in my CS coursework.

[patbob]

I do. Both kinds (integer & floating point). I learned how interger math happened back during my high school years, when my dad and I were both learning about computers. He was more into the theory and taught me how 2's complement math worked and how logic gates could be wired together to implement it. I was never taught that level of detail again. I didn't learn how the innards of an FPU worked until college, when I was asked to write a test for the FPU hardware of the college's Vaxs (apparently they failed from time to time). It even found a failure in a live system :) As for boolean logic, that was also during my high school years. Math class taught the expressions. I played with logic gates for fun outside of school. I found one of my dad's books that had circuit diagrams for the elecronics inside the gates that I studied until I understood them. My thoughts: if a developer doesn't understand the level beneath the one they program to (i.e. the one they can debug and fix), there will be times when they are completely ineffective. We don't get paid to be ineffective. Understanding two or more levels deeper won't help (unless there's the possibility of being able to debug at that level too), so isn't necessary. So, here's a joke absolutely every developer should find amusing.. How many times will this (C) loop iterate? for (float f = 0.0f; f < 1000000000.0; f = f + 1.0f) { } Note: float is a 4-byte IEEE floating point number.. pick an appropriate type in your favorite language. Please, nobody post the answer. If you don't know, go try it and figure it out for yourself.

patbob

[Chris Maunder]

Just stay clear of Tuggers. (Though it's been6 years since I lived there)

cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP

[KChandos]

What I've found over the years is that "normal" developers don't need to know how the computer performs math operations. Their development software simply does the magic. Here's where the caveat comes in: "Normal" developers = Business Application Developers Over my career I've primarily done business application development. In the few cases where I was doing scientific development, all the math rules changed. In the scientific arena, you need to understand what's really going on so that you can: 1. Optimize operations 2. Guarantee accuracy to xx digits Sounds simple, but it's not. If you really think it's simple just take a look at some of the "Big Number" math software from places like MIT. You'll see that how the number is constructed and managed becomes very important. Here's an exercise to try: Write a program that will divide a 100-digit number by a 50-digit number. At a company that I used to work for (back around 1989) this was exactly the challenge made to all programmers in the company by the company President. The hook? We developed in Natural on the IBM mainframe. For those who don't know, Natural is a 4GL created to run primarily against an ADABAS DBMS. Both ADABAS and Natural are the IP of Software AG. Within the company only two programmers, myself and one other, came up with solutions to this problem. His was pretty quick but had a couple of numeric domain issues, mine was slower but I neglected to check for a zero divisor. Both of us were awarded a (rather nice) bottle of champagne for our effort (the company President really just wanted to know that he had people who would actually take up the challenge. As it turns out, more than half of the employees started, but only two of us came up with practical implementations that didn't attempt to "extend" the language or environment).

[User 3760773]

If you are going to write software that does math then you have to know how computers represent numbers and how they do math. Both the representation of numbers and the methods used to do the calculations place limitation on what you can do and how you can do it.

[Doug Henderson]

I loved that ascii art Einstein portrait. If you don't know how the math works you will get it wrong. Consider floating point on the Univac 36-bit machines vs the Honeywell 36-bit machines. I was tasked with porting a computationally heavy application suite. As I recall, the Univac floating point registers were the same size and format as the memory values. The Honeywell registers were a different size, so you lost bits of precision when you stored a value. The result of calculations in registers did not compare equal to the same value after it had been stored to memory. Not only did I need to know how computer math worked, but how it was implemented on two different machines.

[jschell]

CDP1802 wrote:

And how could I overlook that people working on binary algorithmic calculating machines only need to know about those fundamentals when they are interested in it?

No idea what your point is since there is a great deal of programming that can be accomplished without understanding binary arithmetic (presumably that is what you are referring to.) Just as there is a great deal that can be accomplished without knowing how the hard drive works. Certainly in the past 10 years in my problem domains a knowledge of threads and data structures is needed even day to day and has a far greater impact than binary arithmetic. I have used binary arithmetic seldom and I suspect that some other idioms although more complex (in code not knowledge) could have been substituted easily. Could be that your problem domain requires a more extensive usage. But I haven't seen anything to suggest that is true for a majority of problem domains. Excluding perhaps the embedded domain.

[jschell]

Depends on the problem domains. For example in financial sectors you need to understand exactly how floating point numbers work on a computer. But you also need to understand such things a what 'rounding' means in terms of the computer as well as in terms of business domains (which are not computer driven.) But specific in depth knowledge of integer arithematic would not be needed. On the other hand there are probably domains where it is essential such as in embedded controllers which are likely to use bits to control functionality.