# Thread: Formula from table with operation restrictions

1. ## Formula from table with operation restrictions

It has been suggested to me this forum might be the right place for the following; please move this thread if it's not. If you remember this thread looking like a previous of mine, although most of the question is the same, the difference in col3 makes it about a completly other subject in that system.

I have a mostly automated profile/sheet/information that I'd like to automate even more as it allow custom formulas using limited data and operations.

In the following table the column (col) 1 is entered (by the profile/sheet/information) then col 2 is automated and I'd like to do so for col 3; currently col 3 is entered and the user is supposed to verify its correct when col 1 is changed, but it's more than negligibly forgotten so the user doesn't benefit from having a col 3 as high as possible (using the table constraints). If possible I'd end up with a custom formula to generate col 3, the only information it could have is col 1 & 2 and the only available operations are arithmetic (+, -, x & /) and rounding (round(), floor() & ceil()). There is no need to figure col 2, it's only there if it helps finding the formula for col 3 (with the restrictions of the previous sentence).
 1 2 0 2 2 0 3 2 0 4 2 0 5 3 0 6 3 0 7 3 0 8 3 1 9 4 1 10 4 1 11 4 1 12 4 1 13 5 1 14 5 2 15 5 2 16 5 2 17 6 2 18 6 2 19 6 2 20 6 2

Step by step: In the profile/sheet/information, a user goes row-by-row, hopefully going all the way to the end but might stop along the way, stopping would have nothing to do with the data. The user currently have to enter col 1 & 3 (as they go along, thus row-by-row), in the profile/sheet/information what's related to col 2 is automated and will always reflect what's in the table (whatever is in col 1, it will become col 2 of the corresponding row). As mentioned currently the data in the profile/sheet/information related to col 3 has to be entered manually with the corresponding disadvantages; it will function incorrectly if a user forget to modify it after changing the data corresponding to col 1, or do so incorrectly, it will be less efficient if it's lower than the corresponding row col 3, it will be breaking the rules if it's higher, so it's better if it's lower than higher, but it would be nice to have the exact data. I would like an algorithm to automatically modify the data related to col 3 so there's no chance of a user forgetting to change it after changing col 1; the only operations allowed are in the 4th sentence, italicized.

Workaround: If it turns out it's quite difficult to make it the whole table fit, skipping in col3 the 0s could be a workaround (so only for the rows which col1 is between 8 & 20).

Thank you kindly for your help

2. ## Re: Formula from table with operation restrictions

I don't have much time now but I'll try to come back to it later.

Here's a thought for you. See the image below. You could maybe try a sine curve or something. (This would be a lot easier if you had 7 ones and 6 twos.)

The red dots (evenly spaced!) would be a value for 0, the black for 1, and the green for 2. (We probably need the black dots to not be at the maximum, but 3 on each side.)
-Dan

3. ## Re: Formula from table with operation restrictions

If n is the number in the first column, how about $$\text{floor}(\frac n 8) +\text{floor}(\frac n {14}) -\text{floor}(\frac n {16})$$for column 3.

4. ## Re: Formula from table with operation restrictions

Originally Posted by Walagaster
If n is the number in the first column, how about $$\text{floor}(\frac n 8) +\text{floor}(\frac n {14}) -\text{floor}(\frac n {16})$$for column 3.
I'm in the middle of something and using the real system would take too much energy to do it at the same time; so I did a preliminary test using a spreadsheet and it validated. I should reply or make an update to this post < 24 hrs, hopefully much sooner.

5. ## Re: Formula from table with operation restrictions

I was going to write that the end system doesn't work with your formula when I remembered in the spreadsheet for the last part of the formula the subtraction sign, which is perhaps the valid UTF sign, gave an error and after replacing '−' with '-' it worked, so I did the same replacement in the end system (and it worked). For details: The Roll20 formula is
floor(@{base_level}/8)+floor(@{base_level}/14)-floor(@{base_level}/16)