2

I am building an app where a user controls inputs via multiple sliders each with discrete steps. The app then uses the combination of slider values to run some calculations and returns back an output value.

The sliders are meant to be highly responsive, so the user can immediately see the impact of their input combination on the output value -so I have resorted to eagerly calculating ALL possible combinations of sliders and letting the client query the results in the browser itself for faster response times.

The problem is that the number of possible combinations can seriously explode. If I have 6 inputs each with 10 steps, that is 10^6 = a million possible combinations! That's way too expensive to calculate eagerly.

Is there a better way to do this? I could try to restrict the number of sliders that can be moved at any point, to lower the solution space...but wondering if there's a better solution out there.

Anubhav
  • 121
  • 2

1 Answers1

2

I like John L's suggestion. Have the app compute the view for the current position of all sliders. Also, for each of the 6 other sliders, for each other 9 positions of that slider, precompute the view obtained from that. In other words, you precompute all views that can be obtained by changing the position of a single slider. That involves precomputing 6*9 = 54 other views. Now, when the user clicks on a slider and changes its position, you'll be able to immediately display that view, and you can start precomputing 54 more views (for all combinations of changing one other slider to a different position). As long as you can compute 54 views in the it takes for a user to move their mouse from one slider to another, you'll be able to keep up in a responsive way.

D.W.
  • 167,959
  • 22
  • 232
  • 500