On 2026-05-26 23:49, Jack Kamm wrote:
> "Jacob S. Gordon" <[email protected]> writes:
>> floor(1 + 9(p-H)/(L-H+1)) : {H,…,L} -> {1,…,9}
>
> Yes, sorry, I swapped highest and lowest, and you're right, it
> should be 9 instead of 8.
That works, though it will generally not be symmetric around 5 and is
biased away from 9:
N = 2 # #
N = 3 # # #
N = 4 # # # #
N = 5 # # # # #
N = 6 # # # # # #
N = 7 # # # # # # #
N = 8 # # # # # # # #
N = 9 # # # # # # # # #
---|---|---|---|---|---|---|---|---|---
1 2 3 4 5 6 7 8 9
compared to the rounding scheme:
N = 2 # #
N = 3 # # #
N = 4 # # # #
N = 5 # # # # #
N = 6 # # # # # #
N = 7 # # # # # # #
N = 8 # # # # # # # #
N = 9 # # # # # # # # #
---|---|---|---|---|---|---|---|---|---
1 2 3 4 5 6 7 8 9
I’ve only shown low N here, but these will form the ‘tops’ of the
histograms for larger N, showing how the two schemes distribute extra
points on top of an even background, e.g. N=21 looks like N=3:
# # #
floor # # # # # # # # #
N = 21 # # # # # # # # #
---|---|---|---|---|---|---|---|---|---
1 2 3 4 5 6 7 8 9
# # #
round # # # # # # # # #
N = 21 # # # # # # # # #
---|---|---|---|---|---|---|---|---|---
1 2 3 4 5 6 7 8 9
>> round(1/2 + 9(p-H)/(L-H)) : {H,…,L} -> {1,…,9}
>
> I think this maps onto [0,10]?
That’s why I said care is needed with default rounding on half
integers. Assuming tie-to-even, the behaviour I had in mind can be
expressed as:
round(9(p-H)/(L-H) - 4.5) + 5
{H,…,L} -> [-4.5,4.5] -> {-4,…,4} -> {1,…,9}
> Also I think the tie-to-even behavior is undesirable, it means the
> interval is tiled with successively closed then open intervals like
>
> (0.5, 1.5), [1.5, 2.5], (2.5, 3.5), ...
>
> which will cause unevenness between the sub-segments when points map
> to their boundaries.
It could be chosen differently (e.g., tie towards zero), but in the
majority of cases it has /exactly/ the same ‘uneveness’ as the floor
option, except symmetrically distributed instead. Only when L-H = 9n
(n = 1,2,…) do you see exaggerated differences from this property (+2
instead of +1), but these cases can easily be smoothed.
> I think the options should be:
> 1. Current implementation, for back-compatibility.
> 2. One or more alternative functions, referred to by symbol names.
> 3. Custom user function mapping {H,...,L}->{1,...,9}.
>
> Patch is welcome, if you are interested.
I think the current version is just wrong, but otherwise sounds good
to me. I’ll wait to hear other thoughts before preparing anything.
Best,
--
Jacob S. Gordon
[email protected]
Please don’t send me HTML emails or MS Office/Apple iWork documents.
https://useplaintext.email/#etiquette
https://www.fsf.org/campaigns/opendocument
