アカウント名:
パスワード:
JR東海の発表PDFの2ページ目に、過去に見つかった似た事例が参考資料として上げられていますが。そこでは、
１．判明に至った経緯平成28年5月7日（土）、ＪＲ線（新宿⇔横浜）と相鉄線のＩＣ連絡定期券をお持ちのお客様が、ＪＲ横浜駅から乗車して三島駅の自動精算機で精算した際に、本来であれば定期区間で最も三島駅に近い「横浜駅からの精算」（1,660円）をご案内すべきところ、定期区間の途中駅である「品川駅からの精算」（2,270円）をご案内しておりました。※翌日（5月8日（日））にお客様から三島駅社員にお申し出があり、事象が判明しました。２．発生原因昨年
１．判明に至った経緯平成28年5月7日（土）、ＪＲ線（新宿⇔横浜）と相鉄線のＩＣ連絡定期券をお持ちのお客様が、ＪＲ横浜駅から乗車して三島駅の自動精算機で精算した際に、本来であれば定期区間で最も三島駅に近い「横浜駅からの精算」（1,660円）をご案内すべきところ、定期区間の途中駅である「品川駅からの精算」（2,270円）をご案内しておりました。※翌日（5月8日（日））にお客様から三島駅社員にお申し出があり、事象が判明しました。
２．発生原因昨年
それから、新宿〜横浜って、料金優先なら渋谷乗り換えで東急東横線を挟んで定期取る区間ですよね。JR私鉄乗り継ぎのテストで、高い経路で定期持ってるケースのチェックが不足していたんでしょうね。
しかも横浜から先は相鉄線となると、横浜を経由せずに大和乗り換えで小田急で新宿に行くほうが安い駅も多いですよね。
っていうか、この人、相鉄で乗って三島に行くなら、海老名で小田急に乗り換えて小田原からJRの方が安いんじゃん？？わざわざ横浜に出てからJRに乗ったんですかね。まー、定期を東横じゃなくJRで取ってるのだから、きっと料金よりも乗り換えを減らして時間を優先する人なのでしょうね。
地元なのでAC
昔面白い記事を見たので貼っておきますね。
自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説http://www.publickey1.jp/blog/12/_1040.html [publickey1.jp]
> バグがすり抜けてしまうこともありますが
まあしょうがないか。
今回のように、収受ミスが発生したら都度対応するしかないでしょうね。首都圏は会社をまたぐ相互乗り入れ路線が多く、また定期券での乗り越しが絡むと、最安経路の算出が膨大になってしまいますし。
1円でも高いと、あるいはルールが曖昧だとクレームを付ける利用者がいるのは容易に想像できますが、現状に優る方法が見いだせないです。
時代を巻き戻して、Prologなんぞを使ったルールベースのシステムで処理できないのかね？要はルールが正しければ、数学的に正しい結果が得られることが理論的に保証されるようなシステムを作れないの？（ルールの矛盾も自動的に検証されるとして）
NP困難だから何らかのチートを入れないと現実的な時間で計算できないんじゃね?
まず、運賃規則を正確に機械処理出来る条件の表現形式に落とし込むのが大変。あれ、自然言語で色んな例外事項がどっさり書かれた文書なので、どのぐらいのルール記述の能力を持たせたら全てを正確に書き下せるのかの検討から始めないとダメなレベルで大変。
ついでに、そもそも、運賃規則自体が、頑張って考えて発見した不合理になるような区間には例外を追加して…というような試行錯誤の積み重ねの果てに設計されているようなもんで、それ自体に未発見の穴がある。運賃自動生産システムを作るときにも、その手の穴はいくつか防がれたという。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
過去事例 (スコア:2)
JR東海の発表PDFの2ページ目に、過去に見つかった似た事例が参考資料として上げられていますが。
そこでは、
1を聞いて0を知れ!
テストケースも不足していそう…しかし組み合わせ膨大すぎ (スコア:0)
それから、新宿〜横浜って、料金優先なら渋谷乗り換えで東急東横線を挟んで定期取る区間ですよね。
JR私鉄乗り継ぎのテストで、高い経路で定期持ってるケースのチェックが不足していたんでしょうね。
しかも横浜から先は相鉄線となると、横浜を経由せずに大和乗り換えで小田急で新宿に行くほうが安い駅も多いですよね。
っていうか、この人、相鉄で乗って三島に行くなら、海老名で小田急に乗り換えて小田原からJRの方が安いんじゃん？？
わざわざ横浜に出てからJRに乗ったんですかね。
まー、定期を東横じゃなくJRで取ってるのだから、きっと料金よりも乗り換えを減らして時間を優先する人なのでしょうね。
地元なのでAC
Re:テストケースも不足していそう…しかし組み合わせ膨大すぎ (スコア:1)
昔面白い記事を見たので貼っておきますね。
自動改札機の運賃計算プログラムはいかにデバッグされているのか？
10の40乗という運賃パターンのテスト方法を開発者が解説
http://www.publickey1.jp/blog/12/_1040.html [publickey1.jp]
> バグがすり抜けてしまうこともありますが
まあしょうがないか。
Re:テストケースも不足していそう…しかし組み合わせ膨大すぎ (スコア:1)
今回のように、収受ミスが発生したら都度対応するしかないでしょうね。
首都圏は会社をまたぐ相互乗り入れ路線が多く、また定期券での乗り越しが絡むと、最安経路の算出が膨大になってしまいますし。
1円でも高いと、あるいはルールが曖昧だとクレームを付ける利用者がいるのは容易に想像できますが、現状に優る方法が見いだせないです。
Re: (スコア:0)
時代を巻き戻して、Prologなんぞを使ったルールベースのシステムで処理できないのかね？
要はルールが正しければ、数学的に正しい結果が得られることが理論的に保証されるようなシステムを作れないの？
（ルールの矛盾も自動的に検証されるとして）
Re: (スコア:0)
NP困難だから何らかのチートを入れないと現実的な時間で計算できないんじゃね?
Re: (スコア:0)
まず、運賃規則を正確に機械処理出来る条件の表現形式に落とし込むのが大変。
あれ、自然言語で色んな例外事項がどっさり書かれた文書なので、
どのぐらいのルール記述の能力を持たせたら全てを正確に書き下せるのかの検討から始めないとダメなレベルで大変。
ついでに、そもそも、運賃規則自体が、頑張って考えて発見した不合理になるような区間には例外を追加して…
というような試行錯誤の積み重ねの果てに設計されているようなもんで、それ自体に未発見の穴がある。
運賃自動生産システムを作るときにも、その手の穴はいくつか防がれたという。