# Is multiplying by Ts faster than dividing by fs? [closed]

Say fs = 1000 and Ts = 0.001. Would it be faster to compute Ts at the beginning and subsequently multiply by 0.001 instead of dividing by 1000 when computing frequency-dependent quantities?

• This isn't really a signal-processing question per se; the answer to your question is going to depend on the characteristics of the computing platform you're using. In general, yes, multiplication is usually faster and less hardware-intensive than division. – Jason R Mar 11 at 14:20
• Thank you and sorry for posting in the wrong forum – neolith Mar 11 at 14:24
• Yes. For most platforms it's faster to multiply then to divide – Hilmar Mar 11 at 15:01
• Presumably you're using the $T_s$ to scale coefficients. If your sampling rate is fixed, it's faster to precompute your scaled coefficients. I.e., in your code don't use T_s * k_i * error; use k_i * error with k_i appropriately scaled. – TimWescott Mar 11 at 20:51
• Isn't that something that one could easily test with two loops? – M529 Mar 13 at 13:41

Generally, it makes sense to ensure that your code is logically correct, that it is numerically well-behaved, intuitive to read and tested. That is hard enough. Only when you observe that some innerloop or library call is a real hotspot, affecting the functionality of your software does it make sense to rewrite code for speed, and then you should always profile before and after.

If a constant is known compile time, the compiler may apply the inversion to substitute division for multiplication, if this is within precision constraints and runs faster for a given target. If ppssible, I would rather outsource that complexity to the compiler.

Edit:

It is not "technically the same operation". To see why, have a look at this MATLAB snippet:

a = single(10.0)
b = 1/a
c = 42/a
d = 42*b

c-d

ans =

single

-4.7684e-07


Since floating-point is operating with finite precision and intermediate rounding, the order of operations does matter. Depending on compiler flags, the compiler may be allowed to re-order floatingpoint arithmetic even though the result will differ to some degree.

If we look at the binary representation we see that they differ in the lsb:

dec2bin(typecast(c,'uint32'),32)
dec2bin(typecast(d,'uint32'),32)

ans = '01000000100001100110011001100110'
ans = '01000000100001100110011001100111'


-k

• You pointed out something important: It depends on the compiler. Since it is technically the same operation, a good compiler would choose the best way of accomplishing it. – neolith Mar 13 at 14:20
• See edits in my answer – Knut Inge Mar 16 at 20:27
• Thank you for pointing that out – neolith Mar 16 at 22:59