>>>>
>>>>Ok, I got it! But why not simply:
>>>>
>>>>bitand(lnRight, 0x7f)*256 + lnLeft
>>>>
>>>>Vlad
>>>
>>>Traditionally, a low level bitshift is Much faster than multiplication by a floating point value. But since this is foxpro, and we are actualling calling functions, the performance gains are probably lost. The readability is also reduced using my technique whereas in C++ it would be:
>>>
>>>unsigned char lcShort[2];
>>>short x;
>>>// ...
>>>x = ((lcShort[1] & 0x7f) << 8) | lcShort[0]);
>>>x = (lcShort[1] & 0x80) ? (-x) : (x);
>>>which would be thousands of times faster than the equivalent FoxPro and tens of times faster than the equivalent C++ using multiplies instead of bit operations.
>>>
>>>Of course in C++, the initial reason we had to unpack a short becomes moot :-)
>>>
>>>Peter
>>
>>Peter & Vlad,
>>
>>I assumed that using BITOR() would be faster than addition, however, when I ran a series of tests the opposite turned out to be true. The only reason that made any sense to me would be that the mathematical operations are handled by the internal math coprocessor, while this type of operation would be handled by the main. While I haven't tested shift (VFP's) vs. multiplication, it wouldn't surprise me in the least if the same doesn't apply.
>>
>>George
>
>I also did some tests last night and ... I can obtain now whatever results I want. I can "prove" that either of them is faster than the other! :) It's really weird, so, I'll look more.
>
>Vlad

All I did was to set up two FOR...ENDFOR loops, one that continually ORed the same numbers, and one that added them. By using the same literal values, and having no other code, I felt that it was the truest indicator of actual performance I could find. Any ideas on this?

George