E07 · Dorn/cuda/9

Full sample results

Scores

MethodScoreScaleDataset rank
(0–100)
GPT-6.1 Sol15.670–20; mean of three runs
61.6Δ 13.2
DeepSeek V4 Pro140–20; mean of three runs
65.9Δ 17.5
BTTF0.2710–1; higher is more readable
12.8Δ 35.5
Human3.331–5; original rating
48.3

Loading feature diagnosis…

Source code

GPT-6.1 Sol explanations

Run 1 · 15/20

Code Structure: Logically organized into thread indexing, initialization, convolution, and output.

Nesting: Moderate depth from the thread guard, loop, and bounds check; manageable but not flat.

Clarity of intent: Texture names and accumulation suggest gradient smoothing along the z-axis, though tid, index, and z are terse and the indexing arithmetic lacks explanation.

Code length: Concise overall, with minor repetition in dimension products and component-wise accumulation; the final return is unnecessary.

Action granularity: Statements generally perform one action per line, making updates easy to follow.

Reading flow: Execution proceeds naturally, but inconsistent spacing, redundant parentheses, and the unconventional -1 < z bounds check slightly impede scanning.

Run 2 · 16/20

Code Structure: Logically organized into thread indexing, window initialization, convolution accumulation, and output storage.

Nesting: Three control-flow levels are manageable, though the outer bounds check adds indentation.

Clarity of intent: Names such as gradientValue, windowValue, and smoothedImage suggest gradient smoothing, but the z-axis traversal, index arithmetic, and unused fourth component require inference.

Code length: Compact overall; the repeated slice-size expression could be named, and the final return is redundant.

Action granularity: Most lines perform one operation, with component-wise accumulation clearly separated.

Reading flow: Execution follows a natural setup-process-store sequence, aided by blank lines. Inconsistent spacing, the unusual -1<z condition, and the short z declaration with an int cast slightly impede readability.

Run 3 · 16/20

Code Structure: Logically organized into thread indexing, window initialization, convolution accumulation, and output.

Nesting: Three control-flow levels are manageable, though the outer bounds check and inner boundary check add indentation.

Clarity of intent: Descriptive texture and output names suggest gradient smoothing, but the convolution axis and index arithmetic require inference; comments or a named slice-stride variable would help.

Code length: Compact without substantial redundancy, although the trailing return is unnecessary.

Action granularity: Most lines perform one action, and component-wise accumulation is easy to follow.

Reading flow: Execution proceeds naturally from setup through iteration to storage, with useful blank lines. Inconsistent operator spacing, repeated dimension products, and the unusual '-1<z' condition slightly reduce readability.

BTTF feature contributions

Score 0.271 / 1