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

[Jay K]

 AMD64_NT starting up mentor:   
  
  ***  
  *** runtime error:  
  ***    An enumeration or subrange value was out of range.  
  ***    file "..\src\EventWireRep.m3", line 89  
  ***  


This opens up a big multi-part can of worms.
I'm not sure the order to present things.
Please bear with me.



Background:

 Time.T is a double/longreal number of seconds since a platform-specific epoch.
 This cleverly gives I guess pretty good range and precison.
 On Windows, that is 1601.
 The underlying system stores 64bit 100s of nanoseconds. 
This gives both good range and precision.
 And it works ok with Modula-3. 
 On Posix is presumably 1970. 
 This is all ok. Not controversial.



Corralaries:

Time.Now on Windows returns around 1.3022747815483961e10.
My simple math says that is off by a month but hopefully
more precise math says it is exactly correct.
 We have confusing Modula-3 code and straightforward C code to compute this.
That it is within a month seems adequate to backup everything
else I'm seeing/saying.


events!EventWireRep_M3 [c:\dev2\cm3\m3-comm\events\src\eventwirerep.m3 @ 90]

  Int32 = BITS 32 FOR [-2147483647-1..2147483647];
  TRep = RECORD ts: Int32; objNum: Int32; space: EventSpaceID.T; END;

VAR myTs: Int32 := ROUND(Time.Now());


 Clearly this is a problem. 
 It runs out "soon" on 32bit Posix systems, it runs out 
 already on Win64, and on Win32, well, it produces 
 garbage one way or another, but no range errors. 


On AMD64_NT, this reasonably rounds to

  13022747815 -- the full integer value of the double
   fits in a 64bit integer.
   
But it doesn't fit in 32 bits.
  On I386_NT, this somewhat "correctly" rounds to
 -2147483648
 
Hm. Shouldn't it be nearest integer 2147483647??


In either case, see you the problem.

Ok, so this is three dilemnas/questions/bugs in one.


http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arithmetic_operations.html


ROUND(r) is the nearest integer to r; ties are broken according to the constant RoundDefault


1) How should ROUND be defined? Is Modula-3 adequately safe here?


 What should round of numbers less than FIRST(INTEGER)-1 
 or greater than LAST(INTEGER) + 1 round to? 


 By the simple definition, they should round to FIRST(INTEGER) 
 and LAST(INTEGER). But is it safe?


 You know, I can see taking the whole part of the number 
 and losing the fractional part as being ok when desired, 
 but when the whole part doesn't fit, not even when rounded 
 up or down by 1? Doesn't that seem like it should be a range error? 



2) What is up with the various implementations?


ASSUMING Modula-3 ROUND is defined safely enough,
is the integrated NT/x86 backend correct here?


On I386_DARWIN:

IMPORT IO, Fmt;

BEGIN
IO.Put(Fmt.Int(ROUND(1.3022747815483961e10)) & "\n");
END Main.


We get: 137845760.


Wow, that is just wrong.
Sure it got the mantissa close, but the exponent is arbitrary seeming.
I could chalk this up to a bug in my C backend,
but it gets constant folded in the front end.
The backend just gets load_integer 137845760.
This seems highly incorrect.
Maybe bugs in Target.Float?
Maybe overflow is being ignored??
I'll look later, another day.



3) What to do?


3a) The frontend seems wrong here, no matter what.

3b) The integrated backend seems at least slightly wrong.

3c) The events code either needs widening, or perhaps
this isn't time, but a somewhat arbitrary "fingerprint".
Perhaps it can just use MOD?? I will likely verify if it needs to be
time or just a reasonably volatile number to cross check sender/reciever
and then use MOD. Posix and Win32 systems probably can't talk to each other. Lame.



Someone might suggest that Win32 epoch be changed to 1970.
I don't think so.


4) can anyone understand and explain the Modula-3 code we have here in Time.m3?



Thank you,
 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130904/ca71444d/attachment-0001.html>