2018年11月26日月曜日

Guru: When Is An Error Not An Error? November 26, 2018 Jon Paris

Guru: When Is An Error Not An Error?

November 26, 2018 

When is an error not an error? When it is expected! In this article I want to discuss the use of RPG’s MONITOR op-code and discuss ways in which it might change the way you code RPG. I was prompted to write up my thoughts on this subject as a result of being quizzed by students at a recent RPG & DB2 Summit as to why I was using Monitor blocks rather than more conventional RPG techniques in my examples.
So what do I mean by expected? Basically I mean those errors that you know are going to happen sometimes and that you can hopefully do something about. For example, an error caused by a record lock that could be handled by triggering a retry. Or a divide by zero error could result in a sensible default value being used to allow processing to continue.
Before I get into the discussing Monitor though, there is a point I would like to make about my general philosophy on error handling. In my opinion, there is NEVER a valid excuse for a program to display to a user the “green screen of death.” You know, the one with the options to Cancel, Dump, etc. Or at least they should never see it until after you have put out a “pretty” screen explaining the error. I feel that error handling in RPG is a much neglected art, so much so that, together with my colleagues Susan Gantner and Paul Tuohy, some years ago I authored the IBM Redpiece “RPG: Exception and Error Handling.” If you really want to understand your RPG error handling options check it out. OK, I’ll get off the soapbox now and get back to the article.

The MONITOR Op-code

While many different methods of error handling are available in RPG, MONITOR is probably the least-used member of the family. In part this may be because it is a relatively recent addition to the language. But it may also be because people fail to realize the benefits it offers in terms of program readability.
Monitor allows us to react to errors rather than have to attempt to pre-empt them. Take the EVAL op-code for example. It has no provision for an error (E) extender, consequently division by zero, or numeric overflow, among others, will normally result in a terminal error. In the past the only way to deal with that was to pre-emptively attempt to ensure that the condition could not occur. The same thing applies when we have to convert character or numeric strings to dates, or extract a substring from another string, or. . . . As a result we may encounter code like this:
If totalQuantity = 0;
   averagePrice = 0;
Else;
   averagePrice = totalSales / totalQuantity;
EndIf;
Test(DE) *MDY charDate;
If %Error;
   realDate = *LoVal;
Else;
   realDate = %Date(charDate: *mdy);
EndIf;
Now that you have looked at that code, a couple of questions for you. In the case of the first test, is the programmer expecting the value to be zero? In this case, given the names of the variable and the subsequent calculation, you could reasonably guess that the norm in fact is a non-zero condition. And that in turn would make an old programmer like me grit their teeth and wonder why the programmer did not test for greater than zero so that the expected condition came first . . . but I digress.
Same question for the second example. Is it normal for charDate to contain an invalid date? Probably not, but we don’t know from the code. Of course we could always rely on the ever accurate comments in the code to tell us, if we’re lucky enough to have any of course.
One thing I can pretty much guarantee you is that at least one of the two tests will have change flags against it indicating that it was added to the program at some time, probably after some poor user suffered the green screen of death!
Now let’s look at the same logic written to use Monitor.
Monitor;
   averagePrice = totalSales / totalQuantity;
On-Error;
   averagePrice = 0;
End-Mon; 

Monitor;
   realDate = %Date(charDate: *mdy);
On-Error;
   realDate = *LoVal;
End-Mon;
Doesn’t that make things a lot clearer? Now you know exactly what the original programmer expected to happen. You also know exactly how they handled anticipated errors.
Notice any similarity with the way you program in CL? In CL we normally attempt an operation and then use MONMSG to react to any errors that are triggered. Think of Monitor as giving us that same flexibility in RPG!
Another nice feature of Monitor is that we can control exactly which errors we want to handle. In fact I would normally have coded the first of the examples more like this:
Monitor;
   averagePrice = totalSales / totalQuantity;
On-Error errDivZero;
   averagePrice = 0;
End-Mon;
Where errDivZero is a constant defined like this:
Dcl-C errDivZero  00102;  // Attempt to divide by zero
In practice, this constant would have been included via a /Copy of the standard set of status code values that I use in most programs.
Why do it this way? Because divide by zero isn’t the only potential error that could occur here. The code could have, for example, triggered a numeric overflow error. Should that have occurred in the first Monitor version, then processing would have continued using the default value. This happens because an On-error op-code with no qualification traps any and all errors. And that probably would not have been a good thing to do.
By specifying only the statuses that I am prepared to handle I am assured that RPG’s default error handling will be triggered in the event that any unexpected error occurs. And of course that would result in the PSSR being called to log the error, notify the user, capture the current screen image, and . . . . You do always include such a standard PSSR, don’t you? If not, then you really should read the Redpiece I referenced earlier!
Another reason I like using the Monitor approach is that it is generally more efficient — particularly if the majority of the time the error will not be triggered. Perhaps we only get one invalid date in every 10,000 records. The Test/If combination would have to be applied to 9,999 records to no effect. On the other hand we can simply invoke Monitor to set up the error monitoring and that is a much less resource intensive operation.

Other Monitor Options

In addition to being able to trap specific error statuses, On-Error allows for the use of two special values. Actually there are three if you count *ALL but since that is the same as not coding anything I’ll ignore it for now.
The first value is *PROGRAM. This covers all status codes from 00100 to 00999. The second is *FILE which, as you’ve probably guessed, covers all the file-related status codes, from 01000 to 09999. I have used these from time and coded conditional logic based on specific status codes. Usually such a routine would default to calling the PSSR routine if the error is not one I can handle. In general though I usually code On-error blocks for the specific errors I can process, and leave the default handler to catch anything I had not anticipated.

Summary

MONITOR is a terrific and underutilized addition to the RPG language. I hope in this tip I have encouraged you to try it. Not just because it will improve your error handling abilities, but because of the contribution it can make to making your code more understandable.
RELATED STORY
Jon Paris is one of the world’s foremost experts on programming on the IBM i platform. A frequent author, forum contributor, and speaker at user groups and technical conferences around the world, he is also an IBM Champion and a partner at Partner400 and System i Developer. He hosts the RPG & DB2 Summit twice per year with partners Susan Gantner and Paul Tuohy.https://www.itjungle.com/2018/11/26/guru-when-is-an-error-not-an-error/

ゼロ除算の発見は日本です：
∞？？？    
∞は定まった数ではない・
人工知能はゼロ除算ができるでしょうか：

とても興味深く読みました：2014年2月2日　4周年を超えました：
ゼロ除算の発見と重要性を指摘した：日本、再生核研究所


ゼロ除算関係論文・本

ダ・ヴィンチの名言 格言｜無こそ最も素晴らしい存在
                      

ゼロ除算の発見はどうでしょうか：
Black holes are where God divided by zero：

再生核研究所声明371（2017.6.27）ゼロ除算の講演―　国際会議　
https://ameblo.jp/syoshinoris/entry-12287338180.html

1/0=0、0/0=0、z/0=0
http://ameblo.jp/syoshinoris/entry-12276045402.html
1/0=0、0/0=0、z/0=0
http://ameblo.jp/syoshinoris/entry-12263708422.html
1/0=0、0/0=0、z/0=0
http://ameblo.jp/syoshinoris/entry-12272721615.html
Division By Zero（ゼロ除算）1/0=0、0/0=0、z/0=0
ゼロ除算（ゼロじょざん、division by zero）1/0=0、0/0=0、z/0=0

ソクラテス・プラトン・アリストテレス　その他
https://ameblo.jp/syoshinoris/entry-12328488611.html

ドキュメンタリー 2017: 神の数式 第２回 宇宙はなぜ生まれたのか
https://www.youtube.com/watch?v=iQld9cnDli4
〔NHKスペシャル〕神の数式 完全版 第3回 宇宙はなぜ始まったのか
https://www.youtube.com/watch?v=DvyAB8yTSjs&t=3318s
〔NHKスペシャル〕神の数式 完全版 第1回 この世は何からできているのか
https://www.youtube.com/watch?v=KjvFdzhn7Dc
NHKスペシャル 神の数式 完全版 第4回 異次元宇宙は存在するか
https://www.youtube.com/watch?v=fWVv9puoTSs

再生核研究所声明 411(2018.02.02): 　ゼロ除算発見4周年を迎えて
https://ameblo.jp/syoshinoris/entry-12348847166.html

再生核研究所声明 416(2018.2.20): 　ゼロ除算をやってどういう意味が有りますか。何か意味が有りますか。何になるのですか　－　回答
再生核研究所声明 417(2018.2.23): 　ゼロ除算って何ですか　－　中学生、高校生向き　回答
再生核研究所声明 418(2018.2.24): 　割り算とは何ですか？　ゼロ除算って何ですか　－　小学生、中学生向き　回答
再生核研究所声明 420(2018.3.2): ゼロ除算は正しいですか，合っていますか、信用できますか　－　回答

2018.3.18．午前中　最後の講演：　日本数学会　東大駒場、函数方程式論分科会　講演書画カメラ用　原稿
The Japanese Mathematical Society, Annual Meeting at the University of Tokyo. 2018.3.18.
https://ameblo.jp/syoshinoris/entry-12361744016.html より
9月18日（火） 14:10～15:00
和算とゼロ除算
齋藤三郎・奥村 博
京都大学数理解析研究所 111 号室
（講演精神・要旨）

https://note.mu/ysaitoh/n/n1d38a681644f


再生核研究所声明 424(2018.3.29): 　レオナルド・ダ・ヴィンチとゼロ除算
再生核研究所声明 427(2018.5.8): 神の数式、神の意志　そしてゼロ除算

Title page of Leonhard Euler, Vollständige Anleitung zur Algebra, Vol. 1 (edition of 1771, first published in 1770), and p. 34 from Article 83, where Euler explains why a number divided by zero gives infinity.
私は数学を信じない。　アルバート・アインシュタイン / I don't believe in mathematics. Albert Einstein→ゼロ除算ができなかったからではないでしょうか。
1423793753.460.341866474681。                            

Einstein's Only Mistake: Division by Zero
神の数式：
神の数式が解析関数でかけて居れば、　特異点でローラン展開して、正則部の第1項を取れば、　何時でも有限値を得るので、　形式的に無限が出ても　実は問題なく　意味を有します。
物理学者如何でしょうか。

 https://plaza.jp.rakuten-static.com/img/user/diary/new.gif
カテゴリ：カテゴリ未分類
​そこで、計算機は何時、1/0=0　ができるようになるでしょうか。　楽しみにしています。　もうできる進化した　計算機をお持ちの方は　おられないですね。
これは凄い、面白い事件では？　計算機が人間を超えている　例では？

面白いことを発見しました。　計算機は 正しい答え 0/0=0
を出したのに、　この方は　間違いだと　言っている、思っているようです。
0/0=0　は　１３００年も前に　算術の発見者によって与えられたにも関わらず、世界史は間違いだと　とんでもないことを言ってきた。　世界史の恥。　実は　a/0=0　が　何時も成り立っていた。　しかし、ここで　分数の意味を　きちんと定義する必要がある。　計算機は、その意味さえ知っているようですね。　計算機、人間より賢くなっている　様が　出て居て　実に　面白い。
https://steemkr.com/utopian-io/@faisalamin/bug-zero-divide-by-zero-answers-is-zero
２０１８．１０．１１．１１：２３
カテゴリ：カテゴリ未分類
​
面白いことを発見しました。　計算機は 正しい答え 0/0=0
を出したのに、　この方は　間違いだと　言っている、思っているようです。
0/0=0　は　１３００年も前に　算術の発見者によって与えられたにも関わらず、世界史は間違いだと　とんでもないことを言ってきた。　実は　a/0=0　が　何時も成り立っていた。しかし、ここで　分数の意味を　きちんと定義する必要がある。　計算機は、その意味さえ知っているようですね。　計算機、人間より賢くなっている様が　出て居て　実に面白い。

 
https://steemkr.com/utopian-io/@faisalamin/bug-zero-divide-by-zero-answers-is-zero
２０１８．１０．１１．１１：２３

ゼロ除算、ゼロで割る問題、分からない、正しいのかなど、　良く理解できない人が　未だに　多いようです。そこで、簡潔な一般的な　解説を思い付きました。　もちろん、学会などでも述べていますが、　予断で　良く聞けないようです。まず、分数、a/b は　a 　割る b　のことで、これは　方程式 b x=a　の解のことです。ところが、　b　がゼロならば、　どんな　xでも　0 x =0　ですから、a　がゼロでなければ、解は存在せず、　従って　100/0　など、ゼロ除算は考えられない、できないとなってしまいます。　普通の意味では　ゼロ除算は　不可能であるという、世界の常識、定説です。できない、不可能であると言われれば、いろいろ考えたくなるのが、人間らしい創造の精神です。　基本方程式　b x=a　が　b　がゼロならば解けない、解が存在しないので、困るのですが、このようなとき、従来の結果が成り立つような意味で、解が考えられないかと、数学者は良く考えて来ました。　何と、　そのような方程式は　何時でも唯一つに　一般化された意味で解をもつと考える　方法があります。　Moore-Penrose　一般化逆の考え方です。　どんな行列の　逆行列を唯一つに定める　一般的な　素晴らしい、自然な考えです。その考えだと、　b　がゼロの時、解はゼロが出るので、　a/0=0　と定義するのは　当然です。　すなわち、この意味で　方程式の解を考えて　分数を考えれば、ゼロ除算は　ゼロとして定まる　ということです。ただ一つに定まるのですから、　この考えは　自然で、その意味を知りたいと　考えるのは、当然ではないでしょうか？初等数学全般に影響を与える　ユークリッド以来の新世界が　現れてきます。
ゼロ除算の誤解は深刻：

最近、3つの事が在りました。

私の簡単な講演、相当な数学者が信じられないような誤解をして、全然理解できなく、目が回っているいるような印象を受けたこと、
相当ゼロ除算の研究をされている方が、基本を誤解されていたこと、1/0　の定義を誤解されていた。
相当な才能の持ち主が、連続性や順序に拘って、４年以上もゼロ除算の研究を避けていたこと。

これらのことは、人間如何に予断と偏見にハマった存在であるかを教えている。
​まずは　ゼロ除算は不可能であるの　思いが強すぎで、初めからダメ、考えない、無視の気持ちが、強い。　ゼロ除算を従来の　掛け算の逆と考えると、不可能であるが　証明されてしまうので、割り算の意味を拡張しないと、考えられない。それで、　1/0,0/0,z/0　などの意味を発見する必要がある。　それらの意味は、普通の意味ではないことの　初めの考えを飛ばして　ダメ、ダメの感情が　突っ走ている。　非ユークリッド幾何学の出現や天動説が地動説に変わった世界史の事件のような　形相と言える。
２０１８．９．２２．６：４１
ゼロ除算の４つの誤解：
１．      ゼロでは割れない、ゼロ除算は　不可能である　との考え方に拘って、思考停止している。　普通、不可能であるは、考え方や意味を拡張して　可能にできないかと考えるのが　数学の伝統であるが、それができない。
２．      可能にする考え方が　紹介されても　ゼロ除算の意味を誤解して、繰り返し間違えている。可能にする理論を　素直に理解しない、　強い従来の考えに縛られている。拘っている。
３．      ゼロ除算を関数に適用すると　強力な不連続性を示すが、連続性のアリストテレス以来の　連続性の考えに囚われていて　強力な不連続性を受け入れられない。数学では、不連続性の概念を明確に持っているのに、不連続性の凄い現象に、ゼロ除算の場合には　理解できない。
４．      深刻な誤解は、ゼロ除算は本質的に定義であり、仮定に基づいているので　疑いの気持ちがぬぐえず、ダメ、怪しいと誤解している。数学が公理系に基づいた理論体系のように、ゼロ除算は　新しい仮定に基づいていること。　定義に基づいていることの認識が良く理解できず、誤解している。
George Gamow (1904-1968) Russian-born American nuclear physicist and cosmologist remarked that "it is well known to students of high school algebra" that division by zero is not valid; and Einstein admitted it as {\bf the biggest blunder of his life} [1]：1. Gamow, G., My World Line (Viking, New York). p 44, 1970.


Eπi =-1　（1748）（Leonhard Euler）
1/0=0/0=0　（2014年2月2日再生核研究所）

 ゼロ除算（division by zero）1/0=0/0=z/0= tan (pi/2)=0　　https://ameblo.jp/syoshinoris/entry-12420397278.html

1+1=2　　（　　　　　　）
a2+b2=c2　（Pythagoras）
1/0=0/0=0（2014年2月2日再生核研究所）


投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)