Ever heard of casting?

[Luc Pattyn]

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.

---

[chevu]

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 0

while(pow > 1)
{
res *= res;
rem *= (pow%2)? multi:1;
pow /= 2;
}
res *= rem;

[Luc Pattyn]

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.

---

[chevu]

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...

[Stanciu Vlad]

Recursive functions brings color in life :-D

I have no smart signature yet...

[J4amieC]

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]

what kind of comment was that?

[J4amieC]

Erm, a half-assed joke, you douche.

[johannesnestler]

thank you for answering to chevu - he didn't get the hint - "debug time" :rose:

[Lost User]

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

[Luc Pattyn]

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.

---

[Lost User]

Oops! Sorry :)

[Luc Pattyn]

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.

---

[Lost User]

It's not supposed to work for negative n anyway

[Luc Pattyn]

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.

---

[Lost User]

Is that really necessary..? Fortunately adding just 1 letter of code takes the problem away.

[Rob Grainger]

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 ;-)

[Avi Berger]

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.