エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント12件
- 注目コメント
- 新着コメント
![ka-ka_xyz ka-ka_xyz](https://cdn.profile-image.st-hatena.com/users/ka-ka_xyz/profile.png)
ka-ka_xyz
idに素数を振ってアクセス権限設定として素数の積を使う(read_acl=105の場合、user_id=3,5,7のユーザーがread出来る的な)というのを思い出したけど、ユーザやグループを増やしてくとわりかし簡単にInteger.MAX_VALUEに手が届く地獄
![dgen dgen](https://cdn.profile-image.st-hatena.com/users/dgen/profile.png)
dgen
コンピュータで使うなら何bitで扱うかが問題だ。元の数が 64bit で識別子が 32bit だとすると元の数のままのほうが速度も容量も有利。圧縮しないほうが得になる。それより10¹⁰⁰⁰⁰⁰⁰⁰⁰⁰⁰⁰進数のほうがいいな。
![ROYGB ROYGB](https://cdn.profile-image.st-hatena.com/users/ROYGB/profile.png)
ROYGB
似たようなことを考えたことはある。新たな記号は、前の数+1(もしくは+子)で定義する。たとえば丑=子+1、寅=丑+1、卯=丑・丑+1、辰=丑・寅+1みたいな感じ。丑と+1だけで表記することも可能。
![madooka madooka](https://cdn.profile-image.st-hatena.com/users/madooka/profile.png)
madooka
あっという間に識別子が枯渇しそうでピンとこないなー。追加ルールは面白いが計算量が気になる。このルールの方が効率が良い最大値を求めるのは体操としてアリかな。識別子の表現で食うデータ量を圧縮率で補える数
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
いまの話題をアプリでチェック!
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
2020/11/19 リンク