Partial Scaling – How to do Half a Multiplication

by Malte Skarupke

Programmers have a habit of over-generalizing things, and so it happened that I found myself writing more generalized versions of rotation, translation and scaling, the three most common operations that you’d want to do to 3D objects. These were more generalized in that they had a parameter for how much you want to do a certain operation. Like “translate by (10, 0, 0), but only apply the operation 20%”. This is easy to do for translation: Just multiply by the percentage and only translate by (2, 0, 0). Rotations are also easy in many representations: If the angles are explicit, like in Euler angles, you can just multiply those by the percentage; if you’re using quaternions, you can slerp.

But scaling is more complicated. Internally scaling is just multiplication, but how do you do half a multiplication? What does it mean to say “multiply by 4, but only apply the operation 50%”? My first approach was to multiply by the power, so you’d get “multiply by $4^{0.5}=2$ ” (or $4^{0.1}$ if you only want to apply 10% of the operation) and that seems to work when you’re close to 1, but the further away you are from 1, the more wrong it gets. The answer ends up being to take the median of multiplication, division and exponentiation, but let me further explain the problem first:

It turns out that multiplying by $x^{0.5}$ answers the question “which operation do I have to apply twice to multiply by $x$ ?” Which is almost right, but not what I needed. I needed to answer the question “which operation has half the effect of multiplying by $x$ ?” To illustrate how this goes more wrong the further you are removed from 1, lets say you want to scale by 100, but only apply the operation 50%. Then you would expect the object to roughly be half as big as if you had scaled by 100. So you want to scale by 50. But $100^{0.5}$ is 10, so the object ends up five times too small.

On the other end of the scale you get the same problem when you’re close to 0. If you’re shrinking the object by factor 100, multiplying by $0.01^{0.5}$ would shrink it by factor 10. But if you apply half the operation, you expect it to be roughly twice as big as the full operation, so instead you want to scale by 0.02, and the exponentiation ends up making the object five times too big.

If this doesn’t convince you yet, try bigger values or different percentages. Like scaling by factor 1000, but only applying the operation 90% results in a scale of $1000^{0.9}=501$ . Now put an object that was scaled by 90% next to an object that was scaled 100% and it will be very unexpected that one of them is twice as big as the other.

After writing down a bunch of cases and writing down all the expected behavior, I realized that there are three possible behaviors. If the original multiplication is $a*x$ , and the parameter that controls the strength of the operation is named $t$ you get these three cases:

Close to 0 you want to do $a*x/t$
Close to 1 you want to do $a*x^t$
For large numbers you want to do $a*x*t$

This was easy to figure out for extreme values far from 1, but it leaves open the question of where to transition from one behavior to the other. This can get really complicated to figure out for all combinations of $a$ , $x$ and $t$ . But luckily it turns out that if you do the median of these three operations, you always get exactly the expected behavior. One of these is always too big, one is always too small, and the one in the middle is always exactly right. That results in surprisingly elegant code where you never have to figure out the transition point. Just calculate all three and then write a small function that returns the median of three.

There is one detail that you have to look out for: In order to support a $t$ value of 0 (which just returns $a$ unchanged) you have to handle the case where the division returns NaN. But if you’re aware of that case, you can add a unit test and then your median-of-three function can handle that without overhead, just by doing the comparisons in the right order. (any comparison to NaN returns false, so write the comparisons in an order that ensures the division result won’t be picked when it only returns false)

This isn’t really about the code though. This is just about the realization that

Doing partial scaling is surprisingly tricky. I thought this would be easy because translation and rotation are easy. Scaling seems easy at first because $a*x^t$ is so close to the right answer, and you only realize that it’s wrong when you’re using it for a bunch of cases.
The answer comes out to this weirdly elegant operation: Take the median of division, multiplication and exponentiation. It’s rare that you end up doing something like this. It’s especially unexpected to find this for such a seemingly simple question as “how to do a partial multiplication.”

One elegant thing that I haven’t mentioned yet is that this also seems to handle cases where the $t$ value is bigger than 1. The exponentiation explodes quickly for large $t$ values, but since we use the median, the exponentiation doesn’t get used. And the multiplication and division cases behave pretty well for larger $t$ values.

And a bonus fun-fact: if you’re doing this in log-space (which I was doing at first) this ends up being the median of addition, subtraction and multiplication. Because $log(a)+log(x)=log(a*x)$ and $log(a)-log(x)=log(a/x)$ and $log(a)*x=log(a^x)$ . This is cheaper since you don’t need to calculate the exponent, but it only makes sense if you’re already in log-space. (also watch out for the pattern-break on the last three of those formulas: That one just uses $x$ instead of $log(x))$ .

Also: I tried googling to find if somebody else had already discovered this, but it’s nearly impossible to google for the question of “how to do a half a multiplication.” So I have no idea if I discovered a new mathematical operation or if this is already known. If anyone knows, I would be curious to know how I could have found this without having to reinvent it.

5 Comments to “Partial Scaling – How to do Half a Multiplication”

John Hall says:

July 24, 2020 at 03:33

Why not use LOG(xa,x), where LOG’s second parameter is the base? Or equivalently log(xa)/log(x) or log10(x*a)/log10(x)?

- Malte Skarupke says:
  
  July 24, 2020 at 04:09
  
  For which part? For the part at the end about how if you’re in log space it turns into cheaper operations? For that one I didn’t get to choose which log to take. A different part of the program already did that. So for this part of the problem I got log(a) as input.
  
  Or can you elaborate how it helps to change the base?
  
jobleonard says:

July 26, 2020 at 08:29

Maybe I’m misunderstanding something, but wouldn’t the generic answer to “partially multiply a by x” be

a(1 + (x-1)t)

If we start from the 0% case, then our answer should be a, so we multiply a by 1. The 100% case (or t = 1) should be a*x, so we multiply by x + (x-1) = x.

- Malte Skarupke says:
  
  July 26, 2020 at 13:14
  
  I like that. It works well close to 1 and for large numbers. However it doesn’t seem to work well for numbers close to 0. If x is 0.01 or if x is 0.001, the answer comes out very similar. But you should see something like a 10x difference.
  
  But maybe it’s possible to drop the exponentiation with this. To switch between only two behaviors.
  
  - Cameron says:
    
    June 2, 2022 at 13:26
    
    What jobleonard came up with is really a linear interpolation between the original size and the scaled size, with t being the interpolation factor, and this is how I would expect such a thing to behave if I saw this in a modeling application.
    
    What exactly do you mean by 10x difference? If t is 1 in that situation, x=0.01 would result in the object being 1/100 of its original size, and x=0.001 would result in it being 1/1000 of its original size. That’s a 10x difference.
    
    If you meant t=0.01 vs t=0.001, then the DIFFERENCE in size between original and scaled is a * (s – 1) * t, which is proportional to t. If t is 0.01, the CHANGE in size would be 10 times what it would be if t was 0.001.

Probably Dance