(asked last week on .questions, no response)
Can anyone explain why this happens? (under 7.4.1)
select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;
timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;
timestamp
---------------------
2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp
as the first? Is it a floating-point representation issue, or are the
mathematical rules of rounding not being followed correctly (as I
understand them, anyway)?
--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc. http://www.nexcerpt.com
...Nexcerpt... Extend your Expertise 6 4567
On Thu, 3 Jun 2004, Jeff Boes wrote: (asked last week on .questions, no response)
Can anyone explain why this happens? (under 7.4.1)
select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp as the first? Is it a floating-point representation issue, or are the mathematical rules of rounding not being followed correctly (as I understand them, anyway)?
My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
Stephan Szabo <ss****@megazone.bigpanda.com> writes: That is, why doesn't the second operation result in the same timestamp as the first? Is it a floating-point representation issue, or are the mathematical rules of rounding not being followed correctly (as I understand them, anyway)? My first guess would be that your system probably implements its default rounding as nearest even for .5 results, what does 9:00:01.5 give you?
Fwiw, the floating point timestamp representation is seconds-based. So 0.5s
should be exactly representable. (Though 0.500001 wouldn't, but that shouldn't
matter.)
On my machine it seems to always round away from 0, but this comment from
timestamp.c seems relevant. It would imply my build was build with integer
timestamps and yours was built with floating point timestamps:
/*
* Note: this round-to-nearest code is not completely consistent
* about rounding values that are exactly halfway between integral
* values. On most platforms, rint() will implement
* round-to-nearest-even, but the integer code always rounds up
* (away from zero). Is it worth trying to be consistent?
*/
And this is from the glibc Info page:
IEEE 754 defines four possible rounding modes:
Round to nearest. This is the default mode. It should be used unless there is a specific need for one of the others. In this mode results are rounded to the nearest representable value. If the result is midway between two representable values, the even representable is chosen. "Even" here means the lowest-order bit is zero. This rounding mode prevents statistical bias and guarantees numeric stability: round-off errors in a lengthy calculation will remain smaller than half of `FLT_EPSILON'.
[And the other rounding directions are useless;
this is the default and the only one that matters.]
--
greg
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
On Thu, 3 Jun 2004, Jeff Boes wrote: (asked last week on .questions, no response)
Can anyone explain why this happens? (under 7.4.1)
select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp as the first? Is it a floating-point representation issue, or are the mathematical rules of rounding not being followed correctly (as I understand them, anyway)?
My first guess would be that your system probably implements its default
rounding as nearest even for .5 results, what does 9:00:01.5 give you?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly
Stephan Szabo <ss****@megazone.bigpanda.com> writes: That is, why doesn't the second operation result in the same timestamp as the first? Is it a floating-point representation issue, or are the mathematical rules of rounding not being followed correctly (as I understand them, anyway)? My first guess would be that your system probably implements its default rounding as nearest even for .5 results, what does 9:00:01.5 give you?
Fwiw, the floating point timestamp representation is seconds-based. So 0.5s
should be exactly representable. (Though 0.500001 wouldn't, but that shouldn't
matter.)
On my machine it seems to always round away from 0, but this comment from
timestamp.c seems relevant. It would imply my build was build with integer
timestamps and yours was built with floating point timestamps:
/*
* Note: this round-to-nearest code is not completely consistent
* about rounding values that are exactly halfway between integral
* values. On most platforms, rint() will implement
* round-to-nearest-even, but the integer code always rounds up
* (away from zero). Is it worth trying to be consistent?
*/
And this is from the glibc Info page:
IEEE 754 defines four possible rounding modes:
Round to nearest. This is the default mode. It should be used unless there is a specific need for one of the others. In this mode results are rounded to the nearest representable value. If the result is midway between two representable values, the even representable is chosen. "Even" here means the lowest-order bit is zero. This rounding mode prevents statistical bias and guarantees numeric stability: round-off errors in a lengthy calculation will remain smaller than half of `FLT_EPSILON'.
[And the other rounding directions are useless;
this is the default and the only one that matters.]
--
greg
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
Stephan Szabo wrote: On Thu, 3 Jun 2004, Jeff Boes wrote: (asked last week on .questions, no response)
Can anyone explain why this happens? (under 7.4.1)
select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp as the first? Is it a floating-point representation issue, or are the mathematical rules of rounding not being followed correctly (as I understand them, anyway)?
My first guess would be that your system probably implements its default rounding as nearest even for .5 results, what does 9:00:01.5 give you?
2004-05-27 09:00:02, so I guess that would confirm it.
--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc. http://www.nexcerpt.com
...Nexcerpt... Extend your Expertise
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives? http://archives.postgresql.org
Stephan Szabo wrote: On Thu, 3 Jun 2004, Jeff Boes wrote: (asked last week on .questions, no response)
Can anyone explain why this happens? (under 7.4.1)
select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:01
select '2004-05-27 09:00:00.500000-04' :: timestamp(0) ;
timestamp --------------------- 2004-05-27 09:00:00
That is, why doesn't the second operation result in the same timestamp as the first? Is it a floating-point representation issue, or are the mathematical rules of rounding not being followed correctly (as I understand them, anyway)?
My first guess would be that your system probably implements its default rounding as nearest even for .5 results, what does 9:00:01.5 give you?
2004-05-27 09:00:02, so I guess that would confirm it.
--
Jeff Boes vox 269.226.9550 ext 24
Database Engineer fax 269.349.9076
Nexcerpt, Inc. http://www.nexcerpt.com
...Nexcerpt... Extend your Expertise
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives? http://archives.postgresql.org This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jeff Boes |
last post by:
Can anyone explain why this happens? (under 7.4.1)
select '2004-05-27 09:00:00.500001-04' :: timestamp(0) ;
timestamp
---------------------
2004-05-27 09:00:01
select '2004-05-27...
|
by: calan |
last post by:
Does anyone have a function that will round a number to 0 or .5?
I have a form where I'm entering a number in inches. I need to round it to
the nearest 1/2 inch (onChange).
The split will be...
|
by: towers |
last post by:
Hello,
I've got a bit of experience in C++, but I'm writing my first app that
is dependent on relatively precise math functions. The app requires
that I get a time stamp based on s sample...
|
by: Claudio Lapidus |
last post by:
Hello
(Sorry about reposting, but I'm still not arriving to any good solution for
this one)
I need to output a timestamp attribute formatted to fixed-width, no spaces
nor separators,...
|
by: mboes |
last post by:
Hi there,
Is there a way of specifying the precision of a timestamp *with
timezone* field? It works fine for timestamps *without* timezones, but
gives me a syntax error if I try with...
|
by: Zygo Blaxell |
last post by:
I have a table with a few million rows of temperature data keyed
by timestamp. I want to group these rows by timestamp intervals
(e.g. every 32 seconds), compute aggregate functions on the...
|
by: Marco |
last post by:
Hello,
I have :
float f = 36.09999999;
When I do :
char cf;
sprintf(cf,"%0.03lf", f);
I get : 36.100
|
by: md |
last post by:
Hi
Does any body know, how to round a double value with a specific number
of digits after the decimal points?
A function like this:
RoundMyDouble (double &value, short numberOfPrecisions)
...
|
by: t8ntboy |
last post by:
I am using ASP and SQL 2005 Express.
I am inserting a timestamp from an ASP page using <%=now%into a
smalldatetime field. All of my timestamps are appearing without any
seconds (e.g., ...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |