アカウント名:
パスワード:
rireki1[100]; rireki2[100];
として、rireki1[99]まで使えば次にrireki2を使用し、rireki2[99]まで使えばrireki1の0~99を合計してrireki1[0]に入れ、rireki1[1]~rireki1[99]は0クリアする。 こうしておけば、積算金額を知りたい時には、全バッファ領域200個sumすれば算出できる。 また、今回利用金額を書き込むべき領域は、現在利用中バッファの金額が0になっている最初の所という条件で知る事ができる。 この手のカードでは、おそらく永久記憶にはフラッシュを使っているので、カウンタや積算金額などを毎回更新すると、特定の領域の書き換え回数が増えてしまい、寿命を縮めてしまうから、毎回特定領域を更新するような処理は避けているのではないかと予想。
この予想が正しければ、積算処理が走るのは200, 299, 398・・・となる。 この積算処理の中で、現在利用金額を保持している領域を破壊するようなバグがあったのかも。 この手の物はリソースが少ないので、RAM領域を使いまわしてたりする事も多いため、間違えて現在利用金額を保持する領域を使ってしまったとか、PICのようにバンク切替をするようなチップでバンクの切替忘れ(切替間違い)があったか・・・
そんな感じなのではないかと。
規則性なら出光のプレスリリースにきっちり書いてありますが。
規則性が出来てしまった理由なら出光のプレスリリースにきっちり書いてありますが。
件のコメントは、タイトルを含めて読むと規則性なら出光のプレスリリースにきっちり書いてありますが。ですよね。
「なら」はどっから来ました?
なぜそうなったのだろう…
出光のプレスリリースにきっちり書いてありますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
規則性 (スコア:0, フレームのもと)
Re:規則性 (スコア:1)
Re:規則性 (スコア:0)
Re:規則性 (スコア:0)
Re:規則性 (スコア:0)
199回までは別カウンタで回ってる? それも変な仕様だな。
やっぱ分からんわこれ。部門名みたいに明示的に200+99*n
とかいう判定条件が実装されてるのかなぁ。
Re:規則性 (スコア:2, 興味深い)
200になると前100個分を保存だかずらすだかして、次に200個使うまでバッファのポインタを前100個目にずらす。
この時にずらす位置を間違って、ずらした後に読込んだの値がずれる。
履歴があるのかどうか、ETCを使ってないから分からん。。。。
Re:規則性 (スコア:1)
次の100回を数えるためのカウンタの初期値だかを間違う。
それで99回目に再度・・・
どうだかな
Re:規則性 (スコア:4, 興味深い)
それを実現するために、2つの100回分の履歴領域を持ち、それを交互に利用する。
100個の領域のうち、最初の一つはバッファが溢れた場合には積算金額を保持する領域として使用。
rireki1[100];
rireki2[100];
として、rireki1[99]まで使えば次にrireki2を使用し、rireki2[99]まで使えばrireki1の0~99を合計してrireki1[0]に入れ、rireki1[1]~rireki1[99]は0クリアする。
こうしておけば、積算金額を知りたい時には、全バッファ領域200個sumすれば算出できる。
また、今回利用金額を書き込むべき領域は、現在利用中バッファの金額が0になっている最初の所という条件で知る事ができる。
この手のカードでは、おそらく永久記憶にはフラッシュを使っているので、カウンタや積算金額などを毎回更新すると、特定の領域の書き換え回数が増えてしまい、寿命を縮めてしまうから、毎回特定領域を更新するような処理は避けているのではないかと予想。
この予想が正しければ、積算処理が走るのは200, 299, 398・・・となる。
この積算処理の中で、現在利用金額を保持している領域を破壊するようなバグがあったのかも。
この手の物はリソースが少ないので、RAM領域を使いまわしてたりする事も多いため、間違えて現在利用金額を保持する領域を使ってしまったとか、PICのようにバンク切替をするようなチップでバンクの切替忘れ(切替間違い)があったか・・・
そんな感じなのではないかと。
Re:規則性 (スコア:0)
2. 溢れたら100個分追加で確保して繋げる。
3. 増やせなかったら機器の寿命という事にして有償交換させる。
4. たっだはずが99個しか追加できてない or 境界判定しくじった
って、こんな低レベルデバイスで動的確保してるとも考えづらいよなぁ..
Re:規則性 (スコア:0)
Re:規則性 (スコア:1)
Re:規則性 (スコア:0)
「池沼の oltio です。」
というシグネチャでもつけてくれってこったね。
Re:規則性 (スコア:0)
Re:規則性 (スコア:0)
Re:規則性 (スコア:1)
> なぜそうなったのだろう…
に対して
> タレコミのリンク先に書いてあるじゃん
とツッコミが入っているように見えたのですが、単に国語力がないだけ?
Re:規則性 (スコア:1)
件のコメントは、タイトルを含めて読むと
ですよね。
rin_penguin氏の予想通りの意味にするには
でないとおかしいのでは。
Re:規則性 (スコア:1)
それこそ、タイトルを「規則性がわかった、って言ったって」本文を「規則性がどんなもんかはリリースの方に書いてあるじゃん」って書けばだいぶ五回は減ると思いますが。
タレコミと編集者のコメントを読んだ後には、大抵の人は「規則性ができた理由はたしかに気になるなあ」と思うのであって、「規則性を、リリースを読む前にタレコミ人の回りくどい表現から編集者が発見したこと」に気付く人はあまりいないでしょう。
だから、後者の「編集者に対する突っ込み」であるとは思いもよらず、前者の「規則性が生じた理由」に対するコメントとして書かれてしまうのも仕方ないと思います。
-- garmy
Re:規則性(既にオフトピ) (スコア:0)
「なら」はどっから来ました?
Re:規則性 (スコア:1)
>などと見当はずれのコメントが2つも付くというのが・・・
# これがどうして見当外れなのか俺にはさっぱりワカラネェ。
「200回以上99回毎」が謎なんじゃなくて、それ自体の理由が謎ななのさ。
200は最初からバッファ確保してるけど、次は100づつ確保したつもりで98し
か確保してないとか?リンクに2つ分使うのでここが潰されるとリンクをたど
れなくなってエラーとかかな。
Re:規則性 (スコア:1)
ソフトウェア工学的には、存在自体が謎でもあります。
何故、こんなバグが残ったまま出荷されたのか。バッファの周回処理部分はバグが出やすいから、常識的には、1回は処理を通している筈。恐らくバッファ100個で、99→100→101は正常に動作したので問題なしと判断したのではないかと思われます。つまり、かなりややこしいバグでしょう。
もし、バッファが200個あるとすると、こんな単純なことすらテストしていない体制の方が大問題です。
-- Buy It When You Found It --
Re:規則性 (スコア:1)
それも十分謎だわな。
>こんな単純なことすらテストしていない体制
いやー。案外多い気もする。
# 最近「技術者育ってねーなー」と思う製品が散見されるし。
Re:規則性 (スコア:0)
違和感があるから「見当違い」のコメントってことに
なるんでしょう。
出光クレジットのページに書いてあることをなんでわざわざ
規則性は「すぐにわかった」なんて書くんでしょうね。
と、思いながらコメントを読み始めれば、どれくらい
見当違いかわかるのでは?
Re:規則性 (スコア:1)
>規則性は「すぐにわかった」なんて書くんでしょうね。
その立場のコメントが見当違いなのはわかるのだが...
「なぜそうなったのだろう…」と繋がらなくなるからな。
# んで、後半の方が重要。
タレコミ文自体が「それ自体の理由」の方を指向してるっつー場に依
存してるからミスリードしやすいのは確かだが。
Re:規則性 (スコア:0)
だからプレスリリースに書いてあろうとなかろうと問題はないわけで、
そこを突っ込むのも分からないし、まして違和感は感じないが。
# 感じるか感じないかは主観だけど、理に反してないから突っ込むところじゃないと思うのです。
Re:規則性 (スコア:1)
それに対して,規則性はプレスリリースに書いてあるとツッコミが入った.
それを読んで,やはりプレスリリースを読んでいない第三者は,「規則性が分かった」に違和感を覚えず,ツッコミが無粋であると感じた.
と,想像.
というか,最初プレスリリースをちゃんと読んでいなかったので,まさにそう感じた.いかんですね.
Re:規則性 (スコア:0)
#誤解には違いないけど…