Ever heard of casting?
-
chevu wrote:
This one is correct code
wrong again: 1. the result for pow=18 is wrong. 2. pow=5 and pow=6 give the same result??? I think you have abundantly proven now that your code has high debugging complexity. :(
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
sorry dude... i had really forget to check till 18... coz of odd even cases that code will fail... I knw you people are getting irritated by now, but you can check this code
double pow(long long a, long long b)
{
if(b == 0)
return 1.0;
else if(b == 1)
return a;
else if(b%2 == 0)
return pow(a*a,b/2);
else
return a* pow(a*a,b/2);
}i have tested this code upto long long limits...
-
sorry dude... i had really forget to check till 18... coz of odd even cases that code will fail... I knw you people are getting irritated by now, but you can check this code
double pow(long long a, long long b)
{
if(b == 0)
return 1.0;
else if(b == 1)
return a;
else if(b%2 == 0)
return pow(a*a,b/2);
else
return a* pow(a*a,b/2);
}i have tested this code upto long long limits...
Recursive functions brings color in life :-D
I have no smart signature yet...
-
sorry dude... i had really forget to check till 18... coz of odd even cases that code will fail... I knw you people are getting irritated by now, but you can check this code
double pow(long long a, long long b)
{
if(b == 0)
return 1.0;
else if(b == 1)
return a;
else if(b%2 == 0)
return pow(a*a,b/2);
else
return a* pow(a*a,b/2);
}i have tested this code upto long long limits...
-
chevu wrote:
long long a
If I were a canadian, thats how I would describe this thread.
modified on Thursday, March 4, 2010 8:11 AM
-
chevu wrote:
how can you say algo i gave takes more time to debug.. complexity of given algo is O(n)
O(n) and O(lg(n)) apply to execution time, not debugging time. There are no formulas for debugging time; it depends on number of statements, decision points, readability of code, and initial number of bugs. Your code has more than 5 bugs, it will take you lots of time to find all of them. I suggest you try and fix and run it until the result is correct. :|
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
thank you for answering to chevu - he didn't get the hint - "debug time" :rose:
-
sorry i messed up with code... This one is correct code
decimal res = 10;
decimal multi = 10;
decimal rem = 1;
int pow = 18;//For pow 0 you can directly return with 0while(pow > 1)
{
res *= res;
rem *= (pow%2)? multi:1;
pow /= 2;
}
res *= rem;Here's how:
static decimal pow(decimal x, **u**int n) { decimal result = 1; while (n > 0) { if ((n & 1) == 1) { result \*= x; } n >>= 1; if (n == 0) break; //not nice, but needed in case x\*x overflow on the last step x \*= x; } return result; }Good luck! ok so it's not the best possible code, I just hacked it together, but it works (tested)
modified on Friday, March 5, 2010 11:40 AM
-
Here's how:
static decimal pow(decimal x, **u**int n) { decimal result = 1; while (n > 0) { if ((n & 1) == 1) { result \*= x; } n >>= 1; if (n == 0) break; //not nice, but needed in case x\*x overflow on the last step x \*= x; } return result; }Good luck! ok so it's not the best possible code, I just hacked it together, but it works (tested)
modified on Friday, March 5, 2010 11:40 AM
harold aptroot wrote:
(tested)
that is unacceptable. This is the Coding Horrors forum after all. You're expected to publish something that is completely wrong, yet claim it is correct. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
harold aptroot wrote:
(tested)
that is unacceptable. This is the Coding Horrors forum after all. You're expected to publish something that is completely wrong, yet claim it is correct. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
No problem. Anyway, it fails for negative n. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
No problem. Anyway, it fails for negative n. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
I didn't see any specs; you could have tested and thrown an InvalidArgumentException; or made the second parameter a uint. [EDIT]Negative exponents result in divisions, which for integers tend to yield either 0 or 1 depending on the value of a.[/EDIT] :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
I didn't see any specs; you could have tested and thrown an InvalidArgumentException; or made the second parameter a uint. [EDIT]Negative exponents result in divisions, which for integers tend to yield either 0 or 1 depending on the value of a.[/EDIT] :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that.
-
This is an excerpt from some sample code provided in the documentation for an EFT interface
decimal divider;
// we need 10^18, but Math.Pow does not support decimal
// types and decimal does not provide a power function
divider = 10*10*10;
divider = Decimal.Multiply(divider,10*10*10*10*10);
divider = Decimal.Multiply(divider,10*10*10*10*10);
divider = Decimal.Multiply(divider,10*10*10*10*10);Blows my mind :-)
Not sure a cast is the best approach here - decimal types are OK for currency and other situations where accuracy is critical. Floating point types can introduce rounding errors - it all depends how the value is used. Best solution I've seen in the comments is 1E18M, but really 1E19M may be better ;-)
-
Not sure a cast is the best approach here - decimal types are OK for currency and other situations where accuracy is critical. Floating point types can introduce rounding errors - it all depends how the value is used. Best solution I've seen in the comments is 1E18M, but really 1E19M may be better ;-)
Yes! I'm sorry I could only give you one five. When the problem domain calls for decimal calculations rather than floating point, casting from a floating point type would be a greater horror.
Please do not read this signature.