Thread
-
How PostgreSQL's floating-point hurts everyone everywhere
Peter Eisentraut <peter_e@gmx.net> — 2000-07-20T16:10:24Z
Forgive me for the tacky subject, but the analogies are not far-fetched. I was just looking whether the UNSAFE_FLOATS compile-time option could perhaps be a run-time option, but I'm getting the feeling that it shouldn't be an option at all. "Safe" floats check after each floating point function call whether the result is "in bounds". This leads to interesting results such as peter=# select 'nan'::float8; ?column? ---------- NaN (1 row) peter=# select 'infinity'::float8; ERROR: Bad float8 input format -- overflow What happened? The "safe floats" mode checker will fail if `result > FLOAT8_MAX', which will kick in for 'infinity' but is false for 'nan'. The carefully crafted support for infinities is dead code. Also: peter=# select 1.0/0.0; ERROR: float8div: divide by zero error Division by zero is not an "error" in floating point arithmetic. I think the CheckFloat{4,8}Val() functions should be abandoned and the floating point results should be allowed to overflow to +Infinity or underflow to -Infinity. There also need to be isinf() and isnan() functions, because surely "x = 'infinity'" isn't going to work. This is not a high-priority issue to me, nor do I feel particularly qualified on the details, but at least we might agree that something's wrong. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden -
Re: How PostgreSQL's floating-point hurts everyone everywhere
Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-07-20T16:47:03Z
> What happened? This may be platform-specific behavior. I see on my Linux/Mandrake box the following: lockhart=# select 'nan'::float8; ERROR: Bad float8 input format -- overflow lockhart=# select 'infinity'::float8; ERROR: Bad float8 input format -- overflow Typically, machines will trap overflow/underflow/NaN problems in floating point, but silently ignore these properties with integer arithmetic. It would be nice to have consistant behavior across all types, but I'll stick to floats for discussion now. Lots of machines (but not all) now support IEEE arithmetic. On those machines, istm that we can and should support some of the IEEE conventions such as NaN and +Inf/-Inf. But on those machines which do not have this concept, we can either try to detect this during data entry, or trap this explicitly during floating point exceptions, or watch the backend go up in flames (which would be the default behavior). Same with divide-by-zero troubles. > I think the CheckFloat{4,8}Val() functions should be abandoned and the > floating point results should be allowed to overflow to +Infinity or > underflow to -Infinity. There also need to be isinf() and isnan() > functions, because surely "x = 'infinity'" isn't going to work. It does work if "infinity" is first interpreted by our input routines. I recall running into some of these issues when coding some data handling routines on my late, great Alpha boxes. In this case, I tried to use the isinf() (??) routine provided by DEC (and defined in IEEE?) to test for bad values coming from a real-time GPS tracking system. But until I futzed with the compiler options, calling isinf() failed on any infinity value since the value was being checked during the call to the routine, so the value was never getting to the test! > This is not a high-priority issue to me, nor do I feel particularly > qualified on the details, but at least we might agree that something's > wrong. I'd think that, on some platforms, we can try coding things a bit differently. But the code in there now does do some useful things for some of the platforms we run on (though there are still holes in possible failure modes). imho if we change things it would be to turn some of the checking into NOOP macros on some platforms, but preserve these for others. - Thomas -
Re: How PostgreSQL's floating-point hurts everyone everywhere
Henry B. Hotz <hotz@jpl.nasa.gov> — 2000-07-20T17:03:51Z
At 4:47 PM +0000 7/20/00, Thomas Lockhart wrote: >Typically, machines will trap overflow/underflow/NaN problems in >floating point, but silently ignore these properties with integer >arithmetic. It would be nice to have consistant behavior across all >types, but I'll stick to floats for discussion now. The IEEE standard says that that behavior must be configurable. The standard behavior in Fortran is to ignore floating point exceptions as well. Unfortunately the name of the C routine which changes it is not defined in the standard. This is a bit off-topic but we have this problem with the DS1 spacecraft software. Everything is run with the exceptions enabled because we don't want to allow those values undetected in the attitude control calculations. OTOH we are vulnerable to reboots (and have had one) due to mistakes in other code. Signature failed Preliminary Design Review. Feasibility of a new signature is currently being evaluated. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
-
Re: How PostgreSQL's floating-point hurts everyone everywhere
Jan Wieck <janwieck@t-online.de> — 2000-07-20T17:28:59Z
Peter Eisentraut wrote: > > peter=# select 1.0/0.0; > ERROR: float8div: divide by zero error > > Division by zero is not an "error" in floating point arithmetic. No? Oh, then 7 = 5 because: Assuming 2a = b | * 2 4a = 2b | + 10a 14a = 10a + 2b | - 7b 14a - 7b = 10a - 5b | () 7 (2a - b) = 5 (2a - b) | / (2a - b) 7 = 5 In the given context, you should find the mistake pretty easy. Maybe the message should be changed to ERROR: floatdiv: divide by zero nonsense ^^^^^^^^ because a division by zero results in nonsense? Or should it just return a random value? What is the result of a division by zero? It's definitely not infinity, as the above demonstrates! You might be looking from a managers PoV. Managers usually use this kind of arithmetic to choose salaries. Any engineer knows that work = power * time We all know that time is money and that power is knowlede. So work = knowledge * money and thus work money = --------- knowledge Obviously, the lesser you know, the more money you get, independant of the work to be done. As soon as you know nothing (zero), any money you get for the work is nonsense! This applies well to the real world, so it makes sense from an OO PoV. But in science, I think it's still an error. Since PostgreSQL is an ORDBMS (not an OODBMS), I think it's correct to report an error instead of returning some random. :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # -
Re: How PostgreSQL's floating-point hurts everyone everywhere
Tom Lane <tgl@sss.pgh.pa.us> — 2000-07-21T06:57:21Z
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > I'd think that, on some platforms, we can try coding things a bit > differently. But the code in there now does do some useful things for > some of the platforms we run on (though there are still holes in > possible failure modes). Yes. But on machines that do have IEEE-compliant math, it would be nice to act more IEEE-ish than we do. Perhaps a compile-time option for IEEE vs "traditional Postgres" behavior? regards, tom lane
-
Re: How PostgreSQL's floating-point hurts everyone everywhere
Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-07-21T07:08:36Z
> Yes. But on machines that do have IEEE-compliant math, it would be > nice to act more IEEE-ish than we do. Perhaps a compile-time option > for IEEE vs "traditional Postgres" behavior? Sure. Sounds like a job for configure... - Thomas -
Inprise InterBase(R) 6.0 Now Free and Open Source
Kaare Rasmussen <kar@webline.dk> — 2000-07-25T16:17:44Z
In case you didn't notice: http://biz.yahoo.com/prnews/000725/ca_inprise_2.html -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2582 Howitzvej 75 ben 14.00-18.00 Email: kar@webline.dk 2000 Frederiksberg Lrdag 11.00-17.00 Web: www.suse.dk
-
Re: Inprise InterBase(R) 6.0 Now Free and Open Source
J. M. Brenner <doom@kzsu.stanford.edu> — 2000-07-25T22:40:30Z
Kaare Rasmussen <kar@webline.dk> wrote: > In case you didn't notice: > > http://biz.yahoo.com/prnews/000725/ca_inprise_2.html Yes, and now the story is up on slashdot: http://slashdot.org/comments.pl?sid=00%2F07%2F25%2F1439226&cid=&pid=0&startat=&threshold=-1&mode=nested&commentsort=3&op=Change So if anyone feels like taking time out to do some evangelizing, this might be a good moment to say a few words about Postgresql vs. "Inprise, The Open Source Database". In particular, this guy could use a detailed reply: > Interbase > > (Score:4, Interesting) > by jallen02 (:-( .) on Tuesday July 25, @09:06AM PST > (User #124384 Info) http://gdev.net/~jallen > > I found myself wondering exactly what Interbase could do > for me. So I dug through their site (not hard to find) > and found this lil gem > > Interbase Product Overview > > Interbase has some very awesome features. The overview > took the tone of a semi marketing type item yet it was > infomrative and if you read through some of the garbage > its rather clear to see as a programmer/developer what > Interbase offers. > Some of the features that stuck out in my mind from the > over view. > > -Small memory footprint > -Triggers > -Stored Procedures > -User Definable Functions with some 'libraries' per say > already defined for math and string handling > -Alert events > > EX:A certain item goes below xyz dollars it can send an > alert using some sort of constant polling method. I am > not sure exactly what this one was.. but basically it > looks like whenever changes are done to the table if > certain criteria are met it can call up a stored > proc/UDF or something. This is a bit more powerful than > a trigger or a stored procedure since you do not have to > do any speical coding on a insert/update/delete. > > Some other interesting things... There was a *LOAD* of > case studies on the interbase site. > > Case Studies > > I looked at some of these and they were real industry > proven case studies IMO. > > Its Free.. and it has a good reputation > > You can buy support for it > > It appears to be VERY ANSI Compliant and supports all the > trappings of MS SQL Server. > > It also claimed to be self optimizing... anyways hope this > provided a little information.
-
Re: Inprise InterBase(R) 6.0 Now Free and Open Source
Don Baccus <dhogaza@pacifier.com> — 2000-07-25T22:54:03Z
At 03:40 PM 7/25/00 -0700, Joe Brenner wrote: > >Kaare Rasmussen <kar@webline.dk> wrote: > >> In case you didn't notice: >> >> http://biz.yahoo.com/prnews/000725/ca_inprise_2.html > >Yes, and now the story is up on slashdot: > >http://slashdot.org/comments.pl?sid=00%2F07%2F25%2F1439226&cid=&pid=0&start at=&threshold=-1&mode=nested&commentsort=3&op=Change > >So if anyone feels like taking time out to do some >evangelizing, this might be a good moment to say a few words >about Postgresql vs. "Inprise, The Open Source Database". > >In particular, this guy could use a detailed reply: Just be sure to avoid any talk of outer joins ... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Service and other goodies at http://donb.photo.net.
-
Re: Inprise InterBase(R) 6.0 Now Free and Open Source
Chris <chrisb@nimrod.itg.telstra.com.au> — 2000-07-26T04:30:33Z
$ find InterBase -name \*.c |xargs cat |wc 481977 1417203 11430946 $ find postgresql-7.0.2 -name \*.c |xargs cat |wc 329582 1087860 8649018 $ wc InterBase/dsql/parse.y 4217 13639 103059 InterBase/dsql/parse.y $ wc postgresql-7.0.2/src/backend/parser/gram.y 5858 20413 149104 postgresql-7.0.2/src/backend/parser/gram.y I downloaded it, just to have a poke around. It doesn't build very easily, if at all. The best way I can describe the source is that it is dry reading. Not much interesting commentary. Very big source files, with very long functions and huge case statements is how I would characterise it. I suspect it's reasonably well written but not very extensible in nature. I don't think this is going to set the world on fire anytime soon. -
Re: Inprise InterBase(R) 6.0 Now Free and Open Source
Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-07-26T05:21:06Z
> $ wc InterBase/dsql/parse.y > 4217 13639 103059 InterBase/dsql/parse.y > $ wc postgresql-7.0.2/src/backend/parser/gram.y > 5858 20413 149104 postgresql-7.0.2/src/backend/parser/gram.y Hmm. I suspect that I could shrink our gram.y by ~25% just by removing comments and C support routines, and by consolidating some execution blocks onto fewer lines. Does it look like their parse.y is more dense than ours, do they do a lot of postprocessing to eliminate the yacc rules, or have we missed the boat on writing the grammar in yacc? Just curious; I probably won't look myself since I don't want to run the risk of compromising our code and licensing. Or is that not an issue with the Inprise license? - Thomas -
Re: Inprise InterBase(R) 6.0 Now Free and Open Source
Chris <chrisb@nimrod.itg.telstra.com.au> — 2000-07-26T05:56:12Z
Thomas Lockhart wrote: > > > $ wc InterBase/dsql/parse.y > > 4217 13639 103059 InterBase/dsql/parse.y > > $ wc postgresql-7.0.2/src/backend/parser/gram.y > > 5858 20413 149104 postgresql-7.0.2/src/backend/parser/gram.y > > Hmm. I suspect that I could shrink our gram.y by ~25% just by removing > comments and C support routines, and by consolidating some execution > blocks onto fewer lines. Does it look like their parse.y is more dense > than ours, do they do a lot of postprocessing to eliminate the yacc > rules, or have we missed the boat on writing the grammar in yacc? > > Just curious; I probably won't look myself since I don't want to run the > risk of compromising our code and licensing. Or is that not an issue > with the Inprise license? I had a bit of a look. There's no obvious reason, just maybe postgres has a few more comments and a bit more code inside the action blocks. No obvious problem here. It would be a pity if we can't look and learn from Interbase in this instance, because this is one area where there is at least a possibility of borrowing something useful.