"Jacob S. Gordon" <[email protected]> writes:
> IIUC you’re suggesting we use something like ceil(x-s) where s∈[0,1]
> is a user option, and using the fact that ceil(x-1/2) ~ round(x) and
> ceil(x-1) ~ floor(x)? I’m not sure why other values of the shift
> would be desirable, e.g. if I set s = 1/3, in the limit L-H → ∞ then
> 1/3*1/8 of the priorities will map to 1 and 2/3*1/8 will map to 9 [1]:
> ...
> [1] It also has a larger error: e → 1/4 + (s-1/2)^2 as as L-H → ∞, or
> 1 + (2s-1)^2 times larger than rounding.
Not sure this is the "right" loss function (or if there is one). It
assumes the goal is to minimize the residual to a particular linear
function. But one might prefer another objective, for example to
divide the Org priorities as evenly as possible into the 9 groups.
For example if there are 90 Org priority levels, it feels natural to
have the Org -> iCal map
[1,10] -> 1, [11,20] -> 2, ..., [81,90] -> 9
so that each iCal priority would contain 10 Org priorities. However
under your mapping the number of Org to iCal priorities is uneven,
with iCal priorities containing 6, 11, or 12 Org priorities (iCal
priorities 1 and 9 contain 6 Org priorities, while iCal priorities 2-8
contain 11 or 12 Org priorities).
An alternative that would achieve a more even distribution is
(floor (+ 1 (* 8. (/ (float (- pri org-priority-lowest))
(+ 1 (- org-priority-highest
org-priority-lowest))))))
IOW, if i = pri - lowest, and N = highest - lowest + 1 is the number
of Org priorities, then this maps i -> i/N and then partitions [0,1)
into 9 equal half-open segments. Note unlike the current
implementation and your proposal, this function uses N in the
denominator instead of (N-1), so that the range is [0,1) instead of
[0,1], so that all the steps can be half-open (preventing the boundary
issue).
However, this function may not be desired when the number of Org
priorities is low -- for example, in the case of Org priorities A-C,
it maps
A -> 1, B-> 3, C -> 6
instead of
A -> 1, B -> 5, C -> 9
which is the behavior of the current exporter as well as your
proposal.
A possible way to address this under the partitioning [0,1) approach
would be to relabel the non-empty segments so that they match some
desired behavior, e.g. the current behavior of making them as far
apart as possible on {1,...9}, or possibly some other behavior (e.g.
some users might prefer to map A->1, B->2, C->3).
