orange @[email protected]

「オレゴンから来ました」での雑具合、オレゴン州の気候と文化の多様性でいったら、日本に置き換えたら本州から来ました以上の雑さがあると思う＞＜

なんかC#で普通に内部的なエラー処理なんかでも「例外発生させて、それを受け取って・・・」ってやってたけど、標準の例外処理の負荷を考えたらタプルなり専用の型なりでエラー情報を返す方がいいのか・・・＞＜

Geminiに色々聞いたら「Rustが例外方式じゃなくてResult/Option方式なのは、エラー発生時の処理コストの問題も理由なんですよ」（超意訳）って教えてくれてなるほどなった＞＜（？）

世の中の大量のソフトウェアがオーバーフローからのラップアラウンドでバグるの、システム任せでチェックするとこんなに重いならばいちいち何でもかんでもチェックなんてできないだろうしなるほどかも＞＜；

"値の範囲をint32にしちゃって、内部はint64にすれば..."にしたら、オレンジ版の方が大幅に速くなった＞＜；

System.Int32 ver. Elapsed Time: 1790 ms
Subrange ver. Elapsed Time: 217 ms

もしかして、C#では（？）、高確率でオーバーフローしまくる可能性がある掛け算をする時に、あらかじめ自前でオーバーフローするかどうかをコードで判断できるなら自前で判断をやってでも例外を発生を避けるほうが高速になる場合がある？＞＜；

なんと、オレンジの元の実装でも、int32でcheckedでオーバーフローを空キャッチするコードよりはちょっと高速らしい・・・＞＜；
オーバーフロー時の処理が重いのか＞＜；

値の範囲をint32にしちゃって、内部はint64にすれば、自前の範囲チェックのみで済んでCPU側のラップアラウンドが発生しなくなるからuncheckで計算できて軽くなる・・・？＞＜

原因分かった！＞＜；
checkedブロックの中で掛け算するととんでもなく重い＞＜；

・・・実はnintのほうは、最適化で中身が空になってたりするのかな？＞＜

ちょっといじってみたけど、初期化とかじゃなく、マジでただの掛け算にこの時間のほぼすべてがかかってるっぽい＞＜；

・・・・・・＞＜

かなり前からC#に部分範囲型がない事を嘆く度にわりと馬鹿にされまくってたの、今こそ納得がいかない＞＜

ていうかさっきGeminiにオレンジのアイディアについて聞いたときに、
"""精緻化型（Refinement Types）
Ariane 5の例で出された「部分範囲型」を究極まで突き詰めると、Refinement Types になります。 これは、int などの基本型に $x >= 0 && x < 65536$ のような制約（述語）を付与した型です"""
ってまさにそれが出てきた＞＜

形式検証の簡易版？＞＜

オレンジがやってるのって結局のところ単なるRustの再発明なのかな？＞＜

結局のところ、Rustのエラーハンドリングみたいなのを、こまめにする(Rust)か、後で一気にまとめてする(オレンジが思いついたやつ)かくらいの違いくらいしかない？＞＜；

もしかしてそういうパターンで作れば、言語仕様上の工夫やIDEの支援すらもいらないのかな？＞＜
（でも危ない部分用の型と安全な部分用の型の見分けがつきにくい？＞＜；）