>>> On Mon, May 21, 2007 at 9:02 AM, in message <[EMAIL PROTECTED]>, Shachar Shemesh <[EMAIL PROTECTED]> wrote: > >> We have fought many years to get closer to IEEE 754 >> conformance. > > Please notice that the format I offered *is* IEEE. In fact, what I'm > offering is to export the binary in IEEE format EVEN IF THE NATIVE > FORMAT ISN'T. > > As for the ARM architecture, I've pulled my sources, and the answer is > this: ARM doesn't have one standard floating point format. Different ARM > architectures will use different formats. Most architectures will > actually use IEEE, but some will use decimal based and such. According > to my source (a distributor of ARM based hardware), none of the other > formats will lose precision if translated to IEEE. > > So, I will repeat my original question. I can write portable code that > will translate the native format to IEEE (if it's not already the same). > It seems that it will be good enough for all platforms discussed here. > Failing that, we can adopt my later proposal which is IEEE + status for > all places where that is good enough. It sounds to me like there are two issues: (1) How do you get things to work under the current communications protocol? (2) Should PostgreSQL consider moving toward a platform independent binary protocol in some future release? Based on what Tom and others have said, you need to resort to text representation for portability with the current protocol. You might be surprised at how minimal the impact is, especially if the CPUs aren't saturated. Clearly a platform independent protocol is possible. I send binary information between machines with different hardware and operating systems all the time. A big question for any PostgreSQL implementation of this has been whether any of the internal representations used on supported platforms are incapable of IEEE representation without data loss. You've asserted that you've done research which shows compatibility. Can anyone show a counter-example, where IEEE representation on the wire would not work? For reference on how Java has addressed this issue for floating point numbers and how they go over the wire, see: http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#33377 http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#28147 http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToLongBits(double) http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Double.html#doubleToRawLongBits(double) http://java.sun.com/j2se/1.5.0/docs/api/java/io/DataOutput.html#writeLong(long) -Kevin
---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
