Re: Bit-order reversal (little-endian <--> big-endian)
- From: "David J Mark" <nntp45534-22@xxxxxxxxxxxx>
- Date: Sun, 01 Jan 2006 02:43:53 GMT
"Michael C" <nospam@xxxxxxxxxx> wrote in message
news:e87JmrcDGHA.1088@xxxxxxxxxxxxxxxxxxxxxxx
> "David J Mark" <nntp45534-22@xxxxxxxxxxxx> wrote in message
> news:IVbtf.92256$lh.78947@xxxxxxxxxxxxxxxxxxxxxxxxx
>> Ultimately, my design is faster (all things equal) as it avoids extra
>> iterations. There's really no arguing that.
>
> Your rewritten code might well be faster but I was commenting that your
> original code was grossly inefficient. You've optimised it with all my
Er. You invented this tautology:
X MOD 2 = X AND 1
This reminds me of the guy who tried to rename indentation of for next loops
the "mope maneuver" or something like that.
And as I stated (sigh), the IIF is a moot point.
> suggestions and said "no, mines faster". Well duh. Notice that the code I
> had before your post has remained unchanged and you've just now managed to
> get yours to be a little faster *if* you pass in data to give it
> favourable results.
Er no. Mine is considerably faster because the algorithm is superior. Your
whole argument exists to show off your knowledge of the VB compiler. It has
nothing to do with designing a competent function.
>
>> It turns out that I was right. I can't say that I am shocked. Here is
>> my final revision.
>
> You have got to be kidding me!! I pointed out your original code was
> grossly inefficent which was totally and utterly correct. I never said
> your code couldn't be optimised to be faster, in fact I was suggesting it
> should be optimised.
To what end? You offered no solutions but the above-mentioned truism that
was surely known to the ancient Greeks.
>
> It's kind of ironic really if you look over the thread I pointed out how
> inefficient your code was, how much it could be improved by optimisation
> and even pointed out each optimisation. You implemented all those
> optimisations (with my help along the way), got *massive* improvements in
> speed, basically proving my point and somehow claim I'm wrong.
You are a broken record. Your help? Oh brother. Again, have a look at the
from field. The thread was not about compiler optimizations until you poked
your nose in. As I have shown, your design is lame and no amount of
optimizations can make it catch up with mine.
>
>> All of this other stuff about IIF is interesting and all, but it is the
>> design that should be considered first. Optimization of individual lines
>> of code is an afterthought.
>
> No way! Optimisations as simple as this should be done when you first
> write the code. For example I remember finding out that "If Len(MyString)
> = 0" is faster than "If MyString = """ so I always use Len *first* time.
> If I want
Not with example code. Lets face it. You just wanted to steer this
discussion into compiler optimization because you think it makes you sound
intelligent. This thread was about a mathematical problem.
> to use IIF I always use a function I've defined myself as it's 50 times
> faster. Sure you don't go too far out of your way first time but you
> certainly don't abandon any thought of it.
>
> The code I wrote for this thread took a few minutes to write and was
> extremely fast *first time* but I didn't spend a huge amount of time on
> optimisation, I just took it into account from the start. You've optimised
> yours several times and have basically come down to what I wrote in the
> first 5 minutes.
This is not a contest. And again, the fact that the tacked on IIF was
inefficient was never a salient point. Over and over again, your message
is: I'm better than David Mark.
>
>> So take my design, optimize the last line and you have a perfect
>> solution. If you start with your solution, you can't get there (unless
>> you change your loop to look like mine.)
>> Public Function ReverseBits8(ByVal lX As Long) As Long
>> Dim lMultiplier As Long
>>
>> lMultiplier = 256&
>> Do
>> ReverseBits8 = (ReverseBits8 * 2&) Or (lX And 1&)
>> lX = lX \ 2&
>> lMultiplier = lMultiplier \ 2&
>> Loop While lX > 0&
>> ReverseBits8 = ReverseBits8 * lMultiplier
>> End Function
>
> Sure I could have hard coded mine to 8 bits also and made the same
I knew you would say that. Yours hard-coded with extra bits will still loop
extra times. Basically, your algorithm stinks and no amount of squirming
after the fact is going to make it any better.
> assumption but I don't see how you'd eliminate the loop with the bits
> passed in as a variable, which was what the op requested. For what it's
> worth the one optimisation you've made to what is basically my code above
> is a good idea.
>
> Public Function BitReverse (BitCount as long, DataBits as long) as long
>
>> Oh and I didn't learn about the & suffix from you.
>
> I never said you did however you still don't understand it's use if you
> think putting it inside an IIF or power function is going to help optimise
> your code.
>
>> From field on my messages? If you didn't, I am David Mark. Enough said?
>
> I've never heard of you.
That means you are a greenhorn. Somehow I guessed as much. Put in another
decade or so and then come talk to me. Or better yet, don't.
Anyway, I won't be around to argue in here again until late next week. Find
somebody else to "teach" about boolean arithmetic. Or just blather on about
it endlessly to nobody in particular. Or do something useful and write a
post about how to design a proper dialog. Now THAT would be a welcome
discussion here.
.
- Follow-Ups:
- Re: Bit-order reversal (little-endian <--> big-endian)
- From: Michael C
- Re: Bit-order reversal (little-endian <--> big-endian)
- Prev by Date: Finding Color of Specific Pixel in Loaded Image
- Next by Date: Re: Bit-order reversal (little-endian <--> big-endian)
- Previous by thread: Finding Color of Specific Pixel in Loaded Image
- Next by thread: Re: Bit-order reversal (little-endian <--> big-endian)
- Index(es):
Relevant Pages
|
Loading
