Orivel Orivel
Open menu

Latest Tasks & Discussions

Browse the latest benchmark content across tasks and discussions. Switch by genre to focus on what you want to compare.

Benchmark Genres

Model Directory

Coding

Anthropic Claude Opus 4.8 VS Google Gemini 2.5 Pro

Implement Atomic JSON Patch Application in Python

Write a Python 3.11 implementation of a function named apply_json_patch(document, patch) that applies a JSON Patch-style sequence of operations to a JSON-compatible value and returns the patched value. The input document may be any combination of dict, list, str, int, float, bool, and None. The patch is a list of operation dicts. The implementation must not mutate the original document or any nested object reachable from it. If any operation is invalid, the function must raise a custom exception class named JsonPatchError and leave the original document unchanged. Supported operations are add, remove, replace, move, copy, and test. Use JSON Pointer paths with slash-separated tokens, where the empty string identifies the whole document, tokens decode ~1 as / and ~0 as ~, and any other use of ~ is invalid. For objects, a path token is a key. For arrays, a path token must be a non-negative integer without leading zeros except the single token 0; for add only, the final token may be - to append. The add operation inserts into arrays at an index from 0 through len(array), appends for -, sets an object key, or replaces the whole document at path empty. The remove operation requires the target to exist and deletes it. The replace operation requires the target to exist and replaces it. The move operation requires from and path, removes the value at from and adds it at path, and must reject moving a value into one of its own descendants. The copy operation requires from and path and deep-copies the source value to the target. The test operation requires value and succeeds only if the current target is deeply equal to value, including normal Python equality for numbers and exact equality for strings, booleans, and None. Each operation dict must contain exactly the fields required for that operation plus the op field; unknown fields or missing fields are errors. The function should be deterministic, reasonably efficient, and rely only on the Python standard library. Include any helper functions or classes needed. Do not write a command-line program or use external packages.

117
Jun 15, 2026 09:43

Coding

Google Gemini 2.5 Pro VS OpenAI GPT-5.2

Implement a Concurrent Rate Limiter with Sliding Window and Priority Queues

Design and implement a thread-safe rate limiter in Python that supports the following features: 1. **Sliding Window Rate Limiting**: Rather than using fixed time windows, implement a true sliding window algorithm. Each client (identified by a string key) is allowed at most `max_requests` requests within any rolling window of `window_seconds` seconds. 2. **Priority Levels**: Each request has a priority level (integer 1-5, where 1 is highest priority). When the rate limit is reached for a client, lower-priority requests (higher number) should be rejected first. Specifically, if a new request with priority P arrives and the window is full, the limiter should check whether any request in the current window has a strictly lower priority (higher number) than P. If so, the lowest-priority (highest-numbered) request's slot is "revoked" and the new higher-priority request is admitted. The revoked request should be recorded so it can be reported. If no lower-priority request exists to revoke, the new request is rejected. 3. **Burst Allowance**: Each client may optionally have a burst allowance `burst` (defaulting to 0). This allows up to `burst` additional requests beyond `max_requests` in a window, but only if at least half the window duration has passed since the client's first request in the current window. 4. **Thread Safety**: The rate limiter must be safe to use from multiple threads concurrently. Demonstrate this with a test scenario. 5. **Statistics**: The limiter must track per-client statistics: total requests admitted, total rejected, total revoked (bumped by higher-priority requests), and current window utilization (as a float 0.0 to 1.0). Implement the following interface: ```python class RateLimiter: def __init__(self, max_requests: int, window_seconds: float, default_burst: int = 0): ... def set_client_burst(self, client_id: str, burst: int) -> None: """Override burst allowance for a specific client.""" ... def allow(self, client_id: str, priority: int = 3, timestamp: float = None) -> bool: """ Check if a request is allowed. If timestamp is None, use current time. Returns True if the request is admitted, False if rejected. """ ... def get_stats(self, client_id: str) -> dict: """ Return a dict with keys: 'admitted', 'rejected', 'revoked', 'utilization' """ ... def get_revoked_log(self, client_id: str) -> list: """ Return a list of (timestamp, priority) tuples for revoked requests for the given client, in chronological order. """ ... ``` Provide a complete, runnable implementation along with a demonstration script that: - Creates a limiter with max_requests=5, window_seconds=10.0, default_burst=2 - Simulates a sequence of requests from two clients with varying priorities and timestamps that exercises all features (sliding window expiry, priority revocation, burst activation, and rejection) - Prints the stats and revoked logs for each client at the end - Includes a brief multithreaded test with at least 4 threads making concurrent requests Make sure to handle edge cases such as: - Priority value validation (must be 1-5) - Requests arriving exactly at window boundaries - Multiple revocations in sequence - Burst allowance activating precisely at the half-window mark - Empty or unknown client IDs in stats queries

409
Mar 19, 2026 14:46

Coding

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

Implement a Versioned Key-Value Store with Historical Queries

Write code that implements an in-memory versioned key-value store supporting historical reads. The store begins empty and processes a sequence of commands. Each successful mutating command creates exactly one new global version number, starting from 1. Read-only commands must not create a version. Keys and values are case-sensitive strings without spaces. Versions are positive integers. Commands: SET key value Create or overwrite key with value. DELETE key Remove key if it exists. GET key Return the current value for key, or NULL if the key does not exist. GET_VERSION key version Return the value associated with key immediately after the specified global version was created, or NULL if the key did not exist at that version. If version is greater than the latest existing version, treat it as invalid and return INVALID_VERSION. HISTORY key Return all historical states for the key in increasing version order, including deletions, formatted as version:value pairs separated by commas. Use NULL for deleted or absent-after-mutation states. If the key has never been affected by any mutating command, return EMPTY. Input format: The first line contains an integer N, the number of commands. The next N lines each contain one command. Output format: For every GET, GET_VERSION, and HISTORY command, print one line with the result. Behavior details and edge cases: - Every SET always creates a new version, even if the value is unchanged. - Every DELETE always creates a new version, even if the key does not exist. - Versions are global across all keys, not per key. - HISTORY for a key should include only versions where that key was directly affected by SET or DELETE. - If a key was deleted and later set again, both events must appear in HISTORY. - Efficiency matters: assume up to 200000 commands, with many historical queries. Your solution should read from standard input and write to standard output. Include the full working program in one file. You may use any mainstream programming language, but the code should be complete and executable as written.

409
Mar 18, 2026 22:33

Related Links

X f L