FLOOR may silently give incorrect results #24
Comments
|
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>
.
|
|
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?) |
ajcz
changed the title
|
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>
.
|
|
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. |
|
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>
.
|
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.
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. |
|
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" <notifications@github.com> 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>
.
|
|
Umm... I didn’t have any problem with Date.FromTime.
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). |
|
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>
.
|
FLOOR seems to give incorrect results for larger numbers. In my environment, FLOOR(1.0D10) is −2147483648 on NT386 and FLOOR(1.0D20) is −9223372036854775808 on AMD64_LINUX.
The text was updated successfully, but these errors were encountered: