| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Arnold Neumaier wrote:
Nate Hayes wrote:Arnold Neumaier wrote:Nate Hayes wrote:Arnold Neumaier wrote:Nate Hayes wrote:Arnold Neumaier wrote:Nate Hayes wrote: > we propose an > alternative, including by Proposition 1 (Motion 18) to make the distinction > between 1/0 and 1/Empty with decorations D_1 and D_0,But your scheme fails to make a distinction between 1+1/0 and 1+1/Empty,so your decorations for this distinction cannot be relied upon in a longer calculation.My scheme reports that both 1+1/0 and 1+1/Empty are ill-formed, as it should be:1/0 is undefined, and 1+undefined is ill-formed (as is 1/Empty).Under these circumstances, what's the point of distinguishing between undefined and ill-formed?A user may want to trap the undefined operation in 1+1/0 to pinpoint the location inside the lengthy computation where the evaluation ceased to be real. Your scheme would not allow this.How does your scheme allow this? There are no traps in the decoration systems, only the final decoration.Of course. But nothing prevents a vendor or implementor from examining the decoration of each operation and invoking some non-P1788 reporting mechanism such as C++ exceptions or a debug trap handler.This would allow evaluation to stop "just in time" so a message can be reported to the user, informing them of exactly where the bad operation was. In a computation involving hundreds or thousands of operations, this could be useful information.This doesn't depend on converting undefined into ill-defined as in your scheme. You can do the same in my scheme, stopping when the first decoration Empty occurs.
Your scheme would also stop on 1/Empty. So it can't single-out the locations in a program where the input operands were real but the result is undefined. So all the possible reasons for empty set as output are lumped together with no way to distinguish them apart.
But it doesn't make sense to label f(0) undefined and g(0) ill-formed, just because your scheme yields this artificial distinction.Well, that is your opinion, and I don't accept it is a fact.In my view, IEEE 1788 is a hardware-oriented computational standard focusing on the individual arithmetic operations, and my scheme provides information that is lost in your scheme.useless, confusing information.In your opinion...Users can safely ignore the distinction if it is not useful to them, as demostrated in the example of Section 5.3 of my paper. So it incurs no penalty to users that may feel the way you do. However, if P1788 standardizes your scheme, users will have no choice, since the relevant information will always be lost.This information will be lostI'm glad you admit your scheme loses the information.Your decoration propagation also loses the information. And the trap handler can recover the wanted information from both versions of the decoration handling. But yours has the additional anomaly about the final decoration.
I don't see it is an anomaly: it is information about what happened during the computation.
D_1 and D_0 are shades of gray of each-other: in both cases the interval result is empty set, but D_1 is a stronger assertion of what did not happen in the computation, namely that no input operand to any operation in the computation was empty.
This is the same as all other decorations: D_2 is stronger assertion of what did not happen in the computation than D_1, D_3 is stronger assertion of what did not happen in the computation than D_2, etc.
but you haven't shown a reason why it is relevant that the information is relevant. If it were relevant in the evaluation of f(0) it surely is also relevant in the evaluation of g(0), where your scheme lost it, too.No. I just showed above an example where it is not lost and could be used constructively in a real-world application.In this sense, my scheme doesn't lose the information either.
No. It still loses the information mentioned above. Nate