アカウント名:
パスワード:
>「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とする
「とりあえず31ビットの二進数の桁あふれ」という説明で良いんじゃないの?残りの1ビットはどこへいった?と聞いてくる人がいたら、それは符号ビットだよと答えれば良いし、そう質問する人はそういう説明を理解出来る人だろうからそれでいいでしょ
あるいは実行時エラーでプログラムを停止する可能性もありますね。実際、規格上はゼロ除算の結果も「未定義」で、古いAndroidはゼロ除算でエラーを起こさず黙って間違った結果のまま実行を続けたりしてくれましたが規格上は完全に合法です。
まさに「エラー」ではなく「例外」ですからね.
「例外」を意識するのって組み込みやドライバでは普通だと思いますが, アプリケーションプログラムだと, せいぜい浮動小数点例外ぐらいでしょうか.
そんな人にはぜひ片手で31まで数える方法を教えてあげてください#まあ、31人以下の人員点呼などをする時には役立つだろう。。。。。。。。
片手で23(親指がMSBなら29)を表してみろ。机上の空論だってわかるから
薬指だけを曲げるだけのことでは?できないの?
あれ指を折ったときのビットの意味が反転してた?薬指だけを伸ばすつもりだったんだけど。
別ACだけど、楽器やってたお蔭か普通に0~31まで表現出来るので個人差が有るかと。
薬指だけを「完全に」伸ばすのは指の構造上難しいかもしれませんが、薬指の根本の関節以外は単独で伸ばせませんか?ビットの識別にはこれで十分だと思います。
円周率およそ3世代もn進数を学校で習ってたっけ?
> 穿孔実施確かにパンチカードは2進数を学ぶのに格好の教材だが…。
いわゆる「ゆとり教育」が導入された時期と、高校に「情報」の授業が導入された時期は一致するね。習っているはず。
あと、「円周率はおよそ3」は別にゆとり教育世代だけの話じゃない。精度が要らないときはおよそ3で計算して素早く概算を得るのは誰だってやってる。
素人はそもそも日付・時刻の表現を「○年○月○日○時○分○秒」でしか考えていないから、「日付・時刻が行あぶれする」という発想は端から無いでしょう。
20年後は状況が変わっていると思うので使えないと思いますが、コンピュータをよく知らない人に今この問題を説明するとしたらこんな感じでしょうか、
~~~~~
パソコン等のコンピュータは1秒単位でカウントする時計を持っていて、普段はそれを日付や時刻に換算して表示している。今のところ、その多くが「0から2,147,483,647」までカウントできるタイプの時計で、0を「1970年1月1日0時0分0秒」として1秒ずつカウントしている。カ
それじゃウチの部長にはムリ「時間を数えている箱があふれる」「プログラムをあたらしくする必要がある」これが限界
そもそもtime_tが、なんで符号付き整数なのが理解できないんだが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
ある程度の専門知識を必要とする (スコア:0)
>「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とする
「とりあえず31ビットの二進数の桁あふれ」という説明で良いんじゃないの?
残りの1ビットはどこへいった?と聞いてくる人がいたら、それは符号ビットだよと答えれば良いし、そう質問する人はそういう説明を理解出来る人だろうからそれでいいでしょ
Re:ある程度の専門知識を必要とする (スコア:4, 参考になる)
time_t t = foo + bar;
などとやった場合、コンパイラは「foo + barは、MAX_INT以下である」という前提でコンパイルしても良いことになっています。 「C言語 未定義動作 バグ」ぐらいでWebを検索するといろいろ具体例が出てきますが、例えばこれ [intransient.info]とか。
time_t tomorrow = now + 60*60*24; //現在時刻nowから、丁度1日後の日時を求める
if(tomorrow < now) {// 足してるのに小さくなっていると言うことはオーバーフローしたはず! 2038年問題!
//対処コード
}
とか書くと、コンパイラは「正の整数を足してるんだから、値が小さくなるはずがない。C言語の規約で、オーバーフローするような計算はしちゃいかんことになっているから、オーバーフローが原因で負になる可能性も無い。よって、このif文の条件は常に非成立。if文の中身と条件判定を削除して高速化できるぜやっほー」、とやっても良かったりします。
なので、ぱっと見に分かりにくいバグをはらんでたり、対処したつもりが何故か利かなかったりする可能性があります。 ややこしいので「その最適化はするな」というコンパイラオプションもあるので、とりあえずそれをONにして回った方がいいでしょうね。
# ここまでintのオーバーフローが注目を集めたら、「これが未定義動作ってひどくね?」という方向へも話が飛び火したりしないのかな。
Re: (スコア:0)
あるいは実行時エラーでプログラムを停止する可能性もありますね。
実際、規格上はゼロ除算の結果も「未定義」で、古いAndroidはゼロ除算でエラーを起こさず黙って間違った結果のまま実行を続けたりしてくれましたが規格上は完全に合法です。
Re:ある程度の専門知識を必要とする (スコア:1)
まさに「エラー」ではなく「例外」ですからね.
「例外」を意識するのって組み込みやドライバでは普通だと思いますが, アプリケーションプログラムだと, せいぜい浮動小数点例外ぐらいでしょうか.
Re:ある程度の専門知識を必要とする (スコア:1)
その説明で一般大衆、経営者、政治家などに通じないから懸念があるわけでしょ。ここを見てるような人にとってはそりゃ常識の範囲内でしょうけど、「31ビットの二進数」ってあたりですでに「ある程度の専門知識」ですから。
Re: (スコア:0)
そんな人にはぜひ片手で31まで数える方法を教えてあげてください
#まあ、31人以下の人員点呼などをする時には役立つだろう。。。。。。。。
Re: (スコア:0)
片手で23(親指がMSBなら29)を表してみろ。机上の空論だってわかるから
Re: (スコア:0)
薬指だけを曲げるだけのことでは?
できないの?
Re: (スコア:0)
あれ指を折ったときのビットの意味が反転してた?
薬指だけを伸ばすつもりだったんだけど。
Re: (スコア:0)
別ACだけど、楽器やってたお蔭か普通に0~31まで表現出来るので個人差が有るかと。
Re: (スコア:0)
薬指だけを「完全に」伸ばすのは指の構造上難しいかもしれませんが、
薬指の根本の関節以外は単独で伸ばせませんか?ビットの識別にはこれで十分だと思います。
Re: (スコア:0)
円周率およそ3世代もn進数を学校で習ってたっけ?
Re:ある程度の専門知識を必要とする (スコア:2)
Re: (スコア:0)
> 穿孔実施
確かにパンチカードは2進数を学ぶのに格好の教材だが…。
Re: (スコア:0)
いわゆる「ゆとり教育」が導入された時期と、高校に「情報」の授業が導入された時期は一致するね。
習っているはず。
あと、「円周率はおよそ3」は別にゆとり教育世代だけの話じゃない。
精度が要らないときはおよそ3で計算して素早く概算を得るのは誰だってやってる。
説明を考えてみた (スコア:0)
素人はそもそも日付・時刻の表現を「○年○月○日○時○分○秒」でしか考えていないから、
「日付・時刻が行あぶれする」という発想は端から無いでしょう。
20年後は状況が変わっていると思うので使えないと思いますが、
コンピュータをよく知らない人に今この問題を説明するとしたら
こんな感じでしょうか、
~~~~~
パソコン等のコンピュータは1秒単位でカウントする時計を持っていて、
普段はそれを日付や時刻に換算して表示している。
今のところ、その多くが「0から2,147,483,647」までカウントできるタイプの
時計で、0を「1970年1月1日0時0分0秒」として1秒ずつカウントしている。
カ
Re: (スコア:0)
それじゃウチの部長にはムリ
「時間を数えている箱があふれる」
「プログラムをあたらしくする必要がある」
これが限界
Re: (スコア:0)
そもそもtime_tが、なんで符号付き整数なのが理解できないんだが。
Re: (スコア:0)