UUID v6, v7, v8 : タイムスタンプでソートできる新しい UUID のドラフト仕様 - kakakakakku blog
ID を採番するときによく使われる UUID Version 4 の課題として「順序性がなくソートしにくい」という側面があり，ULID (Universally Unique Lexicographically Sortable Identifier) を使えばソートできるようになるという記事を前に書いた． kakakakakku.hatenablog.com 関連して調査をしていたら，標準化団体 IETF (Internet Engineering Task Force) によって，UUID Version 6, 7, 8 という新しい仕様が提案（ドラフト段階）されていることを発見した❗️UUID Version 6, 7, 8 の目的を簡単にまとめると「タイムスタンプ情報を使ってソートできる ID を採番できるようにする」となり，もしこの仕様が取り込まれると，UUID を活用する幅がさ
一意な識別子の生成でUUID/ULID/CUID/Nano IDなど検討してみた - Sweet Escape
最近、一意な識別子について検討することがあったのでその検討メモ。 一意な識別子とは つまり、重複しない、ユニークな識別子（Identifier, 以下id）のこと。ここではRDBのテーブルにおける主キーとして使うことを想定かつ前提としている。したがって、主キーの要件であるユニーク性を持ったidをどうやって生成していくか。 そんなのDBの連番でいいじゃんて話もあるがここではその話はせず、あくまでも一意な識別子をどう生成するかの話に絞る。 選択肢 一番有名だと思われるUUIDを筆頭にいくつかの選択肢がある。 UUID ULID CUID Nano ID 他にもTwitter発のSnowflakeとか今はDeprecatedになってるshortidなどがあるが、キリがないのでここでは上記の4種類だけで簡単に比較した。また、実際にはUUIDはバージョンによってSpecが異なるがここではバージョン4
リアルタイム共同編集のアルゴリズム (Operational Transformation; OT) を理解する試み – RORO
Google Docsのように文書を複数人でリアルタイムに共同編集できるアプリケーションがあります。あのような機能は、多かれ少なかれ、Operational Transformation (OT; 操作変換) という考え方を使って実現されているようです。興味があったので、このOTについて調べてみました。 (追記: これからは OT でなく CRDT だという話 → I was wrong. CRDTs are the future) なおGoogle Docsではいわゆる「リッチテキスト」を共同編集できますが、ここでは話を簡単にするために「プレーンテキスト」を共同編集することを想定します。 リアルタイム共同編集の流れ 共同編集システムの登場人物は次の通りです： サーバ x 1（各クライアントから届く編集操作をもとに、最新の文書を保持します） クライアント x N（文書を編集する側です） そ
オンラインゲームでは、お互いの位置がだいぶ離れていても (日本とブラジルくらい) 何故素早く同期できるのですか？どのように通信しているのでしょうか？に対するNakamura Yutaさんの回答 - Quora
回答 (7件中の1件目) 通信するデータ量が増えれば増えるだけ、遠距離間における反応は遅くなることは感覚的に理解できるのではないかと思います。 そういう意味で、反射速度を上げてゲームむを滑らかに遂行させるためには、なるべく通信するデータは少ないのがベストです。 なので、単位時間当たりのプレーヤーの位置、入力コマンド、標的の座標といった、操作に関わるデータを何かしらのデータ圧縮を用いて通信し、そのうえで遠隔地にいるプレーヤー同士の対戦を実現しているのだと思います。 その時に、なるべくデータを小さくするためにある程度の操作などをテーブルにまとめておいたのを用意し、一回のデータで複数のコ...
8時間を0.01秒に短縮 「アルゴリズムの素晴らしさが2分で分かる動画」が今すぐ勉強したくなる分かりやすさ
※本記事はアフィリエイトプログラムによる収益を得ています アルゴリズムの素晴らしさを2分で解説した動画が、とても分かりやすくためになると人気です。なるほど、これがアルゴリズムと仕組みかぁ。 最短経路をアルゴリズムで算出しよう この動画では、迷路を最短手数で解くアルゴリズムについて解説。迷路はマス目状になっており、全部で8900億個の手順が存在するものとなっています。全ての経路を試せば最短手順を導き出せますが、普通のコンピュータでは約8時間かかってしまう計算になります。 全パターンの網羅は非常に時間がかかります そこで計算の手順を変更。スタートに0を書き、その隣1を、また隣に2……と繰り返していきます。こうして進めていくと最終的にゴールは34となり、この34が最短手数となることが分かります。今度はゴールから34，33，32とたどっていけば、最終手数で進む経路の1つが導き出せました。 数字を振
パズルとアルゴリズムのコラボ本を書きました！ - けんちょんの競プロ精進記録
1. はじめに お久しぶりです！ けんちょん本のけんちょんです。 最近はアルゴリズムがとても盛り上がっていますね。今回新たなアルゴリズム本を上梓させていただくことになりました！ 発売予定日は 2022/4/20 です。一部大型書店では、もうすでに並んでいるはずです。今回の記事では、この本を通してお届けしたいメッセージや、想定読者、内容などについて簡単に紹介させていただきます。 amazon ページへのリンク 2. 本書の内容と対象読者 2-1. 本書の内容 百聞は一見に如かずということで、まずは目次構成をお見せします！ 第 1 章：アルゴリズム入門 第 1 話：「テンパズル」 〜 力まかせ探索 第 2 話：「小町算」 〜 再帰関数 第 3 話：「虫食算」 〜 枝刈り 第 II 章：グラフアルゴリズム 第 4 話：「数独」 〜 深さ優先探索 1 第 5 話：「覆面算」 〜 深さ優先探索 2
高速な文字列探索：Daachorseの技術解説 - LegalOn Technologies Engineering Blog
こんにちは。LegalForce Researchで研究員をしている神田 (@kampersanda) です。 LegalForce Researchでは現在、高速なパターンマッチングマシン Daachorse（ダークホース）を開発・運用しています。文字列処理の基礎である複数パターン検索を提供するRust製ライブラリです。以下のレポジトリで公開されています。 github.com 本記事はDaachorseの技術仕様を解説します。具体的には、 複数パターン検索に関係する基礎技術（トライ木・Aho–Corasick法・ダブル配列） Daachorseの実装の工夫と性能 を解説します。 以下のような方を読者として想定します。 文字列処理アルゴリズムやデータ構造に興味のある方 自然言語処理の要素技術に興味のある方 Rustライブラリに興味がある方 Daachorseについて 複数パターン検索の基
ポケモンの最強タイプを考える【グラフ理論】 - Qiita
導入 先日、ポケモンの最新作『Pokémon LEGENDS アルセウス』が発売されました。ポケモン愛好家の中で密かに話題を集めたのが、新たに登場したポケモン「ゾロア（ヒスイのすがた）」と「ゾロアーク（ヒスイの姿）」のタイプです。なんと驚くべきことに、両者のタイプは未だ登場したことのなかった「ノーマル・ゴースト」だったのです。 ポケモンを知る人には説明不要ですが、これはノーマルタイプの唯一の弱点であるかくとう技をゴーストタイプで無効化しながら、ゴーストタイプの弱点であるゴースト技をノーマルタイプで無効化するという、非常にバランスのとれた、まさに夢のような複合タイプです。一部では、この「ノーマル・ゴースト」こそ最強の組み合わせなのではないかと噂されました。 しかし、果たして本当にそうなのでしょうか？ ポケモンのタイプは全部で18種類あり、一匹のポケモンは二つまでタイプを持つことができます。考
世界四連覇AIエンジニアがゼロから教えるゲーム木探索入門 - Qiita
はじめに 書籍化 本記事を元に ゲームで学ぶ探索アルゴリズム実践入門～木探索とメタヒューリスティクス という書籍を出版することになりました！ 本記事を読んで気になっていただけたらご購入をご検討いただけるとうれしいです！ この記事で得られる技術 ゲームルールに適した探索アルゴリズムを選択する ゲーム木探索をするのに適したクラス設計 主要なゲーム木探索アルゴリズムの実装 この記事の特徴 汎用アルゴリズムの実装例による他ゲームへの応用力と、実際に動作可能なサンプルコードによる具体的実装イメージの両視点でわかりやすくした（片方しか記載のない記事が多い） サンプルコード付き日本語記事がほぼないDUCTを解説している サンプルコードは印のついたメソッドを実装したクラスさえ書けば、アルゴリズム部分を変更せずそのまま他のゲームで動作可能になっている この記事で扱わない関連技術 探索の高速化 多様性の確保
アルゴリズムの世界地図 - Qiita
0. アルゴリズムとは？ まず、アルゴリズムとは何かを説明します。（0 節の説明はスライド「50 分で学ぶアルゴリズム」 の説明を参考にして書きました） さて、次の問題を考えてみましょう。 問題： 1 + 2 + 3 + … + 100 の値を計算してください。 単純な方法として、式の通りに 1 つずつ足していく方法が考えられます。すると、以下の図のように答えが計算されることになります。 これで答え 5050 が正しく求まりました。これはれっきとした アルゴリズム であり、この問題を 99 回の足し算 で解いています。しかし、計算回数が多く、計算に時間がかかるのではないかと思った方もいると思います。 ここで、方法を変えて、「1 + 100」「2 + 99」「3 + 98」…「50 + 51」の合計を求めることで、1 + 2 + 3 + … + 100 の値を計算してみましょう。 50 個の
Python言語による実務で使える100+の最適化問題 | opt100
はじめに 本書は，筆者が長年書き溜めた様々な実務的な最適化問題についてまとめたものである． 本書は，Jupyter Laboで記述されたものを自動的に変換したものであり，以下のサポートページで公開している． コードも一部公開しているが，ソースコードを保管した Github 自体はプライベートである． 本を購入した人は，サポートページで公開していないプログラムを 圧縮ファイル でダウンロードすることができる． ダウンロードしたファイルの解凍パスワードは<本に記述>である． 作者のページ My HP 本書のサポートページ Support Page 出版社のページ Pythonによる実務で役立つ最適化問題100+ (1) ―グラフ理論と組合せ最適化への招待― Pythonによる実務で役立つ最適化問題100+ (2) ―割当・施設配置・在庫最適化・巡回セールスマン― Pythonによる実務で役立つ
頭が痛くならない「ダメージ計算式」の基本の話｜だらねこ
戦闘のあるゲームを作るなら、考えないといけないのがダメージの計算式。でも、計算式のコツとか基本とか調べると、小難しそうな話が出てきて め、めんどくせぇ～ってなったりしませんか？私はなります。色んな計算式とその特徴を羅列されても、よくわかんなくなっちゃう。 とはいえ私もゲームデザイナーの端くれなので、ダメージ計算式を考える機会がそれなりにあります。そして他人の作った変な計算式に苦しめられることも、いっぱいあります。泣きたい。 大元の計算式が悪いと、それを利用してバランス調整しても苦労する事が多いんですよ。なので、そんな悲劇を少しでも食い止めるためにもですね。 この記事では 数字が苦手な文系の人でも、なんかいい感じに計算式を考る…とっかかりになることを目指して書いていこうかと思います。 ※こういう計算式がある！選んで使え！！という記事ではありません。 ※計算式を考える時、こういうのを把握して、
「施策デザインのための機械学習入門」を完全に理解したサトシくんがポケモン捕獲アルゴリズムを実装する話 - kanayamaのブログ
プロローグ ストーリー編 第1章 感銘 step1. KPIの設定 step2. データの観測構造をモデル化する step3. 解くべき問題を特定する step4. 観測データのみを用いて問題を解く方法を考える step5. 機械学習モデルを学習する step6. 施策を導入する 第2章 絶望 第3章 反省 第4章 再起 step1（再） KPIの設定 step2（再） データの観測構造をモデル化する step3（再） 解くべき問題を特定する step4（再） 観測データのみを用いて問題を解く方法を考える step5（再） 機械学習モデルを学習する step6（再） 施策を導入する 第5章 俺たちの戦いはこれからだ！ 実装編 準備 擬似データの生成 意思決定モデルの学習 モデルのオフ方策評価 モデルの真の性能の評価 まとめ この記事を読んだ方はこんな記事も読んでいます（多分） @tkana
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
CPUとGPUのマルチスレッディングの違いについて - arutema47's blog
"Locality is efficiency, Efficiency is power, Power is performance, Performance is King", Bill Dally マルチスレッディングとは？ CPUとGPUのマルチスレッディングの違いをブログにまとめていたけど例によって誰も興味なさそう— arutema47 (@arutema47) 2021年8月16日 つぶやいたら読みたい方が多そうだったので完成させました。 マルチスレッディングとはメモリ遅延を隠蔽しスループットを上げるハードウェアのテクニックです。 ただCPUとGPUで使われ方がかなり異なるため、その違いについて考えてみる記事です。 （SIMDについて並列プログラミングの観点から触れるべきでしたが、時間無いマルチスレッディングに注目するため初版では省きました。） 本記事について 本記事はCPUとG
「量子」と組合せ最適化に関する怪しい言説 ―とある研究者の小言― - むしゃくしゃしてやった，今は反省している日記
最近，量子コンピュータの話題をニュースや新聞で見かけることが増えてきました． その中で気になってきたのが，組合せ最適化と量子コンピュータ（特に量子アニーリング）に関する怪しい言説．私自身は（古典コンピュータでの）組合せ最適化の研究をやってきて，量子コンピュータを研究しているわけではないのですが，さすがにこれはちょっと・・・と思う言説を何回か見かけてきました． 最近の「量子」に対する過熱ぶりは凄まじいので，こういう怪しい言説が広まるのは困りものです．すでにTwitter上には，“組合せ最適化は今のコンピュータでは解けない”とか“でも量子なら一瞬で解ける”という勘違いをしてしまっている人が多数見られます*1． さすがに危機感を覚えてきたので，この場できちんと指摘しておくことにしました． 今北産業(TL;DR) “古典コンピュータは組合せ最適化を解けない” → 古典コンピュータで組合せ最適化を解
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Algorithms
ReDoS 検出の最先端 recheck の紹介 / State of the Art of ReDoS Detection
ルールベース画像処理のススメ
https://utokyo-icepp.github.io/qc-workbook/welcome.html