Re: A Level 2 query
As I said a couple years ago, the standard should allow multiple modes. In the mandatory one, an implementation shall evaluate each _expression_ as literally as possible. In optional modes, it may provide more accuracy (even if slower), more speed (even if less accurate), more debuggability, or other tradeoffs. An implementation using 80 bit extended precision should be allowed and would have a competitive advantage on precision, but if the standard or the program specifies double precision then there must be a way to get that.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
John Pryce ---06/10/2013 03:53:06 AM---Jürgen On 9 Jun 2013, at 19:58, Jürgen Wolff von Gudenberg wrote:
![]()
| ![]()
John Pryce <j.d.pryce@xxxxxxxxxx> |
![]()
| ![]()
Ian McIntosh/Toronto/IBM@IBMCA |
![]()
| ![]()
06/10/2013 03:53 AM |
![]()
| ![]()
Re: A Level 2 query |
Jürgen
On 9 Jun 2013, at 19:58, Jürgen Wolff von Gudenberg wrote:
> isn't that the problem with the extended 80bit format in the early processors ?
> AFAIK this has only caused some inconsistencies like due to double rounding. thre tightst enclosure is not found.
> so my answer is yes [(JDP) I assume you mean it should be a violation of 1788.]
That was in floating point, where inconsistencies (between compilers, or between optimisation levels of one compiler) can be extremely annoying. With intervals, you have containment and the effect, especially if done throughout a long _expression_, will be to get a tighter enclosure than you "expected". Is that really so annoying? Actually I tend to agree with you and am playing devil's advocate.
John
> Am 09.06.2013 17:31, schrieb John Pryce:
>> ...E.g., let T be infsup-binary32, and T' be infsup-binary64, and the operation be subtraction. Then suppose, in obvious notation,
>> xx_32 - yy_32 always gives zz_64.
>>
>> In fact as these are both 754-conforming types of radix 2 -- call these "nice" types -- any combination is allowed (the "typeOf" feature on the lines of "formatOf" in 754), so the current rules say there shall be an
>> xx - yy whose inputs may be any combination of nice types, giving result of type T.
>> Also
>> xx - yy whose inputs may be any combination of nice types, giving result of type T'.
>>
>> Suppose the implementation only provides the second of these. (If one wants the first, get it by taking the T-hull explicitly.) Should the standard call this non-conforming?

