v7.5.0
v7.5.0
We re-measured, and corrected, both the reason behind "drifting cannot beat grip" and how far that statement actually reaches (its scope). The driving physics is unchanged down to the byte. Until now the notes gave two different reasons (§11 and §13.8 said "because steering is only left / centre / right", §13.14 said "because of the car's own recovery limit"), and never said which situations the claim covered. While looking into it we found that the drift driver used for the measurements still had the sign of the counter-steer the wrong way round (sideslip angle goes negative in a left-hand slide, but the test compared it on the positive side, so counter-steer was never applied at all), so all three measurement programs were fixed and every table was taken again. Five things came out of it. (1) The reason is not the three-state steering; it is the car's own recovery limit. Continuous steering does not change it, and neither does making the servo 64x faster (measured back in v7.2.0). The two explanations in the notes are now one. (2) "Cannot beat grip" applies to holding a deep sideslip angle (35 to 60°) inside a corridor that grip driving can geometrically follow. In a tight wall-lined hairpin (8 cases: in 6 of them the corridor's outer radius is under the 5.84 m minimum turning radius, and in the other 2 the radius is sufficient but the car's own body will not fit), grip driving that traces a steady arc fails to complete the 180° in all 16 variations (8 cases x 2 drivetrains; the best-held line reached 121°). Actively sliding, on the other hand, got through 5 of those 8 cases with rear-wheel drive without touching a wall (0.03 to 0.71 m of clearance; all-wheel drive scores 0 of 8 on the same sweep). But the peak sideslip in those runs is only 12 to 15° — a shallow slide — and in none of the 5 was any counter-steer ever applied (the minimum angle the servo actually reached is 0%). So we cannot claim that a deep drift is the only way through, and getting through is not down to fixing the sign either: reverting just the sign to the original bug still gets through. What did the work was how the run is composed and how far the sweep reaches. (3) There is exactly one window in free space where drifting is faster than grip. Sweeping 36 cases found one (tightest radius x low-grip surface x 180° x rear-wheel drive), where the run went from 6.03 s to 5.32 s, 11.9% faster, and it held 3 out of 3 with entry speed varied by ±10% (peak sideslip there is 27°, which is not shallow). Of the remaining 35 cases, four are up to 6.9% faster on a single run but fall apart once entry speed moves by ±10% — what fails there is not speed but robustness. (4) What is fast is the shallow slide. Optimising a trail-braking style of driving beat grip in 7 of 8 cases (by up to 20.6%), and every one of those optima peaked at 14.8° of sideslip or less. Re-running the same search budget under a constraint to slide deeply (peak of 20° or more) produced nothing faster than the shallow optimum in all 16 rows that yielded a solution. In 5 of those 16 the deep solution still beats grip, though, so the accurate statement is not "sliding deeply loses to grip" but "sliding deeply never gets you the fastest time". (5) With two cars on track, turning sideways to block the road makes you slower. The leader's average lap went from 15.78 s to 23.19 s (+47%) and its position went from 582 m ahead to 69 m behind. Descending gradients were re-measured too, across 72 cases, and none of the 72 is faster than grip. What the gradient changes is the mechanism: on a low-grip 180° hairpin, rear-wheel drive spends its whole speed budget on every gradient and drops into a pivot on the spot, whereas all-wheel drive keeps some speed on a 10° descent (minimum speed while sliding is 0.11 to 0.57 m/s on the flat and at 5° — essentially stopped — against 1.67 to 2.04 m/s at 10°). Note that the figures in (3) and (4) come from --full (the systematic sweep, about 30 minutes) of the bundled gate wf_drift_reexam.mjs; the default run (about 2.5 minutes) uses a reduced grid and confirms the same conclusion in a fraction of the time. Every table is also the best result within a finite sweep grid — it means "not found within that grid", and better conditions outside the grid cannot be ruled out. So that none of this has to be argued from impressions again, a permanent automated check, wf_drift_reexam.mjs, now ships with the simulator (the suite goes from 54 to 55 gates). Re-measuring also turned up two mistakes of our own, which are fixed (a unit mismatch in the recovery phase, and counting a car that was rolling backwards as having completed the corner). The physics notes (Japanese and English) and the in-app explanations were rewritten to match, and a machine check was added so the Japanese catalogue and the HTML body cannot drift apart. The driving physics, the tabletop determinism hashes f0-f3, the verifyHash of official records and share URLs are all unchanged.
日本語
「ドリフトはグリップに勝てない」という結論について、その理由と、どこまでの話なのか (適用範囲) を測定し直して是正しました。走行物理は1バイトも変えていません。これまで解説には「勝てない理由」が2通り書かれていて (§11・§13.8 は「操舵が左/中立/右の3値だから」・§13.14 は「車体の回復限界だから」)、しかも「勝てない」がどんな場面についての話なのかが書かれていませんでした。今回、測定に使っていたドリフト走行プログラムの側に逆ハン (カウンター) の符号の取り違えが残っていたことが分かり (横滑り角は左旋回で負になるのに正側で判定していたため、逆ハンが一度も当たっていませんでした)、3本の測定を直して全部取り直しました。分かったことは5つです。①理由は「3値ステアだから」ではなく、車体側の回復限界です。連続舵にしてもサーボを64倍速くしても結果は変わりません (v7.2.0 で実測済)。解説の2通りの説明をこの1つに統一しました。②**「勝てない」と言えるのは、グリップ走行が幾何的に追従できる廊下の中で、深い横滑り角 (35〜60°) を保ったまま走る型についての話です。壁に挟まれたタイトなヘアピン (8ケース。うち6ケースは廊下の外径が最小回転半径 5.84 m を下回り、残る2ケースは外径は足りても車体の外形が収まりません) では、定常円弧をなぞるグリップ走行は 8ケース×2駆動方式＝16通りすべてで180°を回りきれません (いちばん長く保った線でも 121°)。一方、能動的に滑らせる運転なら後輪駆動で8ケース中5ケース、壁に触れずに回りきれました** (壁とのすき間 0.03〜0.71 m。四輪駆動は同じ掃引で 0/8 です)。ただしそのときの横滑り角のピークは12〜15°と浅く、しかも5ケースとも逆ハンを一度も当てていません (サーボが実際に向いた舵角の最小が 0%)。ですから「深いドリフトが唯一の通過手段だ」とは言えませんし、通れるようになったのも符号を直したからではありません (符号だけ元のバグへ戻しても通れます)。効いたのは運転の組み立てと掃引の広げ方のほうです。③自由空間にも、グリップより速いドリフトの窓が1つだけあります。36ケースを掃引して見つかったのは1つ (最もタイトな半径×低μ路面×180°×後輪駆動) で、そこでは 6.03秒→5.32秒＝11.9% 速く、進入速度が±10%ずれても3回中3回成立しました (このときの横滑り角のピークは 27° で、浅くはありません)。残る35ケースのうち4ケースは単発なら最大 6.9% まで速いのですが、進入速度が±10%ずれると崩れます — 落ちているのは速さではなく頑健性です。④速いのは「浅い滑り」です。ブレーキを残して向きを変える型を最適化すると8ケース中7ケースでグリップより速くなりました (最大 20.6%) が、その最適解の横滑り角ピークはすべて 14.8° 以下でした。「深く滑ること (ピーク20°以上)」を条件に同じ予算で探し直すと、解が見つかった16行すべてで浅い解より速くなりません。ただしその16行のうち5行では深い解でもグリップには勝つので、「深く滑るとグリップに負ける」ではなく「深く滑らせても最速にはならない」が正確な言い方です。⑤2台で走ると、横を向いて進路をふさぐ走り方は自分が遅くなります。先頭の平均ラップが 15.78秒→23.19秒 (+47%)、順位も先行 +582 m から −69 m へ落ちました。あわせて下り坂も72ケース取り直しましたが、72ケースすべてでグリップより速くなりません。勾配が変えたのは機序のほうで、低μの180°ヘアピンでは後輪駆動が全勾配で速度を使い切ってその場回頭に落ちるのに対し、四輪駆動は下り10°では速度が残ります (平地〜5°の滑走中の最低速度が 0.11〜0.57 m/s ＝ ほぼ停止なのに対し、10°では 1.67〜2.04 m/s)。なお③④の数値は同梱ゲート wf_drift_reexam.mjs の --full (系統掃引・約30分) の値です。既定実行 (約2.5分) は縮小格子で、同じ結論を短時間に確認します。またどの表も有限の掃引格子の中での最善＝「その格子では見つからなかった」という意味で、格子の外により良い条件がある可能性は排除できません。この取り直しを二度と勘で語らずに済むよう、常設の自動検査 wf_drift_reexam.mjs を追加しました (自動検査は54本→55本)。取り直しの過程では自分たちの測定側の誤りも2つ見つけて直しています (回収フェーズの単位の取り違えと、車が後ろ向きに転がっているのを「完走」と数えていた件)。解説文 (日本語・英語) とアプリ内の物理解説も同じ内容へ書き替え、日本語カタログと HTML の本文がずれていないかを見る機械検査も足しました。走行物理・卓上の決定論ハッシュ f0〜f3・公式記録の verifyHash・共有URL は、すべて不変です。
Verifying this release yourself
cd Simulator
node wf_run_all.mjs # the full assertion-gate suiteThe suite runs from a fresh clone with no dependencies beyond Node.js.
The real-browser checks under Simulator/browser/ additionally need npm install and a display.