"Jacob S. Gordon" <[email protected]> writes:

> I think you mean:
>
>            floor(1 + 8(p-H)/(L-H+1)) : {H,…,L} -> {1,…,8}?
>
> This completely cuts out priority 9, so it introduces a boundary issue
> at p = L, but is otherwise very close to (N-1):
>
>                 #   #   #   #   #   #   #   #
>                 #   #   #   #   #   #   #   #
>                 #   #   #   #   #   #   #   #
>              ---|---|---|---|---|---|---|---|---|---
>                 1   2   3   4   5   6   7   8   9
>
> The real issue seems to be all our formula are mapping onto [1,9)
> which has length 8, instead of something like [1,10):
>
>           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.

> or, a more symmetric version with rounding by mapping onto the
> interval [0.5,9.5] (you just have to be careful at the half-integers
> because of the tie-to-even behaviour):
>
>          round(1/2 + 9(p-H)/(L-H)) : {H,…,L} -> {1,…,9}

I think this maps onto [0,10]?

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.

Here's another way to think about this. We could map the priorities
from lowest to highest to (0,1] as:

1/N, 2/N, ..., 1

so iCal priority 1 maps to 1 (100% importance), and iCal priority 9 maps
to 1/9 (11.1% importance). Meanwhile for the default Org priorities A-C,
A maps to 1 (100% importance), while C maps to 1/3 (33.3%
importance). If we think of the priorities this way, then I think

floor(1 + 9*(p-H) / (L-H+1))

actually does minimize both the absolute and squared error (as long as
we identify the Org and iCalendar priorities with their "probability"
values rather than their nominal values), in addition to minimizing the
entropy.

> I think that should be covered by the user option: we provide some
> ‘standard’ choices, or a user can directly map {H,…,L} -> {1,…9} with
> their own function.  What do you think the options should be?

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.

Reply via email to