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.

  • $\begingroup$ $5$ inputs with $10$ steps is $10^5$ combinations. $\endgroup$ – Steven May 29 '20 at 17:04
  • $\begingroup$ You're right! Its 100,000 combinations and not 9.8 million. Unfortunately that's still too expensive to eagerly calculate for me so the intent of the question still stands. $\endgroup$ – Anubhav May 29 '20 at 17:17
  • $\begingroup$ It's a bit hard to answer this question without knowing more details about the specific problem. Also this problem is really in topic here if there is some theoretical issue behind it (i.e., it doesn't just boil down to implementation technique/engineering trick to speed things up). Are you sure the result can't be computed on the client when it is needed? If it is too slow, can you come up with a data structure that possibly takes a long time to compute but it is compact an then can quickly report a solution to your problem given the sliders? $\endgroup$ – Steven May 29 '20 at 17:46
  • 1
    $\begingroup$ @Anubhav All you need to do is to compute about 10 combinations. A user can only drag one slider at a time. When the user switches to another slider, try responding within a fraction of a second. $\endgroup$ – John L. May 29 '20 at 18:17
  • $\begingroup$ @JohnL. Not sure if I follow you. While a user can move only one slider at a time, they can set multiple sliders to non-default values? So for e.g. we start with all sliders at position. Then the user moves slider A to position 2 and slider B to position 3. Are you suggesting calculating a "smaller subset" of possible solutions each time the user moves only one slider? $\endgroup$ – Anubhav May 29 '20 at 18:22

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.