|
And for sqrt(-1/64) do we get indigestion tablets?
|
|
|
|
|
ASkoro wrote:
And for sqrt(-2)????
Computers ignore complexity. Or is that irrationality? I'm almost sure that's a complex number. If that is true, what is an irrational number? I know they both exist, but can't definitively define them.
|
|
|
|
|
I just tried your method, and my compiler is generating a error about a method must return a value, so I fixed it.
There is a version without bugs, hope it helps:
if (i < 0)
return 1 - abs(i);
else if (i == 0)
return 1;
else if (i > 0)
return 1 + abs(i);
|
|
|
|
|
Sorry, I fail to see how you fixed it. Computers aren't very good at determining there is an unreachable path. Put an unconditional return 1 - abs(i) + abs(i); after all the if statements should fix it. (Especially if i is uint. Checking for negative numbers is really interesting in that case.)
|
|
|
|
|
Came across this piece of solid-gold coding in Android the other day, in good old SurfaceFlinger.cpp:
if (mCurrentState.orientation != orientation) {
if (uint32_t(orientation)<=eOrientation270 || orientation==42) {
mCurrentState.orientationType = flags;
mCurrentState.orientation = orientation;
setTransactionFlags(eTransactionNeeded);
mTransactionCV.wait(mStateLock);
} else {
orientation = BAD_VALUE;
}
}
Sometimes I just don't know what to think any more. 
+++DIVIDE BY CUCUMBER ERROR+++
|
|
|
|
|
Well, just hold your phone at 42 degrees .
And also, there were worse f'ups: (Steve Jobs "Don't hold it that way", anyone?) Actually, there were none 
|
|
|
|
|
Guess the author is afraid of "AddWithZeroException" 
|
|
|
|
|
I a very humble opinion, I think the original developer cared about performance.
There is a big and ugly monster living in or closes that will eat us if we write less performing code.
The problem is, that almost all developers don't understand about performance and do wrong things.
Here, I think he/she are trying to avoid a sum using a comparison. In some cases, like division, it will be a great code.
|
|
|
|
|
For the sake of learning here, why do some of the examples use the abs function in their answers. Why not just i++?
|
|
|
|
|
Rewritten:
return (i == 0) ? 1 : i++;
In division, specifically in the denominator, this code eliminates the divide by zero issue. I think the OP (original programmer) had good intentions.
|
|
|
|
|
Bug Alert. I think you meant perhaps:
return (i == 0) ? 1 : ++i;
|
|
|
|
|
Why not use i++? Obfuscation. The original coder was trying to obfuscate it by using an if statement, so people are running with that theme 
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
MehGerbil wrote: Why not just i++?
For one thing that would be the same as returning i. (Unless the i was passed with ref. Then you get two values for the price of one.)
MehGerbil wrote: For the sake of learning here
That's rich. Trying to learn better coding by studying poor code harder.
|
|
|
|
|
The intent was to write: return i++;
KP Lee wrote: That's rich. Trying to learn better coding by studying poor code harder.
I think fixing bad code is a great way to learn, especially if you learn the "why" along the way.
|
|
|
|
|
It should be 'return i + 1'. ++i is a wasteful update of the variable i, assuming it's local (there's some serious issues if it isn't anyway), and i++ is just wrong because it returns i (before the statement) and not i + 1.
|
|
|
|
|
That was interesting.
Why is it that ++i is less efficient then returning i + 1?
Isn't a calculation made (total of i + 1) made in memory somewhere regardless?
|
|
|
|
|
It's likely that compiler optimisations make it irrelevant in this case. But in the general case, she using ++i the value is copied into i after being calculated, then copied into the return variable. Using i+1 only copies it to the return variable (one less copy).
|
|
|
|
|
Interesting.
Thank you for the informative response.
|
|
|
|
|
I'm not surprised, see it all the time. This happens as a result of changing the condition, i.e. the code was written for one condition, then the condition changed, and the code was updated without logical refactoring.
Also, some developers like making code temporarily unreachable rather than commenting it out, i.e. putting the code into a block like:
if(false){...code...}
|
|
|
|
|
Developer took special math classes...
|
|
|
|
|
Almost 12 years ago (before I joined the company ), this little beauty almost made it into the release build of one of our applications:
CString strTimeZone;
timeb timeptr;
ftime(&timeptr);
long TimeZone = (long)timeptr.timezone/(long)60;
switch(TimeZone)
{
case 8:
strTimeZone = "P";
break;
case 7:
strTimeZone = "M";
break;
case 6:
strTimeZone = "C";
break;
case 5:
strTimeZone = "E";
break;
default:
AfxMessageBox("Invalid TimeZone. Please Move.");
}
Soren Madsen
|
|
|
|
|
It's not a horror - at least he checked - but it's not that helpful an error message, I must admit. However, it does give advice on how to solve the problem which is a vast improvement on most MS error messages of 12 years ago!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
You are a true the-glass-is-half-full guy
Soren Madsen
|
|
|
|
|
I think that serves people right for living in invalid timezones!
I'm glad someone was finally willing to tell them 
I'm pretty sure the programmer was thinking of timezones such as GMT+4,35 and GMT-27
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
I wanted to share this, so I actually went to find it in our old SourceSafe database. I deleted a few lines of code that really did nothing, so what you see is what it did.
Today in its place, the code formats a date/time with abbreviated time zone and Daylight saving information - getting the TZ abbreviation right is still a hit and miss (when TZ is outside the US), but at least you don't have to move
Soren Madsen
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
