  |
はてなキーワード: 処理系とは
1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。
年数を下2桁だけで処理していたシステムや、2000年を平年(閏年ではない)と誤解したシステムに問題が起こる。
1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」(閏年処理)、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)
1930年 - 2029年を下2桁で表現しているシステムに問題が起こる。同様のものに2050年問題や2070年問題などがある。
1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。
Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)
HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
1950年 - 2049年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2070年問題などがある。
1970年 - 2069年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2050年問題などがある。
FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。
2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。
FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。
2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。
Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。
業界20年目だけど、まるで成長してない（安西先生）って感じる事ばかり
20年もこんなマッチポンプに付き合わされればそりゃ愛想も付きますわ
一部のプログラミング大好きサーバー大好きっ子はその手の仕事が好きなのかもしんないけどこっちはそんなことしたくねーよ
なんでプログラミング言語や処理系のケアまでなんでこっちがしなきゃいけないの？アップデートに付き合わされなきゃいけないの？
自分の要望・目的をしたいことリストアップ言語かなんかに書いておいて、実現する技術はその時々で最適なものを選定してくれませんか？
したい事は変わらないのにプログラミング言語やらOSがアップデートされたので開発をやり直します！ってあきれて物も言えないわｗｗ
当時ドヤ顔で、標準関数のrand()を使ってるからって指摘してる連中多かったな。
大昔に書かれたC FAQってドキュメントに、rand()は質が悪いって書かれてる影響でだろう。
でもカルドセプトの事件が起きたときにはすでに21世紀でそんなrand()の質の悪い処理系なんてなかったはず。
あとだいぶ前に2chのプログラム板を見てたけど、初心者が乱数関係の質問をするたびに、乱数の質が悪いから加工して使えとか、メルセンヌ云々でとか言う連中が常駐してたな。
でもその初心者に教えてる乱数を加工するコードがバグってたりするの。
みたいな言い回しをよく見かけるけれど, 日常のやりとりではまず出てこないような独特な言い回しだよなーと大変興味深い. (「これ」という言葉の使い方とか)
おそらく, この手の文章はできるだけ解釈が一意に定まる (読み方によって解釈がブレない) 表現が必要なので, そのための工夫としてこういう形になったんだろうな～.
「解釈が一意に定まる」ことの重要性はプログラミング言語でも同様で, 処理系を実装する場合にもポイントになってくるわけだけど, そういえばこの表現ってプログラミングにおける foreach 文だよなとふと思った.
「A、B、Cについては」という語句で言及している各項目を、「これ」という変数にバインドしている感じ. Javascript 的に書くと
[A, B, C].forEach(これ =＞ { if (○○の場合) 「これ」を実施; });
私も専門家ではありませんがkenokabeさんよりはFRPもよく知っていると思いますし、
kenokabeさんのいうFRPが普通の世界でいうFRPとは全く違うこと、そして
kenokabeさんが決してそれを認めようとしないことはとてもよくわかりました。
言うだけ言うのはただだよねｗ なんもできてないし。
あの、処理系で「現在時刻が」って言いたかっただけのアホな人？
違うわアホ
その__x上の分布は、「処理系が評価する時刻」に従って広がっている。
わかってるよ。そんな難しい言葉だと思ってるのか？
「kenokabeのGUIプログラムも、イベントが起こるたびに変数の値を繰り返し更新してる。」はスルー
もしくは「岡部さんの哲学を理解していない」ですか。まあそうですよね。
もう一回だけまとめると、__x.t=__x.t+1のような単純な例はもちろん、
岡部氏のライブラリは、右辺の評価時間におけるxの値を、左辺の評価時間におけるxの値としてイミュータブルなストリーム上に分布する、という説明になるんだろ？
ライブラリの内部的にはな。まだ内部で破壊的代入してるってゴネてるの？精神病？
ユーザが見ても関数型だが、おまえみたいに命令型のコードかけば、その文脈でも関数型の値が帰ってきたり、定義することができる。
お前自身がすすんで命令型のコード書いてるんだから、その評価時間のズレで「過去の時間」ってのが発生するんだが、命令型コードの意味しってるかい？
言い訳してるのはおまえ。
関数型ライブラリつかって、あからさまな命令型を書いて、命令型だ！って言われてもな。馬鹿だろ？
方程式の左右の評価時間が違う処理系ならば、岡部氏の説明するとおり、その異なる時間でFRPライブラリが挙動するだけ。
そんなことも理解できないの？
HaskellのIOモナドが「IOアクションを生成する純粋関数型プログラム」なのと同様、
Cのプリプロセッサは「Cプログラムを生成する純粋関数型プログラム」って言ってるのね。
kenokabe氏ははっきりと
http://kenokabe-techwriting.blogspot.jp/2016/05/frp_18.html
残りは全部、使ってるライブラリのソースコードからfrequencyやリフレッシュレートやら、timerの解像度っぽいことをアピールしてるみたいですが、
タイマーの解像度設定しながらマウスイベントを同時にとってなんかやることと、
状態f(0),f(1),f(2),…を得る、という本来のFRPの基本原理
ってまったく違うでしょ？
誤魔化すなと。
状態f(0),f(1),f(2),…を得る
というのはどこだ？とけなされているのだけど、
イベントごとに写像されているのだから、状態f(t)だ、とかいうのなら、
岡部氏の言う時間軸をストリームにする、という話と関係ないのに、
ただ「実際のシステム時刻t=0,1,2,…」って言いたかっただけちゃうんか？ってのは見るものすべてにバレてる誤魔化しだ、って意味でしょ？