Any maths teachers on this forum?
Posted by: mista h on 29 April 2014
((can't see the point in placing brackets around numbers) (when not required)) ((as rediculous as placing brackets around words) (don't you think)) (Even if it does clarify matters) 
Does anybody know the formula for the area of a circle?
Which circle did you have in mind?
This would normally only be written by a crap computer programmer (or a new graduate) and if anybody working for me wrote something like that he or she would get a kick up the arse. You have to write code to be supported by the unfortunate soul coming after you and brackets make it all so much easier.
Rule number one in our programming guidelines used to be "Tricky programming is out" i.e. no ego trips.
Tricky programming is more often achieved by writing overly long and complex formuale into single lines, where a more logical arrangement of shorter formulae is indicated, brackets or not.
For me, the keys to clear code are logical overall structure, meaningful variable names, digestible (short!) pieces/lines, grouping where logical and spaces where required, and adequate annotation (simply tell those that come after you what each section of code is trying to do). People familiar with arithmetic can typically parse equations on the basis of the standard and universal rules without the need for redundant symbols.
Honestly, the orginal equation posted by the OP is not complex, nor misleading to anyone with even basic skills in arithmetic.
Back in early 80's, I wrote a lot of APL code for a company that sold manufacturing and financial planning applications.
The language was extremely powerful. It was based on array processing and used Greek letters as operators. This resulted in some absolutely inscrutable coding! We even used to have contests to see who could develop algorithms using the fewest, shortest lines of code. It was also an interpreted language -- just edit and go (no compile or load). It allowed us to show up at a customer site and implement pretty large customizations in a very short period time. Let's just say that change control was not quite as strongly practiced back then. 
Because APL allowed us to move so quickly (especially compared to the COBOL world, where the rules of structured design and peer review were firmly entrenched), we weren't nearly as thorough with our comments as we needed to be. When problems arose, it was often faster to re-develop from scratch rather than to untangle someone else's mess. Looking back, those were some fun and interesting times...
ATB.
Hook
This would normally only be written by a crap computer programmer (or a new graduate) and if anybody working for me wrote something like that he or she would get a kick up the arse. You have to write code to be supported by the unfortunate soul coming after you and brackets make it all so much easier.
Rule number one in our programming guidelines used to be "Tricky programming is out" i.e. no ego trips.
Tricky programming is more often achieved by writing overly long and complex formuale into single lines, where a more logical arrangement of shorter formulae is indicated, brackets or not.
For me, the keys to clear code are logical overall structure, meaningful variable names, digestible (short!) pieces/lines, grouping where logical and spaces where required, and adequate annotation (simply tell those that come after you what each section of code is trying to do). People familiar with arithmetic can typically parse equations on the basis of the standard and universal rules without the need for redundant symbols.
Honestly, the orginal equation posted by the OP is not complex, nor misleading to anyone with even basic skills in arithmetic.
Back in early 80's, I wrote a lot of APL code for a company that sold manufacturing and financial planning applications.
The language was extremely powerful. It was based on array processing and used Greek letters as operators. This resulted in some absolutely inscrutable coding! We even used to have contests to see who could develop algorithms using the fewest, shortest lines of code. It was also an interpreted language -- just edit and go (no compile or load). It allowed us to show up at a customer site and implement pretty large customizations in a very short period time. Let's just say that change control was not quite as strongly practiced back then.
Because APL allowed us to move so quickly (especially compared to the COBOL world, where the rules of structured design and peer review were firmly entrenched), we weren't nearly as thorough with our comments as we needed to be. When problems arose, it was often faster to re-develop from scratch rather than to untangle someone else's mess. Looking back, those were some fun and interesting times...
ATB.
Hook
I don't do much coding any more. Really just VB in excel macros. But the principles remain. The usefulness of comments (even for understanding your own work!) was drilled into me as an undergrad. Our computer science lecturer would fail assignments that weren't adequately annotated, even if they ran just fine.
This would normally only be written by a crap computer programmer (or a new graduate) and if anybody working for me wrote something like that he or she would get a kick up the arse. You have to write code to be supported by the unfortunate soul coming after you and brackets make it all so much easier.
Rule number one in our programming guidelines used to be "Tricky programming is out" i.e. no ego trips.
Tricky programming is more often achieved by writing overly long and complex formuale into single lines, where a more logical arrangement of shorter formulae is indicated, brackets or not.
For me, the keys to clear code are logical overall structure, meaningful variable names, digestible (short!) pieces/lines, grouping where logical and spaces where required, and adequate annotation (simply tell those that come after you what each section of code is trying to do). People familiar with arithmetic can typically parse equations on the basis of the standard and universal rules without the need for redundant symbols.
Honestly, the orginal equation posted by the OP is not complex, nor misleading to anyone with even basic skills in arithmetic.
Back in early 80's, I wrote a lot of APL code for a company that sold manufacturing and financial planning applications.
The language was extremely powerful. It was based on array processing and used Greek letters as operators. This resulted in some absolutely inscrutable coding! We even used to have contests to see who could develop algorithms using the fewest, shortest lines of code. It was also an interpreted language -- just edit and go (no compile or load). It allowed us to show up at a customer site and implement pretty large customizations in a very short period time. Let's just say that change control was not quite as strongly practiced back then.
Because APL allowed us to move so quickly (especially compared to the COBOL world, where the rules of structured design and peer review were firmly entrenched), we weren't nearly as thorough with our comments as we needed to be. When problems arose, it was often faster to re-develop from scratch rather than to untangle someone else's mess. Looking back, those were some fun and interesting times...
ATB.
Hook
I don't do much coding any more. Really just VB in excel macros. But the principles remain. The usefulness of comments (even for understanding your own work!) was drilled into me as an undergrad. Our computer science lecturer would fail assignments that weren't adequately annotated, even if they ran just fine.
Winky
If you'd have been studying mechanical engineering, your lecturer wouldn't have been very happy if you used pi r squared. He certainly would have cared.
If you'd have been studying mechanical engineering, your lecturer wouldn't have been very happy if you used pi r squared. He certainly would have cared.
This is news to me. I can't understand why one form would be preferred over another. Assuming you have the diameter to start with and want to calculate the area. Either divide by two, square and multiply by Pi, Or square, multiply by Pi and divide by 4. Same number of steps, same outcome.
With respect to which is "preferred" I'd actually argue that dividing by 4 is slightly more difficult than dividing by 2 for most people. You also have to square a bigger number, which is perhaps more difficult. These differences are VERY subtle but are both in favour of converting to radius first. If you start with a radius then it is a no-brainer - you wouldn't convert to diameter just for the pleasure of having divide your answer by 4.
In any case, it is so absolutely trivial that I can't imagine a lecturer caring one way or the other.
I think you're either making this issue up or are confusing this with the obscure debate about whether to use Pi or Tau.
http://tauday.com/tau-manifesto
The Pi Vs Tau argument at least makes sense at some level.
If you'd have been studying mechanical engineering, your lecturer wouldn't have been very happy if you used pi r squared. He certainly would have cared.
This is news to me. I can't understand why one form would be preferred over another. Assuming you have the diameter to start with and want to calculate the area. Either divide by two, square and multiply by Pi, Or square, multiply by Pi and divide by 4. Same number of steps, same outcome.
With respect to which is "preferred" I'd actually argue that dividing by 4 is slightly more difficult than dividing by 2 for most people. You also have to square a bigger number, which is perhaps more difficult. These differences are VERY subtle but are both in favour of converting to radius first. If you start with a radius then it is a no-brainer - you wouldn't convert to diameter just for the pleasure of having divide your answer by 4.
In any case, it is so absolutely trivial that I can't imagine a lecturer caring one way or the other.
I think you're either making this issue up or are confusing this with the obscure debate about whether to use Pi or Tau.
http://tauday.com/tau-manifesto
The Pi Vs Tau argument at least makes sense at some level.
I agree, it's not simpler to use d as opposed to r when calculating the area of a circle, just as niether has an advantage when calculating the second moment of inertia of a shaft, I = pi r to the power 4 over 4, v I = pi d to the power 4 over 64. etc.
It's nothing to do with the ease of use, it's simply a convention. You measure diameters, you dimension diameters, you manufacture diameters and you calculate using diameters. Introducing r into the the mix would increase the chance of an error.
Never heard of Tau, but the Pi Vs Tau argument seems pretty irrevelant to me.