FLOOR may silently give incorrect results about cm3

[mikanystrom]

What SHOULD it do? Checked runtime error?

…

On Sat, Mar 10, 2018 at 11:09 PM, jcchu ***@***.***> wrote: FLOOR seems to give incorrect results for larger numbers. In my environment, FLOOR(1.0D10) is −2147483648 <(214)%20748-3648> on NT386 and FLOOR(1.0D20) is −9223372036854775808 on AMD64_LINUX. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFWGpRph0-4jO3h2P5QIRTUZKucAVqJyks5tdM2kgaJpZM4SllkK> .

[ajcz]

Gee, I didn’t even realize FLOOR returns INTEGER. (I’ll change the issue title.)

Actually I was trying to calculate the fractional part of Time.T values, which turned out to be too large. The comment in Math.i3 suggests the reader to use the built-in rounding functions instead; I guess that could be a bit misleading.

Getting checked runtime errors does seem a lot better than getting incorrect results. (Or could something go wrong?)

[mikanystrom]

Isn't Time.T from the Unix epoch? It shouldn't have rolled over yet... Or is this on Windows? Can you use the Date interface?

…

On Mar 11, 2018 11:25 AM, "jcchu" ***@***.***> wrote: Gee, I didn’t even realize FLOOR returns INTEGER. (I’ll change the issue title.) Actually I was trying to calculate the fractional part of Time.T values, which turned out to be too large. The comment in Math.i3 suggests the reader to use the built-in rounding functions instead; I guess that could be a bit misleading. Getting checked runtime errors does seem a lot better than getting incorrect results. (Or could something go wrong?) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFWGpd_yfVx8_lyhpQvqrOw3Dex1460Bks5tdPt6gaJpZM4SllkK> .

[ajcz]

There’s no problem with the Date interface. I just need a Date.T with a finer resolution, hence the need for the fractional part of Time.T.

[mikanystrom]

How far into the past or future do you need to go? 32 bits is good till 2038, I think, if it's the Unix epoch... If you need to convert later dates or with a different epoch you can do a stepwise thing. Divide the time by a nice round number, say 2048, do the floor, subtract it off, multiply by 2048... Yes a checked runtime error is the right behavior when the conversion is out of range, I think. Mika

…

On Mar 11, 2018 1:55 PM, "jcchu" ***@***.***> wrote: There’s no problem with the Date interface. I just need a Date.T with a finer resolution, hence the need for the fractional part of Time.T. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFWGpVvLYbA6Tm_-soLclebQcxHZTQECks5tdR7VgaJpZM4SllkK> .

[ajcz]

How far into the past or future do you need to go?

Not too far from the present thankfully. I think the Posix implementation already uses 64-bit times internally where possible. On Windows Time uses WinBase.FILETIME, which has a resolution of 0.1 ms and is good for about 30,000 years around January 1, 1601.

If you need to convert later dates or with a different epoch you can do a stepwise thing. Divide the time by a nice round number, say 2048, do the floor, subtract it off, multiply by 2048...

Do you mean that if a Time.T is too large for Date.FromTime I can calculate suitable a remainder first, convert it to a Date.T, and then adjust that Date.T accordingly? But then how do I know when a Time.T is too large? Date.FromTime doesn’t raise any exceptions.

[mikanystrom]

Does Date.FromTime not work right? I thought you just had a problem getting the fractional seconds out.... Since all the epochs that I know about start from an integral second (although it's hard to say precisely what that means before about 1958, but "whatever"), you can use the algorithm I described to extract the fractional seconds regardless of epoch and then Date.FromTime for all the other fields. Been a while since I used modula-3 on Windows... I will see if I solved this problem. I think so... I had a high-frequency trading robot running on Windows for a while, it must have needed this info. Mika On Mar 12, 2018 4:34 AM, "jcchu" <[email protected]> wrote: How far into the past or future do you need to go? Not too far from the present thankfully. I think the Posix implementation already uses 64-bit times internally where possible. On Windows Time uses WinBase.FILETIME, which has a resolution of 0.1 ms and is good for about 30,000 years around January 1, 1601. If you need to convert later dates or with a different epoch you can do a stepwise thing. Divide the time by a nice round number, say 2048, do the floor, subtract it off, multiply by 2048... Do you mean that if a Time.T is too large for Date.FromTime I can calculate suitable a remainder first, convert it to a Date.T, and then adjust that Date.T accordingly? But then how do I know when a Time.T is too large? Date.FromTime doesn’t raise any exceptions. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFWGpZkyh5--yjckfSPh4Ee7jloEZDBWks5tdezLgaJpZM4SllkK> .

[ajcz]

Umm... I didn’t have any problem with Date.FromTime.

Since all the epochs that I know about start from an integral second […]

That’s my assumption as well as well as what is said in the Time interface’s comment. I didn’t get the correct fractional part of VAR now := Time.Now() because now is too large for INTEGER and I was calculating now - FLOAT(FLOOR(now), Time.T) instead of now - Math.floor(now) or maybe just Math.fmod(now, 1.0D0).

[mikanystrom]

That's what I thought. All I'm saying is you can use FLOOR if you chop the integer part off in two steps. No need for Math.xxxxx . Mika

…

On Mar 12, 2018 5:12 AM, "jcchu" ***@***.***> wrote: Umm... I didn’t have any problem with Date.FromTime. Since all the epochs that I know about start from an integral second […] That’s my assumption as well as well as what is said in the Time interface’s comment. I didn’t get the correct fractional part of VAR now := Time.Now() because now is too large for INTEGER and I was calculating now - FLOAT(FLOOR(now), Time.T) instead of now - Math.floor(now) or maybe just Math.fmod(now, 1.0D0). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFWGpbi2OicokNl77ucAWKQT3NNd3N9Aks5tdfWPgaJpZM4SllkK> .