アカウント名:
パスワード:
2の補数と符号無しの表現がこんがらがって2の補数の-1が符号無しの32768に化けたとか？
言わんとする事はわかるけど、-1なら65535になってないとおかしいでしょう。short型の最小値-32768をint型として評価すると32768になるから、そんなところじゃないかな。
そんなとこでしょうね。エラー標識で負数を使っているとかで、その上一部の機材がエラー標識への対応が甘いみたいな。K-T境界前ならMSBをflagにする実装もよくあったけど今時はそんな事しないでしょうから。
> K-T境界
って何だろう。 「Keio－Teito境界」じゃないよね？
やっぱ地層のあれかね？ファーストインパクトによる大絶滅で生命種が絞られたイベントだから、カンブリア爆発で増えまくった珍妙な生物がきれいさっぱり消え失せてモダンな生物に様変わりしたことにコンピューティング環境の進化と淘汰を比喩してみたんじゃないだろうか。多分、K-T境界前は年号を二桁で管理してるシステムとか、8ビットクリーンじゃなくて日本語通すと文字化けするメールサーバーとかも含まれるんだろう。
int型のbit数を暗に決めつけた考え方は危険です
歴史的経緯で下駄履き（エクセス）表現が使われ続けているのかも。
データベース上では編成数の内部表現が16ビットのエクセス32767になっていて、表示部にデータを渡す前に、32767を減算しておく実装だったり。
で、なぜか編成数に0xFFFFが入っていた。（特殊値かミスオペ）ここから32767を減算すると0x8000 になる。表示部はこれを16ビットでの2の補数として解釈したため、 -32768 になった。そして5文字しか表示幅がない仕様だったので、先頭の - が消えた。「32768」の出来上がり。
って、単にエクセス32767で0xFFFFを解釈するだけで32768だわ。深く考えすぎた。
きっと、合わせ技一本みたいなバグばかり目にしてきたせいだ…
表示側は、1000 0000 0000 0000を単純に符号なし2バイトか4バイト以上の整数として判断した。ってことでしょうけど。
どういう入力や処理の結果として、そのデータになったのかが気になる。
自然数を返す関数のエラーを負数で表す悪習が原因ですかね表示側に渡る前に消すなり回送に置き換えるなりするはずだったのがすり抜けたとか
しかも、マジックナンバーを使っている悪寒が。
C言語なら、unsigned short型の変数にSHRT_MINを代入しちゃったというミスなんでしょうかね。- エラーが発生するとSHRT_MINを返す関数があり、その戻り値をunsigned shortに直接代入していた- 初期化時の値を適当にSHRT_MINにしてあり、当日はエラーのため値が上書きされずそのまま出力されたとかが考えられる気がします。
なんかそれだと探索の初期値っぽい気が。最初の要素で確実に上書きされるはずが、探索対象が空っぽでそのままきちゃったとか。
それなんてFF6のドリル装備・・・
お前は-1両編成を見たことがあるのか？
いつもより短い11両編成なら見たことあります。
それは前者が2両編成で後者は1両編成じゃ……
行き先はホグワーツ
この予想に賛成。ただ、この予想が当たってるなら、型関連のバグを心配しちゃう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
2の補数 (スコア:1)
2の補数と符号無しの表現がこんがらがって2の補数の-1が符号無しの32768に化けたとか？
Re:2の補数 (スコア:5, 参考になる)
言わんとする事はわかるけど、-1なら65535になってないとおかしいでしょう。
short型の最小値-32768をint型として評価すると32768になるから、そんなところじゃないかな。
Re: (スコア:0)
そんなとこでしょうね。
エラー標識で負数を使っているとかで、その上
一部の機材がエラー標識への対応が甘いみたいな。
K-T境界前ならMSBをflagにする実装もよくあったけど
今時はそんな事しないでしょうから。
Re:2の補数 (スコア:1)
> K-T境界
って何だろう。 「Keio－Teito境界」じゃないよね？
Re: (スコア:0)
やっぱ地層のあれかね？
ファーストインパクトによる大絶滅で生命種が絞られたイベントだから、
カンブリア爆発で増えまくった珍妙な生物がきれいさっぱり消え失せてモダンな生物に
様変わりしたことにコンピューティング環境の進化と淘汰を比喩してみたんじゃないだ
ろうか。
多分、K-T境界前は年号を二桁で管理してるシステムとか、8ビットクリーンじゃなくて
日本語通すと文字化けするメールサーバーとかも含まれるんだろう。
オフトピ-3 (スコア:0)
int型のbit数を暗に決めつけた考え方は危険です
内部値が下駄履き表現なんじゃないか？ (スコア:3, 興味深い)
歴史的経緯で下駄履き（エクセス）表現が使われ続けているのかも。
データベース上では編成数の内部表現が16ビットのエクセス32767になっていて、
表示部にデータを渡す前に、32767を減算しておく実装だったり。
で、なぜか編成数に0xFFFFが入っていた。（特殊値かミスオペ）
ここから32767を減算すると0x8000 になる。
表示部はこれを16ビットでの2の補数として解釈したため、 -32768 になった。
そして5文字しか表示幅がない仕様だったので、先頭の - が消えた。
「32768」の出来上がり。
Re:内部値が下駄履き表現なんじゃないか？ (スコア:3, すばらしい洞察)
って、単にエクセス32767で0xFFFFを解釈するだけで32768だわ。
深く考えすぎた。
きっと、合わせ技一本みたいなバグばかり目にしてきたせいだ…
Re:2の補数 (スコア:1)
表示側は、
1000 0000 0000 0000
を単純に符号なし2バイトか4バイト以上の整数として判断した。
ってことでしょうけど。
どういう入力や処理の結果として、そのデータになったのかが気になる。
Re: (スコア:0)
自然数を返す関数のエラーを負数で表す悪習が原因ですかね
表示側に渡る前に消すなり回送に置き換えるなりするはずだったのがすり抜けたとか
Re:2の補数 (スコア:2)
しかも、マジックナンバーを使っている悪寒が。
Re: (スコア:0)
C言語なら、unsigned short型の変数にSHRT_MINを代入しちゃったというミスなんでしょうかね。
- エラーが発生するとSHRT_MINを返す関数があり、その戻り値をunsigned shortに直接代入していた
- 初期化時の値を適当にSHRT_MINにしてあり、当日はエラーのため値が上書きされずそのまま出力された
とかが考えられる気がします。
Re: (スコア:0)
なんかそれだと探索の初期値っぽい気が。
最初の要素で確実に上書きされるはずが、探索対象が空っぽでそのままきちゃったとか。
Re: (スコア:0)
それなんてFF6のドリル装備・・・
Re:2の補数 (スコア:1)
お前は-1両編成を見たことがあるのか？
Re:2の補数 (スコア:4, おもしろおかしい)
Re: (スコア:0)
いつもより短い11両編成なら見たことあります。
Re: (スコア:0)
Re: (スコア:0)
それは前者が2両編成で後者は1両編成じゃ……
Re: (スコア:0)
行き先はホグワーツ
Re: (スコア:0)
この予想に賛成。ただ、この予想が当たってるなら、型関連のバグを心配しちゃう。