Orivel Orivel
メニューを開く

お題・ディスカッション一覧

公開されている最新のお題やディスカッションをまとめて確認できます。

比較ジャンル

モデル一覧

プログラミング

Anthropic Claude Opus 4.8 VS Google Gemini 2.5 Flash

決定論的リミットオーダーブック・シミュレータを実装する

単一ファイルの Python 3.11 ソリューションを作成し、関数 process_events(events: list[dict]) -> dict を実装してください。外部パッケージを使用しないでください。 この関数は、1つの銘柄の小さな取引所のリミットオーダーブックをシミュレートする必要があります。入力順序のイベント辞書のリストを受け取り、正確に次のキーを持つ辞書を返します: trades, rejected, book。 Event types: New order event: Required fields: type="new", id, side, order_type, qty. side は "buy" または "sell" です。 order_type は "limit" または "market" です。 qty は正の整数です。 limit 注文は price(セント単位の正の整数)も必須です。 オプションのフィールド tif は time-in-force で、"GTC", "IOC", または "FOK" のいずれかです。指定がなければ、limit 注文は "GTC" を、market 注文は "IOC" を使用してください。 market 注文は tif="GTC" を持つことはできず、book 上で残存してはなりません。 Cancel event: Required fields: type="cancel", id. それは、その id を持つ現在 book に残っている注文の残数量をキャンセルします。 Matching rules: book は bids と asks を持ちます。resting buy limit 注文は bids です;resting sell limit 注文は asks です。 価格-時間優先が必須です:最良価格が先;同一価格では、より早く受理された resting 注文が先です。 buy 注文は交差する限り resting ask とマッチします:market buy は任意の ask と交差します;limit buy は ask price <= buy limit price の ask と交差します。 sell 注文は交差する限り resting bid とマッチします:market sell は任意の bid と交差します;limit sell は bid price >= sell limit price の bid と交差します。 各トレードの数量は min(到着注文の残数量, resting 注文の残数量) です。 トレード価格は常に resting maker 注文の limit price であり、到着注文の価格では決してありません。 トレードが発生したら直ちに、正確に次のキーを持つトレード記録を追加しなければなりません: buy_id, sell_id, price, qty, taker_id, maker_id. 部分的に約定した resting 注文は、残数量で元の優先順位を保持します。完全に約定した注文は book から離脱します。 Time-in-force behavior: GTC limit 注文は、未約定の残りを book に残します。 IOC 注文は可能な限り即時に実行し、残りはキャンセルします。 FOK 注文は、現在の book と交差ルールに従って即時に完全に埋められる必要があります。完全に埋められない場合、トレードを一切生成せず、book を変更しません。完全に埋められる場合は通常通り実行します。FOK 注文は決して残りません。 Validation and rejection rules: イベントが不正な形式の場合、book を変更せずにそれを拒否してください。拒否レコードを rejected に追加し、キーは input_index, event, reason とします。reason は短い人間可読の文字列で構いません。 新しい注文の id が以前に受理されたどの new 注文でも既に使われている場合(その先の注文が既に約定またはキャンセルされていても)その new 注文を拒否してください。 不明な id やもはや resting していない id に対する cancel イベントを拒否してください。 qty と price の値が非整数、ゼロ、または負の場合は拒否してください。Python では、bool はこれらのフィールドの整数として受け入れてはいけません。 その他の余分なフィールドは、有効なイベントであれば無視してください。 Return format: trades: 実行順のトレード記録のリスト。 rejected: 入力順の拒否レコードのリスト。 book: keys が bids と asks の辞書。 book["bids"] は、降順の価格、次に元の resting 時刻でソートされたすべての resting bid をリスト化し、各要素は {"id": id, "price": price, "qty": remaining_qty} とします。 book["asks"] は、昇順の価格、次に元の resting 時刻でソートされたすべての resting ask をリスト化し、各要素は {"id": id, "price": price, "qty": remaining_qty} とします。 あなたの回答は、process_events を定義する完全な実行可能な Python コードであるべきです。ヘルパーのクラス/関数や if name == "main": で保護された小さなセルフテストセクションを含めても構いませんが、コア関数は stdin から読み取ったり stdout に書き出したりしてはいけません。

294
2026/06/29 09:44

プログラミング

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

スライディングウィンドウとバースト許容を備えたレートリミッタ

スライディングウィンドウ会計とバースト許容をサポートする、スレッドセーフなレートリミッタを選択した言語(Python, Go, Java, TypeScript, または Rust)のいずれかで設計・実装してください。要件は次のとおりです。 API surface: 少なくとも次の操作を公開してください: allow(client_id: str, cost: int = 1) -> bool — 現時点でリクエストが許可されるかどうかを返します。 retry_after(client_id: str) -> float — 少なくとも1単位の容量が利用可能になるまでの秒数を返します(現在許可されている場合は0)。 クライアントごとの設定を受け取るコンストラクタ: rate(単位/秒)、burst(蓄えられる最大単位)、およびスライディングウィンドウ会計のためのオプションである window_seconds。 Algorithm: トークンバケット(バースト許容のため)と スライディングウィンドウ(ログまたはカウンタ)(window_seconds 内で許可される総リクエストを上限するため。純粋なトークンバケットではリフィル後に持続的な乱用を許してしまう)を組み合わせたハイブリッドを実装してください。リクエストは両方のチェックが通った場合にのみ許可されます。スライディングウィンドウのデータ構造選択(正確なログ vs. 重み付き二窓近似)について正当化し、メモリ/精度のトレードオフを短いコメントブロックまたは付随するノートで議論してください。 Concurrency: リミッタは同一および異なる client_id に対して多くのスレッド/ゴルーチンから同時に呼ばれます。単一のグローバルロックがボトルネックにならないようにしてください(例:クライアント毎のロック、ロックストライピングなど)。同時実行の allow 呼び出しの下であなたのアプローチが正しい理由(トークンの二重消費が起きない、更新の取りこぼしがない)を文書化してください。 Time source: テストが決定論的になるようにクロックを注入可能にしてください。デフォルトではモノトニッククロックを使用してください。 Edge cases to handle explicitly: cost が burst より大きい場合(拒否すること、永遠にブロックしないこと)。 クロックの巻き戻しや長時間の一時停止(例:サスペンドされたVM):クラッシュさせずにクランプ(調整)し、無制限のトークンを付与しないこと。 新規クライアントの最初のリクエスト(遅延初期化)。 ステールなクライアントのクリーンアップ(クライアントが停止してもメモリが無制限に成長しないこと)。 小数トークン/サブミリ秒の時間処理。 Tests: 注入可能なクロックを使用して、少なくとも6つの単体テストを提供してください。対象は:基本的な許可/拒否、バーストの枯渇とリフィル、バケットのリフィルとは独立したスライディングウィンドウ上限、cost > burst、1クライアントへの同時競合(決定論的特性:ある期間 T 秒内に許可される合計 ≤ rate*T + burst)、およびステールクライアントの除去を含みます。 Complexity: allow の償却時間計算量とクライアントあたりのメモリ計算量を明示してください。 Deliver: 完全な実行可能コード(単一ファイルで可、ただしファイルを分ける場合は明確にラベル付けしてください)、テスト、および設計ノート(最大約250語)を提出してください。

461
2026/05/12 09:45

プログラミング

Google Gemini 2.5 Flash VS OpenAI GPT-5.4

ロックフリーの並行 LRU キャッシュを実装する

Python でスレッドセーフな LRU(Least Recently Used)キャッシュを実装してください。すべての操作でグローバルなロックを使用せず、並行した読み書きをサポートすることを目的とします。実装は以下の要件を満たす必要があります。 インターフェース: キャッシュは次の操作をサポートしなければなりません: __init__(self, capacity: int) — 与えられた最大容量(正の整数)でキャッシュを初期化する。 get(self, key: str) -> Optional[Any] — キーが存在する場合はその値を返し(最近使用されたものとしてマークする)、存在しない場合は None を返す。 put(self, key: str, value: Any) -> None — キーと値のペアを挿入または更新する。挿入後にキャッシュが容量を超える場合は、最も使用されていない項目を削除する。 delete(self, key: str) -> bool — キャッシュからキーを削除する。キーが存在した場合は True、存在しなかった場合は False を返す。 keys(self) -> List[str] — 現在キャッシュに存在する全てのキーのリストを、最も最近使用された順から最も使用されていない順へ並べて返す。 並行性: キャッシュは複数のスレッドから同時に安全に使用できなければなりません。可能な限り読み取り同士が互いにブロックしない設計を目指してください(例えば、リード・ライトロック、細粒度ロック、またはロックフリー技術の使用)。すべての操作を直列化する単一のグローバルミューテックスは基準解とは見なされますが、最適な解決策ではありません。 競合下での正しさ: 同時アクセス下でも、キャッシュは決して古いデータや破損したデータを返してはならず、指定された容量を超えてはならず、一貫した LRU 順序を維持しなければなりません。 扱うべきエッジケース: 容量が 1 の場合 既に存在するキーに対する put(値を更新し、最も最近のものに移動すること) 存在しないキーに対する delete 同一キーに対する同時の put と get 多数のスレッドが同時に挿入する際の急速な連続追い出し(evictions) テスト: 単一スレッドおよびマルチスレッドのシナリオで全操作の正しさを示すテスト関数 run_tests() を含めてください。マルチスレッドテストは少なくとも 8 スレッドを使い、重複するキーに対して get、put、delete の混合操作を行い、キャッシュが決して容量を超えないこと、また get が一度も挿入されていないキーに対して値を返さないことをアサートする必要があります。 完全な実装を Python で提供してください。標準ライブラリのみを使用し、サードパーティのパッケージは使用しないでください。並行性戦略と取った設計上のトレードオフを説明する docstring とコメントを含めてください。

588
2026/03/23 17:47

プログラミング

Google Gemini 2.5 Flash VS OpenAI GPT-5.2

範囲クエリを備えたロックフリー並行スキップリストを実装する

任意の言語(C++、Java、Rust、Go、または Python)で、以下の操作をサポートする並行スキップリストデータ構造を設計し、実装してください。 insert(key, value) – キーと値のペアを挿入する。キーがすでに存在する場合は、値をアトミックに更新する。新しいキーが挿入された場合は true、更新だった場合は false を返す。 remove(key) – キーと値のペアを論理削除する。キーが見つかって削除された場合は true、それ以外は false を返す。 find(key) – キーに対応する値を返すか、存在しないことを示す。 range_query(low, high) – low <= key <= high を満たすすべてのキーと値のペアを、キー順にソートされたリストとして返す。結果は一貫したスナップショットでなければならない。すなわち、操作の実行中に同時に存在したことが一度もないキーを含んではならない。 size() – アクティブな(削除されていない)要素数のおおよその値を返す。 要件と制約: スキップリストは、上記の操作を任意に組み合わせて同時実行する複数スレッドによる並行利用に対して安全でなければならず、単一のグローバルロックを用いてはならない。細粒度ロック、ロックフリー技法(CAS)、またはその組み合わせを使用してよい。 遅延削除は許容される。ノードは物理削除の前に、削除済みとして論理的にマークされてもよい。 確率的なレベル生成は、p=0.5、最大レベル 32 の標準的な幾何分布を使用しなければならない。 キーは 64 ビット整数、値は文字列とする。 適切なメモリ安全性への配慮を含めること。ガベージコレクションのない言語を使用する場合は、再利用戦略(例: エポックベース再利用、ハザードポインタ)を説明するか実装すること。 提出物: 並行性戦略を説明するコメント付きの、完全でコンパイル可能/実行可能なソースコード。 複数スレッドを起動して insert、delete、find、range query を並行実行し、正しさを検証するテストまたはデモンストレーション(例: 更新の取りこぼしがないこと、範囲クエリでファントムリードがないこと、クラッシュしないこと)。 以下を論じる簡潔な分析セクション(コメントまたは docstring でも可): あなたの実装が提供する線形化可能性(またはスナップショット分離)の保証。 各操作の期待時間計算量。 既知の制限や潜在的な ABA 問題、およびそれにどう対処しているか。 あなたの解答は、並行実行下での正しさ、コードの明瞭性、並行性戦略の堅牢性、範囲クエリのスナップショット機構の品質、分析の徹底性に基づいて評価されます。

595 1
2026/03/18 22:05

プログラミング

OpenAI GPT-5.2 VS Google Gemini 2.5 Flash

Least Recently Used (LRU) キャッシュの実装

LRU(Least Recently Used)キャッシュクラスをPythonで実装してください。以下の操作をサポートする必要があります。 LRUCache(capacity) — キャッシュを正の整数容量で初期化します。 get(key) — キーが存在する場合は、それに関連付けられた値を返します。存在しない場合は -1 を返します。キーにアクセスすると、そのキーが最近使用されたものとしてマークされます。 put(key, value) — キーと値のペアを挿入または更新します。挿入後にキャッシュが容量を超えた場合、最も最近使用されていないキーを削除します。 get と put の両方は、平均 O(1) の時間計算量で実行される必要があります。 完全で自己完結したPython実装を提供してください。functools.lru_cache または collections.OrderedDict を使用しないでください。基盤となるデータ構造(例:双方向連結リストとハッシュマップ)を自分で実装する必要があります。 クラス定義の後、容量 2 の LRUCache を作成し、以下の操作を実行して、各 get の結果を印刷する短いデモンストレーションを含めてください。 cache = LRUCache(2) cache.put(1, 10) cache.put(2, 20) print(cache.get(1)) # 期待値: 10 cache.put(3, 30) # キー 2 を削除 print(cache.get(2)) # 期待値: -1 cache.put(4, 40) # キー 1 を削除 print(cache.get(1)) # 期待値: -1 print(cache.get(3)) # 期待値: 30 print(cache.get(4)) # 期待値: 40

652
2026/03/10 15:38

関連リンク

X f L