[RESOLVED] CAUTION: When Multiplying Versus Dividing

[vb6forever]

I was taught (rightly or wrongly) that output is faster if one multiplies versus divides.
However, take caution, as the result may Not be what you expect. The number of significant digits matter when multiplying.

Private Sub Form_Load()

    Dim a As Double
    Dim b As Double
    Dim c As Double
    Dim d As Double
    Dim e As Double
    Dim f As Double

    'divide
    a = 5617.41 / 3

    'multiply
    b = 5617.41 * 0.33
    c = 5617.41 * 0.333
    d = 5617.41 * 0.3333
    e = 5617.41 * 0.33333
    f = 5617.41 * 0.333333

    Debug.Print a, b, c, d, e, f

End Sub

'Print Result
'Divide
a = 1872.47

'Multiply
b = 1853.7453
c = 1870.59753
d = 1872.282753
e = 1872.4512753
f = 1872.46812753

[Elroy]

haha, well sure it does.

0.33 is only a very rough approximation of 1#/3#. So, when we multiply by 0.33, we're only doing a rough estimate of what N/3# will be, as shown by your example.

IEEE Double Precision (aka, VB6 Double) has 15 or 16 base-10 digits of precision. So, if you want to use multiplication to divide by three, you should be using:

0.333333333333333

... thereby maxing out your precision.

[OptionBase1]

This of course isn't limited to VB6, or to multiplication for that matter.

[vb6forever]

Thought it was worth a post, as I just got caught (e.g. post #1) mulitplying using a hand calculator.

[Shaggy Hiker]

How old are you? Multiplication was (and may still be) faster, especially for integer operations up through the 486. Once floating point units got included on all CPUs, multiplication might still have been a bit faster than division for floating point values, and were a bit faster than division...but it's all irrelevant by now. That level of optimization mostly mattered back in the 90s and earlier. The difference is only a number of clock ticks per instruction. Prior to the advances that showed up with the Pentium, stuff like that could matter if you wanted to squeeze every last cycle out of the CPU. These days, with branch prediction, pre-fetch, multiple pipes, multiple cores, and other hardware improvements, even bothering with a change like this is nuts. I doubt you can even say which is faster anymore. You'd have to understand the context of the exact multiplication and exact division if you want to figure out which individual operation in each individual situation is faster.

It used to be, "this instruction takes N cycles." Now, it's more a case of, "this instruction can take this range of cycles, including zero, depending on where in the code it is located."

[dday9]

Shaggy and his blatant ageism. Pay not attention to Shaggy, he is clearly a 20 year old junior dev

---

Only joking in case that wasn't obvious.

Shaggy's right. While technically speaking multiplication is less complex, the amount of gain you'd get (if any) is absolutely trivial.

[OptionBase1]

Thought it was worth a post, as I just got caught (e.g. post #1) mulitplying using a hand calculator.

It's a good reminder. It's also why there's a concept of significant digits (the bane of high school physics students) when performing calculations involving imprecise measurements.

[vb6forever]

Shaggy Hiker:

How old are you?

Older than dirt. I started programming in 1969 on a CDC 6400.

[Shaggy Hiker]

Yeah, that makes sense. I didn't start quite that early, as I was only 2, and didn't do any programming until I was perhaps 11 or 12. Still, it does make sense. Your information was valid for decades, but is no longer valid. The timing of multiplication and division is now too complicated a subject for there to be able to state that one is faster than the other. At best, you can say that on average, multiplication will be marginally faster than division, but in the performance of each is so situational that they appear as a normal distribution, where the curves for each closely, though not perfectly, overlap.