the analysis is very suspicious: “gpt 5 mini had api failures due to wrong temp setting”? wtf?

whatever you used to slop your benchmark didt even take the time to set the temp to 1 (which the docs say is required)

i understand zig as a better C, but in what world is another memory unsafe language a good idea?

i mean i kinda get if the thing you are writing would require LOTS of unsafe, then zig provides better ergonomics

however most programs can definitely be written without unsafe and in that case i dont get why wed do this to ourselves in 2025

why not take advantage of memory safe, and data race safety?

https://platform.openai.com/docs/models/compare?model=gpt-5....

This is just about syntax sugar hiding function calls.

it seems to truncate your prompt even under the "maximum message length" and yeah around 55k is where it starts to happen.

extremely annoying. o1 pro worked up until 115k or so. both o3 and gpt5 have the issue. (it happens on all models for me not just the pro variations)

with the new 400k context length in api i would expect atleast 128k message lengths and maybe 200k context in chat.

when models try to be smart/creative they attempt to switch poles like that. in my example it even says that the max speed will be only a few km/h (since their strategy is to chill at the poles and then sail from north to south pole very slowly)

--

GPT-5 pro does get it right though! it even says this:

"Do not try to swap hemispheres to ride both polar summers. You’d have to cross the equator while staying in daylight, which momentarily forces a westward component near the equatorial rotation speed (~1668 km/h)—a much higher peak speed than the 663 km/h plan."

"Assume the earth was just an ocean and you could travel by boat to any location. Your goal is to always stay in the sunlight, perpetually. Find the best strategy to keep your max speed as low as possible"

o3 pro gets it right though..

"This is not just a technical glitch; it’s a deep theoretical problem that suggests we don’t really understand the beginning at all."

"The bounce is not only possible – it’s inevitable under the right conditions."

ugh

Say i have `*Thing`. Are you saying i should cast it to a `Thing`? That is what I was doing initially (im fine with copies), but then you can't call functions that mutate.

from what i understand, pointers become used for that purpose instead (in addition to mutability). which then means that when you get a pointer you don’t know for what reason it is used, so you have to check it even if it was checked higher up in the callstack already.

i wouldn’t actually mind the fact that you can forget to check for nil, i can accept a panic here and there, pretty simple to fix..

the issue i am finding is that it "pollutes" the code, since you end up doing the check more than once for the same value.

if atleast you could only check once and then the compiler would know (ie optionals, or narrowing like TS). ideally you would dereference after the check, but you can’t because pointers are used for mutability AND optionals

in other words, are there any tricks so that you only have to check once?