<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.ecxapple-converted-space
{mso-style-name:ecxapple-converted-space;}
span.EstiloCorreo19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Hi all:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Jay, type checking is one thing while range checking is another. Range checking is harder than type checking, that’s the point here. If you want range checking with brute
force you get a penalty obviously. If you want integer overflow checking is the same thing, perhaps there could be hope in ESC, I haven’t asked that. DEC Alpha had a special purpose lobotomized AMD64 like architecture perhaps that provided the hardware needed
for that; also see below:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><a href="http://www.google.com/patents/?vid=USPAT6470373"><span style="color:windowtext">http://www.google.com/patents/?vid=USPAT6470373</span></a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thanks in advance<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="ES" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">De:</span></b><span lang="ES" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> jayk123@hotmail.com [mailto:jayk123@hotmail.com]
<b>En nombre de </b>Jay K<br>
<b>Enviado el:</b> Wednesday, 04 de September de 2013 12:49 p.m.<br>
<b>Para:</b> Antony Hosking<br>
<b>CC:</b> m3devel<br>
<b>Asunto:</b> Re: [M3devel] rounding very large magnitude longreal, time, events?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Calibri","sans-serif"">I want both.<br>
<br>
<br>
We check subrange assignments.<br>
This seems almost the same thing.<br>
When a programming converts float to int, what do they accept they are losing?<br>
Precision or range or both?<br>
I wonder if it is only precision they accept they are losing, and the loss of range deserves a runtime check.<br>
<br>
<br>
The tradition of ignoring overflows seems unsafe and against the nature of the language. But in the nature of a more efficient less safe implementation.<br>
<br>
<br>
Perhaps what I miss is the line between type safety and correctness and lack of later runtime errors?<br>
Our obligation is only type safety?<br>
round/trunc/ceiling can return random numbers and still be type safe?<br>
(round converts large positive numbers to FIRST(INTEGER) on I386_NT, seems very dubious...)<br>
<br>
<br>
- Jay<br>
<br>
<o:p></o:p></span></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-family:"Calibri","sans-serif"">
<hr size="2" width="100%" align="center" id="stopSpelling">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Calibri","sans-serif"">Subject: Re: [M3devel] rounding very large magnitude longreal, time, events?<br>
From: <a href="mailto:antony.hosking@gmail.com">antony.hosking@gmail.com</a><br>
Date: Wed, 4 Sep 2013 13:31:01 -0400<br>
CC: <a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a>; <a href="mailto:m3devel@elegosoft.com">
m3devel@elegosoft.com</a><br>
To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">I assume you only want the checks to prevent bad folding, not at run-time. In the tradition that overflows are unchecked.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">On Sep 4, 2013, at 1:00 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Calibri","sans-serif"">> Well, I agree wholeheartedly, yes.<br>
<br>
<br>
Tony: can we put in range checks on float to int conversions?<span class="ecxapple-converted-space"> </span><br>
I'd be ok with initially:<span class="ecxapple-converted-space"> </span><br>
if float < FIRST(INTEGER) - 1 or float > LAST(INTEGER) + 1<span class="ecxapple-converted-space"> </span><br>
error<span class="ecxapple-converted-space"> </span><br>
<br>
The "1" isn't quite right, but "0" is also wrong.<span class="ecxapple-converted-space"> </span><br>
<br>
<br>
I'd like to see what Java and C# do also (safe/optionally safe languages in good standing).<span class="ecxapple-converted-space"> </span><br>
<br>
And then we also have to do something in m3-comm/events to stop it failing on AMD64_NT today and everything else "soon".<br>
<br>
<br>
- Jay<br>
<br>
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">> To:<span class="ecxapple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>
> Date: Wed, 4 Sep 2013 09:32:17 -0700<br>
> From:<span class="ecxapple-converted-space"> </span><a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a><br>
> CC:<span class="ecxapple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>
> Subject: Re: [M3devel] rounding very large magnitude longreal, time, events?<br>
><span class="ecxapple-converted-space"> </span><br>
> Jay K writes:<br>
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_<br>
> >Content-Type: text/plain; charset="iso-8859-1"<br>
> >Content-Transfer-Encoding: quoted-printable<br>
> ><br>
> >> If I am understanding properly what is going on I think this means your n=<br>
> >ew<br>
> >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement=<br>
> >ation.<br>
> ><br>
> ><br>
> >I wish=2C but no=2C it is the same as the others.<br>
><span class="ecxapple-converted-space"> </span><br>
> I see...<br>
><span class="ecxapple-converted-space"> </span><br>
> ><br>
> ><br>
> >It is all a bit subtle.<br>
><span class="ecxapple-converted-space"> </span><br>
> As always...<br>
><span class="ecxapple-converted-space"> </span><br>
> ><br>
> ...<br>
> ><br>
> ><br>
> >I believe=2C based on what you are saying=2C<br>
> >the frontend should generate range checks before<br>
> >floor/trunc/ceiling.<br>
> ><br>
> >Roughly it should be an error to convert<br>
> >a float < FIRST(INTEGER) or > LAST(INTEGER) to a double.<br>
> >Plus or minus one though.<br>
> ><br>
> ><br>
> >That is=2C<br>
> > FLOOR(LAST(INTEGER) + .99999) is ok.<br>
> > CEILING(FIRST(INTEGER) - .99999) is ok.<br>
> > ROUND(LAST(INTEGER) - .499999) is ok.<br>
> > ROUND(FIRST(INTEGER) + .499999) is ok.<br>
> >=20<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 relative ranges of float and integer.<br>
> ><br>
> ><br>
> >In particular=2C a 53bit mantissa longreal converted to a 32bit integer<br>
> >needs the checks I describe. But a 53bit mantissa converted to<br>
> >a 64bit integer=2C no range check is needed.<br>
> ><br>
> ><br>
> >The frontend has some of those optimizations already -- converting<br>
> >from a smaller range to a larger range needs no check.<br>
> ><br>
> ><br>
> >Agreed? Surely this is not a difficult change?<br>
><span class="ecxapple-converted-space"> </span><br>
> Well, I agree wholeheartedly, yes.<br>
><span class="ecxapple-converted-space"> </span><br>
> >Nor particularly inefficient?<br>
> ><br>
> ><br>
> ><br>
> > - Jay<br>
> ><br>
> ><br>
> ><br>
> ><br>
> >> To: <a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>
> >> Subject: Re: [M3devel] rounding very large magnitude longreal=2C time=2C =<br>
> >events?<br>
> >> Date: Tue=2C 3 Sep 2013 23:42:12 -0700<br>
> >> From: <a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a><br>
> >>=20<br>
> >> Jay K writes:<br>
> >> ...<br>
> >> ><br>
> >> >Ok=3D2C so this is three dilemnas/questions/bugs in one.<br>
> >> ><br>
> >> ><br>
> >> ><a href="http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith=" target="_blank">http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arith=</a><br>
> >met=3D<br>
> >> >ic_operations.html<br>
> >> ><br>
> >> ><br>
> >> >ROUND(r) is the nearest integer to r=3D3B ties are broken according to t=<br>
> >he co=3D<br>
> >> >nstant RoundDefault<br>
> >> ><br>
> >> ><br>
> >> >1) How should ROUND be defined? Is Modula-3 adequately safe here?<br>
> >> ><br>
> >> ><br>
> >> > What should round of numbers less than FIRST(INTEGER)-1=3D20<br>
> >> > or greater than LAST(INTEGER) + 1 round to?=3D20<br>
> >> ><br>
> >> ><br>
> >> > By the simple definition=3D2C they should round to FIRST(INTEGER)=3D20<br>
> >> > and LAST(INTEGER). But is it safe?<br>
> >> ><br>
> >>=20<br>
> >> No=2C I read the definition as saying "integer"=2C not "INTEGER". That i=<br>
> >s=2C<br>
> >> "integer" is the abstract mathematical concept of an integer=2C not the<br>
> >> Modula-3 data type INTEGER.<br>
> >>=20<br>
> >> I think the intent of the Green Book is that INTEGER should be a range-li=<br>
> >mited<br>
> >> form of integer=2C that is=2C it should behave like an integer as much as=<br>
> > possible=2C<br>
> >> and when the implementation can no longer accomplish that=2C it should si=<br>
> >gnal a=20<br>
> >> runtime error. =20<br>
> >>=20<br>
> >> It happens that many existing implementions of Modula-3=2C as an implemen=<br>
> >tation<br>
> >> restriction=2C do not handle out-of-range situations correctly. Things<br>
> >> such as what you describe SHOULD lead to a runtime error=2C value out of =<br>
> >range.<br>
> >> Some implementations wrap instead=2C but I don't even think that's right.=<br>
> > Of<br>
> >> course it's not as bad as it might be in C where you might be indexing an<br>
> >> array with the incorrectly calculated integer and send your program off i=<br>
> >n<br>
> >> never-never land. In Modula-3 you'll at least get a runtime error at THA=<br>
> >T<br>
> >> point. But it's still not right.<br>
> >>=20<br>
> >> If I am understanding properly what is going on I think this means your n=<br>
> >ew<br>
> >> Modula-3-to-C compiler is the most reasonably behaving Modula-3 implement=<br>
> >ation.<br>
> >>=20<br>
> >> Mika<br>
> > =<br>
> ><br>
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_<br>
> >Content-Type: text/html; charset="iso-8859-1"<br>
> >Content-Transfer-Encoding: quoted-printable<br>
> ><br>
> ><html><br>
> ><head><br>
> ><style><!--<br>
> >.hmmessage P<br>
> >{<br>
> >margin:0px=3B<br>
> >padding:0px<br>
> >}<br>
> >body.hmmessage<br>
> >{<br>
> >font-size: 12pt=3B<br>
> >font-family:Calibri<br>
> >}<br>
> >--></style></head><br>
> ><body class=3D'hmmessage'><div dir=3D'ltr'>>=3B If I am understanding pro=<br>
> >perly what is going on I think this means your new<br>>=3B Modula-3-to-C =<br>
> >compiler is the most reasonably behaving Modula-3 implementation.<br><br><b=<br>
> >r>I wish=2C but no=2C it is the same as the others.<br><br><br>It is all a =<br>
> >bit subtle.<br><br><br>Here is what I believe happens:<br><br><br>I386_NT: =<br>
> >from any double=2C round will give us<br>some integer=2C a 32bit integer=2C=<br>
> > that can be<br>successfully assigned to this range=2C with or without<br>a=<br>
> > range check.<br><br><br>m3cc: Posix: The values are in range.<br>With or w=<br>
> >ithout a range check=2C the code succeeds.<br>For a "few" more years.<br><b=<br>
> >r><br>C backend: Similar.<br>I'm using the C backend all the time on Darwon=<br>
> >.<br>Again=2C Posix: the values are in range.<br>I386_NT: round will give u=<br>
> >s a 32bit integer and it will "work"<br>AMD64_NT: round gives us a 64bit in=<br>
> >teger=2C the range check fails.<br><br><br>In a "few" years=2C 64bit Posix =<br>
> >systems will fail here.<br>32bit Posix would continue to round to some 32bi=<br>
> >t integer=2C which would then<br>successfully pass into the identical subra=<br>
> >nge -- like I386_NT today.<br><br><br><br>The backends don't add range chec=<br>
> >ks.<br>Mostly or entirely=2C they should not.<br>As long as the frontend kn=<br>
> >ows enough=2C it should do it.<br>The frontend knows the range of INTEGER a=<br>
> >nd at least roughly<br>the range of longreal.<br>Possibly the range of a lo=<br>
> >ngreal is target-dependent and knowledge<br>of it should only exist in the =<br>
> >backend. In reality=2C as long as you ignore VAX=2C<br>roughly everything i=<br>
> >s the same since around the early 1980s.<br><br><br><br>I believe=2C based =<br>
> >on what you are saying=2C<br>the frontend should generate range checks befo=<br>
> >re<br>floor/trunc/ceiling.<br><br>Roughly it should be an error to convert<=<br>
> >br>a float <=3B FIRST(INTEGER) or >=3B LAST(INTEGER) to a double.<br>Pl=<br>
> >us or minus one though.<br><br><br>That is=2C<br> =3BFLOOR(LAST(INTEGER=<br>
> >) + .99999) is ok.<br> =3BCEILING(FIRST(INTEGER) - .99999) is ok.<br>&n=<br>
> >bsp=3BROUND(LAST(INTEGER) - .499999) is ok.<br> =3BROUND(FIRST(INTEGER)=<br>
> > + .499999) is ok.<br> =3B<br><br>I'm not sure where "round to even" is=<br>
> >=2C so -.5 and +.5 might be ok.<br><br><br>Oh wait. It depends on the relat=<br>
> >ive ranges of float and integer.<br><br><br>In particular=2C a 53bit mantis=<br>
> >sa longreal converted to a 32bit integer<br>needs the checks I describe. Bu=<br>
> >t a 53bit mantissa converted to<br>a 64bit integer=2C no range check is nee=<br>
> >ded.<br><br><br>The frontend has some of those optimizations already -- con=<br>
> >verting<br>from a smaller range to a larger range needs no check.<br><br><b=<br>
> >r>Agreed? Surely this is not a difficult change?<br>Nor particularly ineffi=<br>
> >cient?<br><br><br><br> =3B- Jay<br><br><br><br><br><div>>=3B To: jay.=<br>
> ><a href="mailto:krell@cornell.edu">krell@cornell.edu</a><br>>=3B Subject: Re: [M3devel] rounding very large magn=<br>
> >itude longreal=2C time=2C events?<br>>=3B Date: Tue=2C 3 Sep 2013 23:42:1=<br>
> >2 -0700<br>>=3B From: <a href="mailto:mika@async.caltech.edu">mika@async.caltech.edu</a><br>>=3B <br>>=3B Jay K w=<br>
> >rites:<br>>=3B ...<br>>=3B >=3B<br>>=3B >=3BOk=3D2C so this is th=<br>
> >ree dilemnas/questions/bugs in one.<br>>=3B >=3B<br>>=3B >=3B<br>&g=<br>
> >t=3B >=3Bhttp://<a href="http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=" target="_blank">modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6=</a><br>
> >_10Arithmet=3D<br>>=3B >=3Bic_operations.html<br>>=3B >=3B<br>>=<br>
> >=3B >=3B<br>>=3B >=3BROUND(r) is the nearest integer to r=3D3B ties a=<br>
> >re broken according to the co=3D<br>>=3B >=3Bnstant RoundDefault<br>>=<br>
> >=3B >=3B<br>>=3B >=3B<br>>=3B >=3B1) How should ROUND be defined?=<br>
> > Is Modula-3 adequately safe here?<br>>=3B >=3B<br>>=3B >=3B<br>>=<br>
> >=3B >=3B What should round of numbers less than FIRST(INTEGER)-1=3D20<br>=<br>
> >>=3B >=3B or greater than LAST(INTEGER) + 1 round to?=3D20<br>>=3B &g=<br>
> >t=3B<br>>=3B >=3B<br>>=3B >=3B By the simple definition=3D2C they s=<br>
> >hould round to FIRST(INTEGER)=3D20<br>>=3B >=3B and LAST(INTEGER). But =<br>
> >is it safe?<br>>=3B >=3B<br>>=3B <br>>=3B No=2C I read the definiti=<br>
> >on as saying "integer"=2C not "INTEGER". That is=2C<br>>=3B "integer" is=<br>
> > the abstract mathematical concept of an integer=2C not the<br>>=3B Modul=<br>
> >a-3 data type INTEGER.<br>>=3B <br>>=3B I think the intent of the Green=<br>
> > Book is that INTEGER should be a range-limited<br>>=3B form of integer=<br>
> >=2C that is=2C it should behave like an integer as much as possible=2C<br>&=<br>
> >gt=3B and when the implementation can no longer accomplish that=2C it shoul=<br>
> >d signal a <br>>=3B runtime error. <br>>=3B <br>>=3B It happens tha=<br>
> >t many existing implementions of Modula-3=2C as an implementation<br>>=3B=<br>
> > restriction=2C do not handle out-of-range situations correctly. Things<br=<br>
> >>>=3B such as what you describe SHOULD lead to a runtime error=2C value o=<br>
> >ut of range.<br>>=3B Some implementations wrap instead=2C but I don't eve=<br>
> >n think that's right. Of<br>>=3B course it's not as bad as it might be i=<br>
> >n C where you might be indexing an<br>>=3B array with the incorrectly cal=<br>
> >culated integer and send your program off in<br>>=3B never-never land. I=<br>
> >n Modula-3 you'll at least get a runtime error at THAT<br>>=3B point. Bu=<br>
> >t it's still not right.<br>>=3B <br>>=3B If I am understanding properly=<br>
> > what is going on I think this means your new<br>>=3B Modula-3-to-C compi=<br>
> >ler is the most reasonably behaving Modula-3 implementation.<br>>=3B <br>=<br>
> >>=3B Mika<br></div> </div></body><br>
> ></html>=<br>
> ><br>
> >--_ab947ec4-5d41-4d75-ba7b-1dd04573736b_--<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>