[M3devel] rounding very large magnitude longreal, time, events?

Jay K jay.krell at cornell.edu
Wed Sep 4 19:22:53 CEST 2013


Target.Float is definitely not entire problem, but probably is part of it.
Runtime checks are missing also.

 - Jay


> From: hosking at cs.purdue.edu
> Date: Wed, 4 Sep 2013 12:48:46 -0400
> To: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] rounding very large magnitude longreal, time, events?
> 
> So, what is the precise proposal?  Fix Target.Float to avoid constant folding in these instances?  That seems reasonable to me.
> 
> On Sep 4, 2013, at 12:32 PM, mika at async.caltech.edu wrote:
> 
> > Jay K writes:
> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_
> >> Content-Type: text/plain; charset="iso-8859-1"
> >> Content-Transfer-Encoding: quoted-printable
> >> 
> >>> If I am understanding properly what is going on I think this means your n=
> >> ew
> >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement=
> >> ation.
> >> 
> >> 
> >> I wish=2C but no=2C it is the same as the others.
> > 
> > I see...
> > 
> >> 
> >> 
> >> It is all a bit subtle.
> > 
> > As always...
> > 
> >> 
> > ...
> >> 
> >> 
> >> I believe=2C based on what you are saying=2C
> >> the frontend should generate range checks before
> >> floor/trunc/ceiling.
> >> 
> >> Roughly it should be an error to convert
> >> a float < FIRST(INTEGER) or > LAST(INTEGER) to a double.
> >> Plus or minus one though.
> >> 
> >> 
> >> That is=2C
> >> FLOOR(LAST(INTEGER) + .99999) is ok.
> >> CEILING(FIRST(INTEGER) - .99999) is ok.
> >> ROUND(LAST(INTEGER) - .499999) is ok.
> >> ROUND(FIRST(INTEGER) + .499999) is ok.
> >> =20
> >> 
> >> I'm not sure where "round to even" is=2C so -.5 and +.5 might be ok.
> >> 
> >> 
> >> Oh wait. It depends on the relative ranges of float and integer.
> >> 
> >> 
> >> In particular=2C a 53bit mantissa longreal converted to a 32bit integer
> >> needs the checks I describe. But a 53bit mantissa converted to
> >> a 64bit integer=2C no range check is needed.
> >> 
> >> 
> >> The frontend has some of those optimizations already -- converting
> >> from a smaller range to a larger range needs no check.
> >> 
> >> 
> >> Agreed? Surely this is not a difficult change?
> > 
> > Well, I agree wholeheartedly, yes.
> > 
> >> Nor particularly inefficient?
> >> 
> >> 
> >> 
> >> - Jay
> >> 
> >> 
> >> 
> >> 
> >>> To: jay.krell at cornell.edu
> >>> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C =
> >> events?
> >>> Date: Tue=2C 3 Sep 2013 23:42:12 -0700
> >>> From: mika at async.caltech.edu
> >>> =20
> >>> Jay K writes:
> >>> ...
> >>>> 
> >>>> Ok=3D2C so this is three dilemnas/questions/bugs in one.
> >>>> 
> >>>> 
> >>>> http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith=
> >> met=3D
> >>>> ic_operations.html
> >>>> 
> >>>> 
> >>>> ROUND(r) is the nearest integer to r=3D3B ties are broken according to t=
> >> he co=3D
> >>>> nstant RoundDefault
> >>>> 
> >>>> 
> >>>> 1) How should ROUND be defined? Is Modula-3 adequately safe here?
> >>>> 
> >>>> 
> >>>> What should round of numbers less than FIRST(INTEGER)-1=3D20
> >>>> or greater than LAST(INTEGER) + 1 round to?=3D20
> >>>> 
> >>>> 
> >>>> By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20
> >>>> and LAST(INTEGER). But is it safe?
> >>>> 
> >>> =20
> >>> No=2C I read the definition as saying "integer"=2C not "INTEGER".  That i=
> >> s=2C
> >>> "integer" is the abstract mathematical concept of an integer=2C not the
> >>> Modula-3 data type INTEGER.
> >>> =20
> >>> I think the intent of the Green Book is that INTEGER should be a range-li=
> >> mited
> >>> form of integer=2C that is=2C it should behave like an integer as much as=
> >> possible=2C
> >>> and when the implementation can no longer accomplish that=2C it should si=
> >> gnal a=20
> >>> runtime error.  =20
> >>> =20
> >>> It happens that many existing implementions of Modula-3=2C as an implemen=
> >> tation
> >>> restriction=2C do not handle out-of-range situations correctly.  Things
> >>> such as what you describe SHOULD lead to a runtime error=2C value out of =
> >> range.
> >>> Some implementations wrap instead=2C but I don't even think that's right.=
> >> Of
> >>> course it's not as bad as it might be in C where you might be indexing an
> >>> array with the incorrectly calculated integer and send your program off i=
> >> n
> >>> never-never land.  In Modula-3 you'll at least get a runtime error at THA=
> >> T
> >>> point.  But it's still not right.
> >>> =20
> >>> If I am understanding properly what is going on I think this means your n=
> >> ew
> >>> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement=
> >> ation.
> >>> =20
> >>>     Mika
> >> 		 	   		  =
> >> 
> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_
> >> Content-Type: text/html; charset="iso-8859-1"
> >> Content-Transfer-Encoding: quoted-printable
> >> 
> >> <html>
> >> <head>
> >> <style><!--
> >> .hmmessage P
> >> {
> >> margin:0px=3B
> >> padding:0px
> >> }
> >> body.hmmessage
> >> {
> >> font-size: 12pt=3B
> >> font-family:Calibri
> >> }
> >> --></style></head>
> >> <body class=3D'hmmessage'><div dir=3D'ltr'>&gt=3B If I am understanding pro=
> >> perly what is going on I think this means your new<br>&gt=3B Modula-3-to-C =
> >> compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=
> >> r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =
> >> bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =
> >> from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=
> >> that can be<br>successfully assigned to this range=2C with or without<br>a=
> >> range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=
> >> ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=
> >> r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=
> >> .<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=
> >> s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=
> >> teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =
> >> systems will fail here.<br>32bit Posix would continue to round to some 32bi=
> >> t integer=2C which would then<br>successfully pass into the identical subra=
> >> nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=
> >> ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=
> >> ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=
> >> nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=
> >> ngreal is target-dependent and knowledge<br>of it should only exist in the =
> >> backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=
> >> s the same since around the early 1980s.<br><br><br><br>I believe=2C based =
> >> on what you are saying=2C<br>the frontend should generate range checks befo=
> >> re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=
> >> br>a float &lt=3B FIRST(INTEGER) or &gt=3B LAST(INTEGER) to a double.<br>Pl=
> >> us or minus one though.<br><br><br>That is=2C<br>&nbsp=3BFLOOR(LAST(INTEGER=
> >> ) + .99999) is ok.<br>&nbsp=3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=
> >> bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br>&nbsp=3BROUND(FIRST(INTEGER)=
> >> + .499999) is ok.<br>&nbsp=3B<br><br>I'm not sure where "round to even" is=
> >> =2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=
> >> ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=
> >> sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=
> >> t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=
> >> ded.<br><br><br>The frontend has some of those optimizations already -- con=
> >> verting<br>from a smaller range to a larger range needs no check.<br><br><b=
> >> r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=
> >> cient?<br><br><br><br>&nbsp=3B- Jay<br><br><br><br><br><div>&gt=3B To: jay.=
> >> krell at cornell.edu<br>&gt=3B Subject: Re: [M3devel] rounding very large magn=
> >> itude longreal=2C time=2C events?<br>&gt=3B Date: Tue=2C 3 Sep 2013 23:42:1=
> >> 2 -0700<br>&gt=3B From: mika at async.caltech.edu<br>&gt=3B <br>&gt=3B Jay K w=
> >> rites:<br>&gt=3B ...<br>&gt=3B &gt=3B<br>&gt=3B &gt=3BOk=3D2C so this is th=
> >> ree dilemnas/questions/bugs in one.<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&g=
> >> t=3B &gt=3Bhttp://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=
> >> _10Arithmet=3D<br>&gt=3B &gt=3Bic_operations.html<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3BROUND(r) is the nearest integer to r=3D3B ties a=
> >> re broken according to the co=3D<br>&gt=3B &gt=3Bnstant RoundDefault<br>&gt=
> >> =3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B1) How should ROUND be defined?=
> >> Is Modula-3 adequately safe here?<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=
> >> =3B &gt=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=
> >> &gt=3B &gt=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>&gt=3B &g=
> >> t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B By the simple definition=3D2C they s=
> >> hould round to FIRST(INTEGER)=3D20<br>&gt=3B &gt=3B and LAST(INTEGER). But =
> >> is it safe?<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B No=2C I read the definiti=
> >> on as saying "integer"=2C not "INTEGER".  That is=2C<br>&gt=3B "integer" is=
> >> the abstract mathematical concept of an integer=2C not the<br>&gt=3B Modul=
> >> a-3 data type INTEGER.<br>&gt=3B <br>&gt=3B I think the intent of the Green=
> >> Book is that INTEGER should be a range-limited<br>&gt=3B form of integer=
> >> =2C that is=2C it should behave like an integer as much as possible=2C<br>&=
> >> gt=3B and when the implementation can no longer accomplish that=2C it shoul=
> >> d signal a <br>&gt=3B runtime error.   <br>&gt=3B <br>&gt=3B It happens tha=
> >> t many existing implementions of Modula-3=2C as an implementation<br>&gt=3B=
> >> restriction=2C do not handle out-of-range situations correctly.  Things<br=
> >>> &gt=3B such as what you describe SHOULD lead to a runtime error=2C value o=
> >> ut of range.<br>&gt=3B Some implementations wrap instead=2C but I don't eve=
> >> n think that's right.  Of<br>&gt=3B course it's not as bad as it might be i=
> >> n C where you might be indexing an<br>&gt=3B array with the incorrectly cal=
> >> culated integer and send your program off in<br>&gt=3B never-never land.  I=
> >> n Modula-3 you'll at least get a runtime error at THAT<br>&gt=3B point.  Bu=
> >> t it's still not right.<br>&gt=3B <br>&gt=3B If I am understanding properly=
> >> what is going on I think this means your new<br>&gt=3B Modula-3-to-C compi=
> >> ler is the most reasonably behaving Modula-3 implementation.<br>&gt=3B <br>=
> >> &gt=3B      Mika<br></div> 		 	   		  </div></body>
> >> </html>=
> >> 
> >> --_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/e69d7b8a/attachment-0002.html>


More information about the M3devel mailing list