quote:My experience leads me to the opposite conclusion. The more parentheses people use, the harder it is to decipher a long formula in code. It's too easy to mistake which close parenthesis goes with which open parenthesis
These days, any code editor worth its salt makes it very easy to tell which parentheses are paired. In many, if you put the cursor on one parentheses (or bracket, or quotation mark, etc.), the paired one is hilighted, bolded, etc.. Its pretty easy to read multiple nested parentheses when the editor does that for you.
Posts: 16551 | Registered: Feb 2003
| IP: Logged |
quote:My experience leads me to the opposite conclusion. The more parentheses people use, the harder it is to decipher a long formula in code. It's too easy to mistake which close parenthesis goes with which open parenthesis
These days, any code editor worth its salt makes it very easy to tell which parentheses are paired. In many, if you put the cursor on one parentheses (or bracket, or quotation mark, etc.), the paired one is hilighted, bolded, etc.. Its pretty easy to read multiple nested parentheses when the editor does that for you.
I still disagree. Both matlab and excel have this feature and I still find that the more parentheses used in a formula, the harder it is to decipher the formula. I help students try to trouble shoot these things daily and the more parentheses they've used, the more likely it is that they've made an error and the harder it will be to find that error. I've taken to starting by deleting all the unnecessary parentheses since this is often the only way to sort out which set of parentheses is wrong.
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
posted
:shrug: While it's certainly possible to use too many parentheses, I think they're far preferable to depending on left-to-right operation order.
But then, I don't deal with novice programmers much. The coders I deal with have years of experience and don't egregious numbers of parentheses.
Posts: 16551 | Registered: Feb 2003
| IP: Logged |
posted
It's worth noting, Rabbit, that neither Matlab nor Excel are "code editor(s) worth (their) salt." As Porter has noted, actual code editors make parentheses trivially easy to pair up. Heck, even some text editors -- albeit ones designed for code -- do this fairly well. Neither Excel nor Matlab do.
Posts: 37449 | Registered: May 1999
| IP: Logged |
quote:Porter has noted, actual code editors make parentheses trivially easy to pair up.
Porter said
quote:In many, if you put the cursor on one parentheses (or bracket, or quotation mark, etc.), the paired one is hilighted, bolded, etc.. Its pretty easy to read multiple nested parentheses when the editor does that for you.
I'm perfectly willing to believe there are better code editors but both matlab and excel have the feature Porter descibes. It's certainly helpful but I still find it very tedious to decipher formulas that contain many nested parentheses.
I'm not working with professional coders, I'm working with students. My students are not studying to become professional coders, they are studying to be engineers and scientist. As professionals, they are going to be using programs like excel and matlab and not "code editor(s) that are worth (their) salt".
Which takes me back to my original point. Understanding the standard order of operations is very important to any one who uses computer programs, like matlab, excel or even a graphing calculator, to evaluate long mathematical formulas. It's not just a text book problem that can be easily remedied by improving the notation used in text books.
[ April 11, 2011, 09:26 AM: Message edited by: The Rabbit ]
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
posted
Porter and Tom, Here's a sample of what I'm talking about.
Here is typical sort of formula that might be used in a class I teach entered taking advantage of the standard order of calculations.
Y = 5/0.25^2*((T1-2*T2/0.25+T3)/0.1^2/2-1/0.25^2*(T3-T1)/0.1/2)+1/2*T1
Here's the formula as entered as it would be entered by one of my typical students. It contains an error. Which formula is easiest to decipher? Go ahead and paste it into what ever code editor you like.
Y = (5/(0.25^2))*(((T1-(2*T2)/0.25+T3)/(2*(0.1^2)))-(1/(0.25^2)*(T3-T1)/(2*0.2))+((1/2)*T1))
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
posted
Hmm... I've never used a code editor to expand out expressions in that manner. What editor are you using, Tom, and what is the tool you used there called?
Posts: 16551 | Registered: Feb 2003
| IP: Logged |
posted
Wow...I wrote a little utility once to expand nested loops/brackets/etc like that; I had no idea that was available in an editor.
Posts: 324 | Registered: Mar 2008
| IP: Logged |
posted
It's part of the Idera toolkit for SQL Management Studio, which I used for this example as opposed to other editors because parentheses are more of a SQL thing.
Don't be TOO glad, though, because careful review will reveal that it actually indented it incorrectly. Of course, this is likely due to the error Rabbit mentioned.
Posts: 37449 | Registered: May 1999
| IP: Logged |
posted
I also much prefer the second version. At least I can get some sense of the grouping of expressions there. The first one is just a wall of numbers to me.
Posts: 3275 | Registered: May 2007
| IP: Logged |
posted
Well, it's still better than the utility I created, which would show you that something was out of whack, but wouldn't even try to offer any intuitive guesses on what might be wrong!
Posts: 324 | Registered: Mar 2008
| IP: Logged |
posted
Add an error to the first, then try to find it.
In order for us to find an error in the second using the first as authoritative, we'd have to be confident that we're parsing the first one correctly. Which, frankly, I'm not; the first is considerably harder to parse.
Posts: 37449 | Registered: May 1999
| IP: Logged |
posted
I think I see the error, but if it's what I think then it's unrelated to the parenthesis.
0.1^2/2 from the first equation appears as (2*(0.1^2)) in the second.
If this is correct, then I don't see what the use of parenthesis have to do with the committing or debugging of this error.
Posts: 3275 | Registered: May 2007
| IP: Logged |
quote:In order for us to find an error in the second using the first as authoritative, we'd have to be confident that we're parsing the first one correctly. Which, frankly, I'm not; the first is considerably harder to parse.
Yup. When I went to find the error in the second one, the first thing I did was start carefully adding parentheses to the first one so that I could tell what it was actually doing.
Posts: 16551 | Registered: Feb 2003
| IP: Logged |
quote:In order for us to find an error in the second using the first as authoritative, we'd have to be confident that we're parsing the first one correctly. Which, frankly, I'm not; the first is considerably harder to parse.
Yup. When I went to find the error in the second one, the first thing I did was start carefully adding parentheses to the first one so that I could tell what it was actually doing.
Curious. To find the error in the second one, I first go through and remove all the unnecessary parentheses. I parse the first one correctly essentially instantaneously.
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
quote:Curious. To find the error in the second one, I first go through and remove all the unnecessary parentheses. I parse the first one correctly essentially instantaneously.
And my method is to add parenthesis to the first one. When dealing with a complex expression (or query) that is not producing the results I expect, I start using parenthesis to logically group key components so they can be more easily considered in isolation of the other components.
Posts: 3275 | Registered: May 2007
| IP: Logged |
posted
The second is clearer, although they're both nightmares. By the way, who divides by 2 when they can multiply by 0.5?
Posts: 10645 | Registered: Jul 2004
| IP: Logged |
posted
I agree with Porter, Matt, and Tom: I believe I could find an error in an equation with more parenthesis faster than in one with fewer.
But really I think both equations ought to be broken into several intermediate equations. I would create a sequence of equations using dummy variables so that no expression contained more than a few operations.
The first equation rerendered: d1 = 0.25^2; nT2 = 2*T2/0.25; d2 = 2*0.1^2; d3 = 2*0.1; %nT1 = T1/d3; %Y = 5/d1*((T1-nT2+T3)/d2-1/d1*(T3-nT1))+1/2*T1; Y = 5/d1*((T1-nT2+T3)/d2-1/d1*(T3-T1)/d3)+1/2*T1;
There seems to be a missing parenthesis after d3 in the above expression, relative to the original expression.
The process of decoding the expression was much easier in the second case than in the first, where I often had to remind myself about what effect earlier operations were having on the one I was currently looking at.
<edit>Oops...I accidentally created a normalized T1 variable in interpreting the first expression. Interestingly, without realizing it, I happened to avoid this error in parsing the second case.</edit>
Posts: 2926 | Registered: Sep 2005
| IP: Logged |
posted
My first calculator was an HP. HP calculators have long been popular among engineers. In my experience, if you hand someone who isn't familiar with HPs, a calculator that use HP (or reverse) notation they haven't a clue what to do with it. But once people become accustomed to it, they are able to use the reverse notation far more quickly and accurately than people who use standard notation that requires using lots of brackets. Its really hard to find someone who has become proficient with the HP notation that doesn't prefer it.
I think its very much the same way with using the standard order of operations verses lots of brackets. It may be more difficult to become proficient at parsing equations using the standard order of operations, but once you've got it down its much faster and less error prone than using lots of brackets.
My students typically make the error in the example above by originally leaving out one of close parentheses. Then they get an error message and because they've used so many parentheses and don't take enough time to parsing the equation, they add the final parentheses in the wrong place.
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
quote:Originally posted by SenojRetep: I agree with Porter, Matt, and Tom: I believe I could find an error in an equation with more parenthesis faster than in one with fewer.[
Me, too.
quote:Originally posted by The Rabbit: Its really hard to find someone who has become proficient with the HP notation that doesn't prefer it.
I'm one of those people. I had to become proficient at HP notation for advanced calculus, chemistry and physics classes. Once I finished with undergraduate and could chose my own resources, I happily left Reverse Polish behind.
Posts: 831 | Registered: Jul 2005
| IP: Logged |
quote:By the way, who divides by 2 when they can multiply by 0.5?
She didn't just divide by two -- she multiplied by one divided by two.
Interestingly, I have discovered that in matlab using certain computer processors, dividing by 2 and multiplying by 0.5 give slightly different results. Not that differences out at the 15th and 16th decimal points are commonly of importance, but they are there.
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
posted
PS to the above: Of course, I haven't a problem with other people using reverse notation in their calculations, so long as they are chosing the convention which most consistently leads to accurate answers in the calculations they do.
Posts: 831 | Registered: Jul 2005
| IP: Logged |
quote:Interestingly, I have discovered that in matlab using certain computer processors, dividing by 2 and multiplying by 0.5 give slightly different results. Not that differences out at the 15th and 16th decimal points are commonly of importance, but they are there.
Hm. This is actually rather interesting. Which is more accurate?
Posts: 37449 | Registered: May 1999
| IP: Logged |
quote:By the way, who divides by 2 when they can multiply by 0.5?
She didn't just divide by two -- she multiplied by one divided by two.
Interestingly, I have discovered that in matlab using certain computer processors, dividing by 2 and multiplying by 0.5 give slightly different results. Not that differences out at the 15th and 16th decimal points are commonly of importance, but they are there.
That is interesting. Both 2 and 0.5 can be expressed in IEEE-754 binary floating point without rounding issues. I'd be really curious to see an example of an equation that produces different results depending on whether you divide by 2 or multiply by 0.5.
Posts: 3275 | Registered: May 2007
| IP: Logged |
posted
That's a problem with using a proprietary language like Matlab -- it's impossible to find out what's going on behind the scenes if it's making mistakes.
Posts: 16551 | Registered: Feb 2003
| IP: Logged |
The following set of formulas are each missing one close parentheses (I hope ). Find the error and post your corrected version. Please rank them in terms of how hard it was to find the error. Please report any software you used to help parse the formulas.
1. y = D*(1-1/r)*((c1-2*c2+c3)/dr^2+2/r*(c3-c2)/2/dr+k*(a*r-b)*c 2. y = D*(1-(1/r))*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2/(2*dr))+k*(a*r-b)*c2 3. y = (D*(1-(1/r))*((c1-2*c2+c3/(dr^2)+2/r*(c3-c2)/(2*dr)))+k*(a*r-b)*c2 4. y = D*(1-1/r)*((c1-2*c2+c3)/dr^2+2/r*(c3-c2)/(2*dr)+k*(a*r-b)*c2 5. y = (D*(1-(1/r)))*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr))+k*((a*r-b)*c2 6. y = D*(1-1/r)*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr)+k*(a*r-b)*c2 7. y = ((D*(1-(1/r)))*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr))+k*(a*r-b)*c2 8. y = (D*(1-(1/r)))*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr))+(k*(a*r-b)*c2 9. y = (((D*(1-(1/r)))*((c1-2*c2+c3)/(dr^2)+2/r*(c3-c2)/(2*dr)))+k*((a*r)-b)*c2
Edited to add: It appears that my inclinations on this are atypical. It would really help me as a teacher to get a better idea of how others see the problem. I'm guessing that there is some optimum level of bracketing and I think I have a guess where that optimum lies, but I'd really like to know how far off I am with that guess.
[ April 11, 2011, 02:30 PM: Message edited by: The Rabbit ]
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
quote:Originally posted by mr_porteiro_head: That's a problem with using a proprietary language like Matlab -- it's impossible to find out what's going on behind the scenes if it's making mistakes.
It's not making a mistake per se. It's a difference in round off error for floating point numbers. I don't think the problem is in matlab itself, because it occurs on some processors but not others. I discovered it when I was devising problems that demonstrated computer round off error.
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
quote:Originally posted by The Rabbit: This question has me interested (for instructional purposes. I'd appreciate anyone who is willing to answer all or part of the question.
I found this humorously ironic. Posts: 1080 | Registered: Apr 2006
| IP: Logged |
quote:Originally posted by The Rabbit: This question has me interested (for instructional purposes. I'd appreciate anyone who is willing to answer all or part of the question.
I found this humorously ironic.
I guess I should have said "the following formulas and preceding sentences are each missing one closing parenthesis."
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
quote:The following set of formulas are each missing one close parentheses (I hope [Big Grin] ).
I went through each one, correcting it as I went. Some of my "corrections" wouldn't actually change the result, such as it adding parentheses that weren't strictly needed.
Honestly, they were all the same. It's not a difficult formula -- I just went through and made sure that there were parentheses where there needed to be. It was pretty much the same process for each problem.
Each one ended up looking like one of these two:
code:
1. y = D*(1-1/r) *((c1-2*c2+c3)/(dr^2)+(2/r)* (c3-c2)/(2*dr)) +k*(a*r-b)*c2 2. y = D*(1-(1/r)) *((c1-2*c2+c3)/(dr^2)+(2/r)*((c3-c2)/(2*dr)))+k*(a*r-b)*c2
The first differnece is between 1/r and (1/r). Looking back, I can see that I just kept that as whatever the first one was. I felt no need to add or remove those parentheses.
The other is between (c3-c2)/(2*dr) and ((c3-c2)/(2*dr)). Since the there's a single division at the end, there's no confusion with not having the parentheses there.* Again, I appear to have stuck with whatever was in the original problem after the initial cleanup of mis-matched parentheses.
The only software I used was gVim, a text editor with a lot of features designed for editing code. The only features I used were the hilighting of and jumping to the matched parentheses when the cursor was on a parentheses.
Oh, and #8 was not missing any closing parentheses.
*eta: For example, a*b*c*d*e*f/g needs no parentheses to be clear, because it doesn't matter what order you do the multiplication and division, but a*b/c*d/e*f/g would need several.
Posts: 16551 | Registered: Feb 2003
| IP: Logged |
quote:*eta: For example, a*b*c*d*e*f/g needs no parentheses to be clear, because it doesn't matter what order you do the multiplication and division, but a*b/c*d/e*f/g would need several.
quote:It's a difference in round off error for floating point numbers.
Are these modern processors? There were known floating-point bugs in some older CPUs, years ago, but I'd be astonished if this were still happening. Do you have examples?
Posts: 37449 | Registered: May 1999
| IP: Logged |
quote:It's a difference in round off error for floating point numbers.
Are these modern processors? There were known floating-point bugs in some older CPUs, years ago, but I'd be astonished if this were still happening. Do you have examples?
Yes, these are modern processors. Round-off error is machine dependent. I'm not sure exactly why a/2 gives a very slightly different answer than 0.5*a, but it does, at least on some current machines. Like I said before, the difference normally occurs out at the 15th or 16th decimal place using double precision floating point representation.
Posts: 12591 | Registered: Jan 2000
| IP: Logged |
posted
There could conceivably be a difference in the result between a 32-bit vs 64-bit processor, depending on how floating point values are stored. For instance, 0.1 in IEEE-754 binary:
While still rounded (note the repeating pattern of "1100" at the end), the 64-bit version does have more precision. This could result in a different result in a 64-bit calculation vs a 32-bit calculation. Though I doubt processor differences alone would account for this. I think you'd also need a 64-bit OS and 64-bit version of the application in question.
Posts: 3275 | Registered: May 2007
| IP: Logged |
posted
Yeah, Matt, I think you're right. ".5" is a decimal value, and is stored differently than the integer value "2". On a 32-bit processor, this difference could conceivably manifest itself in a visible way.
Posts: 37449 | Registered: May 1999
| IP: Logged |
posted
I agree with Porter's analysis; none was significantly easier or harder to find the missing parenthesis using a tool that matches opening and closing brackets (in my case, the built-in Matlab editor).
As far as readability, I think #6 is the best balance between use and overuse of parentheses. Although again, I would never write any of those equations; I would separate it into much smaller chunks. In this case, if I were writing the formula you provided, I would do it as:
f1 = (1-1/r); f2 = (c1-2*c2+c3)/(dr^2); f3 = 2/r*(c3-c2)/(2*dr); f4 = k*(a*r-b)*c2; y = D*f1*(f2+f3)+f4;
although with variables renamed to provide significance.
Posts: 2926 | Registered: Sep 2005
| IP: Logged |
quote:It's a difference in round off error for floating point numbers.
Are these modern processors? There were known floating-point bugs in some older CPUs, years ago, but I'd be astonished if this were still happening. Do you have examples?
Sidenote: Did you play Mass Effect 2?
Posts: 15421 | Registered: Aug 2005
| IP: Logged |
Both values can be expressed with perfect precision in binary (look at that nice trail of 0s) so what's probably happening is that a rounding error is being introduced by another term in the expression which is amplified/preserved more by one of these values than the other.
Still, .5 is extremely similar to 2 in binary (just a small difference in the exponent (1 for the value of 2, -1 for the value of .5) so I'm surprised this difference is sufficient to manifest in different results often enough to notice it.
Posts: 3275 | Registered: May 2007
| IP: Logged |
quote:Originally posted by mr_porteiro_head: The 2 is likely being stored as an integer, not in binary floating point.
While I can see that being possible, it would actually be irrelevant to the evaluation of an expression. When the expression is actually evaluated, any integer values would need to be promoted to floating point values so the binary floating point value would come into play then.
Posts: 3275 | Registered: May 2007
| IP: Logged |
posted
I am making some assumptions about the software in question using standard floating point conventions. If MATLAB, for instance, has built some exotic proprietary floating point library then all bets are off.
Posts: 3275 | Registered: May 2007
| IP: Logged |
Printer-friendly view of this topic
![[Smile]](smile.gif)
![[Big Grin]](biggrin.gif)
). Find the error and post your corrected version. Please rank them in terms of how hard it was to find the error. Please report any software you used to help parse the formulas.
