A little tiny horror
-
Shift left is way cooler than pow any day. And in the end it's all about how good the code looks, eh? ;)
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
int pow(int i, int j) { switch (j) { default: return 0; case 0: return 1; case 32: i *= i; case 31: i *= i; case 30: i *= i; ... case 1: return i; } }.... ewwwwwTim Smith I'm going to patent thought. I have yet to see any prior art.
(stack madness variant)
int imul(int i, int j)
{
if (j==0 ) return 0;
else return imul(i,j-1) + i;
}int ipow(int i, int j)
{
if (j==0) return 1;
else return imul(ipow(i,j-1) , i);
}:-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
[my articles] -
I found this expression in our current source code:
int i;
//...
(int)pow(2,i)This was in code written by a senior developer :wtf:. I replaced it with the following expression:
(1 << i)
Software Zen:
delete this;Do you work for the same company as me? I've seen someone write code just like that -- to create a bitmask.
-
I found this expression in our current source code:
int i;
//...
(int)pow(2,i)This was in code written by a senior developer :wtf:. I replaced it with the following expression:
(1 << i)
Software Zen:
delete this;But... but... but... this ISN'T VB... Is it possible to have bad code written by a senior developer in a non-VB language??? ;P
-
I found this expression in our current source code:
int i;
//...
(int)pow(2,i)This was in code written by a senior developer :wtf:. I replaced it with the following expression:
(1 << i)
Software Zen:
delete this;Gary Wheeler wrote:
(1 << i)
Moral of the story. Shift happens.
Deja View - the feeling that you've seen this post before.
-
Shift left is way cooler than pow any day. And in the end it's all about how good the code looks, eh? ;)
cheers, Chris Maunder
CodeProject.com : C++ MVP
I'm uncomfortable saying this :sigh: No, it is all about the app meeting the requirements. One of the requirements (too often, only implied) is that the code be readable and maintainable. It may be that << is better looking than pow in some cases, but maybe not. What if that was coding a requirement directly? I would expect any coder worth his salt to understand and translate, but I know too many programmers that are not worth their salt.
I want to die like my Grandfather. Peaceful, Sleeping. Not screaming like his passengers.
-
But... but... but... this ISN'T VB... Is it possible to have bad code written by a senior developer in a non-VB language??? ;P
-
Gary Wheeler wrote:
(1 << i)
Moral of the story. Shift happens.
Deja View - the feeling that you've seen this post before.
<DeepMysteriousVoice> You have become known to us. Your capacity for puns is disturbing... </DeepMysteriousVoice>
Software Zen:
delete this; -
Robert Surtees wrote:
I'm guessing the shift is a wee bit faster.
Which, as was argued here, is very probably of no importance, while the resulting obfuscation of the intent of the calculation is important.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"Based on what he was using this for (constructing a bit string), I would say using the
pow()obscured the intent more than the shift operation did.Software Zen:
delete this; -
<DeepMysteriousVoice> You have become known to us. Your capacity for puns is disturbing... </DeepMysteriousVoice>
Software Zen:
delete this;Gary Wheeler wrote:
You have become known to us. Your capacity for puns is disturbing...
A curse upun you.
Deja View - the feeling that you've seen this post before.
-
Gary Wheeler wrote:
You have become known to us. Your capacity for puns is disturbing...
A curse upun you.
Deja View - the feeling that you've seen this post before.
-
Can you guarantee that floating point inaccuracies + truncation in the cast doesn't introduce a problem? A quick check shows they don't on VC8, but I wouldn#t have bet on it. Further, if your compiler uses the canonical (if simplistic) implementation of
double pow_simple(double x, double y) { return exp(y*log(x)); }you fail pretty quickly with pow(2,3) = 7.9999999999999982 To add a pitfall to a lurking bug: if you use the default %f specifier for that, it dutifully prints 8.000000, but truncates it to 7 when casting to int. Also, when using 64-bit integers, starting with pow(2,51) double loses on accuracy.We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!| FoldWithUs! | sighistThat is the first thing I thought of when I saw this. The thought of converting floating point to integers using casts keeps me awake at night. I am actually currently working on a project at work that has a few of these. I just started here at the time I noticed them. For fun, I thought it would be neat to try compiling this project (which was developed in VC++ 6.0) with VC 2005, and VC 2005 choked on these instances. Good job to the compiler team on that one. It also choked on a few things that I thought VC++ 6.0 should have, such as assigning an int literal to a CString. A few more bonus points to the team there, although 6.0 definitely should have caught that. Of the pow(int,int)s, at least one could've used the x *= 2 form, as it was in a loop, and the others the shift form. In the end, I decided not to touch any of them, because for all I know the truncation does mess things up but somebody spent a bunch of hours putting in "fixes" to work around this. The routines in question don't seem to have any bugs for now, but since a lot of the other ones do, I decided to focus my energy on those.
