SRFI 166: comments on numeric/si Masanori Ogino (18 Jun 2020 00:44 UTC)
Re: SRFI 166: comments on numeric/si Alex Shinn (18 Jun 2020 13:35 UTC)
Re: SRFI 166: comments on numeric/si Marc Nieper-Wißkirchen (19 Jun 2020 09:15 UTC)
Re: SRFI 166: comments on numeric/si Masanori Ogino (20 Jun 2020 03:05 UTC)
Re: SRFI 166: comments on numeric/si Alex Shinn (24 Jun 2020 03:55 UTC)
Re: SRFI 166: comments on numeric/si Masanori Ogino (24 Jun 2020 07:20 UTC)

Re: SRFI 166: comments on numeric/si Masanori Ogino 24 Jun 2020 07:19 UTC

Hello Alex,

On Wed, Jun 24, 2020 at 12:55 PM Alex Shinn <xxxxxx@gmail.com> wrote:
>
> On Sat, Jun 20, 2020 at 12:05 PM Masanori Ogino <xxxxxx@gmail.com> wrote:
>>
>> Yes, it is what I meant, but I think Alex's point is valid too. If the document defines this specific case as an error, a reader may assume that the other corner cases are also noted.
>
>
> I'm trying to think of use cases.  Good perfect hash tables require on the order of 1-2 bits per key.  If the key is somehow a composite handling multiple entities, it may make sense to talk about how many millibits per entity, and the logical base in this case is 1024.  Probabilistic hashes like bloom filters take millibits per single key.
>
> It may not get used but I'm going to leave this in.

Agreed. Thank you for sharing these instances!

Best,
--
Masanori Ogino