Modulo Arithmetic in VB6?

[victoryhighway2]

Hello,
I'm working on an application that requires modulo-32 bit arithmetic to compute a value in an equation similar to the following:

x = ((a * b) / c) + d

This looks simple on the surface, but even if I define X as a long, it will always overflow (because VB will try to perform standard arithmetic operations and can't store the result in a 32-bit signed integer.)

How can I get VB to perform this computation using modulo-32 bit operations? I've done numerous searches on Google and can't find any information.

Thanks in advance,
Geoffrey

 

[dilettante]

Do you mean 32-bit unsigned arithmetic or something else? I've heard of 32-bit arithemtic, and modulo 32 arithmetic... but never "modulo 32-bit" arithmetic.

You might find How To Convert Between Signed and Unsigned Numbers a good start if you're trying to do unsigned arithmetic in VB.

 

[victoryhighway2]

Hi dilettante,
You may be correct in calling it modulo 32 arithmetic. However, I'm just following a spec that plainly states:

All computations are performed on unsigned 32-bit variables using modulo-32-bit operations.

Regards,
Geoffrey

 

[dilettante]

Nope. Mod 32 is something entirely different. I suspect it's a misstatement or typo.

Sounds as if they want unsigned 32-bit arithmetic done though. Is this class work? Might try another teacher. ;-)

 

[victoryhighway2]

Hi Dilettante,
No, this isn't for a class. This is for my work.
I'll just talk to the engineer who wrote up the spec when he comes in. Maybe he'll be able to give me some advice.

Regards,
Geoffrey

 

[dilettante]

Clarity is everything. I'd sure check first.

 

[tsh73]

>>but even if I define X as a long, it will always overflow (because VB will try to perform standard arithmetic operations and can't store the result in a 32-bit signed integer.)

I guess you should have all other variables in the expression to be long, too.

 

[victoryhighway2]

Hello all,
I've gotten some clarification on this. Apparently, this calculation is to be performed as modular arithmetic operating on 32 bit unsigned integers. The result value is expected to overflow.

Obviously, since VB doesn't support any unsigned integer data types larger than 1 byte, we will need to use doubles to store our results. However, the bounds of a double are not the same as a UINT32, we'll need to do some kind of work around to get the overflow to occur at the correct point.

I've looked at a code sample from the other engineer. It is extremely straight-forward and it looks like his C compiler is handling the overflow by just allowing it to happen (ie. performing the modular arithmetic automatically) whereas VB throws an exception.

Regards,
Geoffrey

 

[strongm]

Indeed. VB doesn't natively handle unsigned maths particularly well. It is perhaps the wrong language to choose if you are doing a lot of unsigned arithmetic.

 

[harebrain]

Google on the terms "long integer modular arithmetic vb" and you'll get more results than you can use.

 

[Hypetia]

>it looks like his C compiler is handling the overflow by just allowing it to happen ... whereas VB throws an exception

I don't know your exact requirements, but you can also instruct VB to ignore overflow by setting advanced compiler options.

Start a new project, and try running the following code.
___
[tt]
Private Sub Form_Load()
Dim L As Long
L = 12345678
L = L * L
MsgBox L
Unload Me
End Sub[/tt]
___

The assignment L = L * L throws an overflow error in IDE because the result is obviously much too larger than the capacity of a VB Long.

Now go to advanced compiler options in project properties and select the option "Remove Integer Overflow Checks".

Compile an EXE and see the results in compiled version. The program runs without an error displaying 260846532. Reason for this result is this:

12345678 * 12345678 = 152415765279684 = 0x8A9F0F8C33C4

Since the overflow check is disabled, VB ignores the fact that an overflow has occurred in multiplication and retains the value in the lower 4 bytes, i.e. 0x0F8C33C4 = 260846532, which is reported by the message box.

 

[BobRodes]

Which is great if it's what's intended, and very very bad when it isn't.