Hatena::Grouphaskell

すばらしき functional programming

 | 

2008-07-24合理的な預かり金額(Part2)

やりたいことは「なんとなく」解ってもらえたでしょうか。ただ、これだけでは曖昧すぎます。関数を定義するには、もっとちゃんとしたルールが必要でしょう。

まず、ルール1。

支払の全額は現金によって行う

ことにします。つまり、30円分の割引クーポンや、1050円分のプリペイドカードなどを使った支払は考慮しなくてよいことにします。支払は10000円札、5000円札2000円札1000円札、500円硬貨、100円硬貨、50円硬貨、10円硬貨、5円硬貨、1円硬貨の組み合わせによって行われるものとします。まあ、この制約を加えたところで、レジの付加機能としてまったく意味のないものになるということもないでしょう。

次に、ルール2。

明らかに合理的でない場合のみFalseを返す

つまり、2800円の買い物に対して4000円を出すことはアリです。なぜなら2000円札を2枚出しているかもしれないから。2000円札が存在しなかった場合、4000円は合理的ではありません。最も枚数が少なく支払われた場合でも、1000円札が4枚となり、1000円は最初から出す必要がないからです。紙幣硬貨のさまざまな組み合わせで4000円となっている場合でも、とにかく1000円分はいらないのです。もっとも、このルールがないとすべて1円玉で支払われる可能性を考慮して、1円でも多く支払われたらFalseを返すという面白くもなく役にも立たないプログラムになってしまいます。プログラムは第1種の誤りを犯すことは認められておらず、第2種の誤りを犯すことは認められている、ってことになるのでしょうね。

とくに断わっていませんが、預かり金は金額のみが入力され、紙幣硬貨の枚数の内訳は分からないとします。そんなの実際にレジでいちいち入力していられません。もちろん機械にかけてしまえば出来ないことはありませんが、機械に吸い込まれた1000円札が本当に10000円札ではなかったということをいつも客が納得してくれるかは分かりません。なんでも機械に任せればいいというものでもないようです。

で、結局合理的な預かり金かどうかって、どうやって決められるのでしょう?

[つづく...]

ゲスト



トラックバック - http://haskell.g.hatena.ne.jp/masshie/20080724
 |