Am Dienstag, 22. Mai 2007 05:58 schrieb Tom Lane:
Okay, I spent some time googling this question, and I can't find any
suggestion that any ARM variant uses non-IEEE-compliant float format.
Some news I'm picking up at DebConf is that the existing Debian arm port
will be replaced by a new armel
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
I seem to recall also that there are machines that
treat the exponent as power-of-16 not power-of-2.
I'm pretty sure I don't understand this. Maybe I misunderstood the
format, but wouldn't that actually lose you precision with, at
Shachar Shemesh [EMAIL PROTECTED] writes:
Before you explode at me (again :), I'm not arguing that you can do
binary based calculations of decimal numbers without having rounding
errors that come to bite you. I know you can't. What I'm saying is that
we have two cases to consider. In one of
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Before you explode at me (again :), I'm not arguing that you can do
binary based calculations of decimal numbers without having rounding
errors that come to bite you. I know you can't. What I'm saying is that
we have two cases to
On Mon, May 21, 2007 at 11:58:35PM -0400, Tom Lane wrote:
The intent of the FP binary I/O code we have is that for platforms
supporting IEEE-compliant FP formats, the on-the-wire representation
should be uniformly big-endian, same as is true for integers. So
I would concur with a patch that
Tom Lane wrote:
Okay, I spent some time googling this question, and I can't find any
suggestion that any ARM variant uses non-IEEE-compliant float format.
What *is* real clear is that depending on ARM model and a run time (!)
CPU endianness flag, there are three or four different possibilities
On Tue, May 22, 2007 at 05:14:54PM +0300, Shachar Shemesh wrote:
As an amusing side note, I have heard a claim that the only reason we
need endianity at all is because the Europeans didn't understand that
Arabic is written from right to left. In Arabic you read 17 as seven
and ten, which means
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
I would concur with a patch that ensures that this is what happens
on the different ARM variants ... though I'll still be interested
to see how you make that happen given the rather poor visibility
into which model and endianness we
On 5/23/07, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
As an amusing side note, I have heard a claim that the only reason we
need endianity at all is because the Europeans didn't understand that
Arabic is written from right to left. In Arabic you read 17 as seven
and ten, which means
Please note - I'm not trying to pick up a fight.
Tom Lane wrote:
Your source appears fairly ignorant of things-float.
That is possible, and even likely, however
If they really are
using decimal FP, it's easy to demonstrate that a lossless conversion
to/from binary representation of similar
Am Montag, 21. Mai 2007 07:04 schrieb Shachar Shemesh:
In other words, if I offer a
format that is assured of preserving both mantissa and exponent
precision and range, as well as all extra attributes (+/-Infinity and
NaN), but does not guarantee that the semantically identical constructs
are
In other words, if I can assure that data exported and then imported
will always, under all circumstances, compare the same to the original,
would that be enough of a requirement? In other words, if I offer a
format that is assured of preserving both mantissa and exponent
precision and range,
Csaba Nagy wrote:
If you care about the +/- for +/-Infinity, you must also care about +/-0
too, so you get the right type of infinity if you divide with 0... so +0
and -0 are far from being semantically identical.
Cheers,
Csaba.
My suggestion accommodates that.
Shachar
Peter Eisentraut wrote:
I want to use the binary format but I don't like what it does.
It doesn't do anything. The set of circumstances under which it is
useful has been limited, on purpose, and, as far as I can see, without
any good reason. Spending not much time (and I suggested to spend it
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
Shachar Shemesh [EMAIL PROTECTED] writes:
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.
So how will you know which one is in use, which I'd think you'd
Shachar Shemesh [EMAIL PROTECTED] writes:
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
On Sun, 20 May 2007, Shachar Shemesh wrote:
This is not data given to store. It's data being exported.
Data being exported has a funny way of turning around and being stored in
the database again. It's kind of nice to know the damage done during that
round trip is minimized.
Tom seems
Greg Smith wrote:
On Sun, 20 May 2007, Shachar Shemesh wrote:
This is not data given to store. It's data being exported.
Data being exported has a funny way of turning around and being stored
in the database again. It's kind of nice to know the damage done
during that round trip is
Shachar Shemesh wrote:
Hi guys of the pgsql-hackers list.
I've received a bug report on the OLE DB list, which I suspect is
actually a server bug. The correspondence so far is listed further on,
but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
the binary interface),
Shachar Shemesh [EMAIL PROTECTED] writes:
I've received a bug report on the OLE DB list, which I suspect is
actually a server bug. The correspondence so far is listed further on,
but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
the binary interface), and server version
Shachar Shemesh [EMAIL PROTECTED] writes:
I'll reiterate - the problem is not that PG is exporting the internal
ARM FP format. The problem is that the server is exporting the internal
ARM FP format when the server is ARM, and the IEEE format when the
server is Intel. It's not the format, it's
Stefan Kaltenbrunner wrote:
Shachar Shemesh wrote:
Hi guys of the pgsql-hackers list.
I've received a bug report on the OLE DB list, which I suspect is
actually a server bug. The correspondence so far is listed further on,
but, in a nutshell, user runs an OLE DB client on windows (OLE DB
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
I've received a bug report on the OLE DB list, which I suspect is
actually a server bug. The correspondence so far is listed further on,
but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
the binary interface),
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
I'll reiterate - the problem is not that PG is exporting the internal
ARM FP format. The problem is that the server is exporting the internal
ARM FP format when the server is ARM, and the IEEE format when the
server is Intel. It's
Shachar Shemesh wrote:
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
I'll reiterate - the problem is not that PG is exporting the internal
ARM FP format. The problem is that the server is exporting the internal
ARM FP format when the server is ARM, and the IEEE format when the
Heikki Linnakangas [EMAIL PROTECTED] writes:
I agree in principle that the wire protocol should be
platform-independent.
The *TEXT* format is for that. The problem here is that Shachar is
insisting on using binary format in a context where it is inappropriate.
Binary format has other goals
Tom Lane wrote:
Binary format has other goals that are not always compatible with 100%
platform independence --- that's unfortunate, sure, but it's reality.
Maybe the misunderstanding is mine. What are the goals for the binary
format?
Shachar
---(end of
Heikki Linnakangas wrote:
But sometimes, like now, PG puts me in an impossible position. You are
essentially telling me you will get the numbers in an unknown format,
you will not have any way of knowing whether you got them in a strange
format or not, nor will you have any docs on what that
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
Binary format has other goals that are not always compatible with 100%
platform independence --- that's unfortunate, sure, but it's reality.
Maybe the misunderstanding is mine. What are the goals for the binary
format?
Well, the one
Shachar Shemesh wrote:
Perhaps OLE is trying to use binary instead of text transmission of
data?
Of course it does. That's what the OLE DB specs say. Said so in my
original email.
Why the heck do the OLE DB specs care about the internals of the
client-server prototocol? It is
Shachar Shemesh [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
Is it not possible to use text
format in OLE DB, for floating points?
It is impossible to use text format for just floating point. I often
don't know in advance what type the result is going to be.
Sure it's possible. Send
Andrew Dunstan [EMAIL PROTECTED] writes:
I do recall someone telling me that text mode transfer could actually be
faster than binary, somewhat to their (and my) surprise.
Seems a bit improbable --- what was their test case?
The only such situation that comes to mind is that some values are
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I do recall someone telling me that text mode transfer could actually be
faster than binary, somewhat to their (and my) surprise.
Seems a bit improbable --- what was their test case?
No idea - this was idle chat on IRC
Tom Lane wrote:
Sure it's possible. Send a Parse command, ask for Describe Statement
output, then specify the column formats as desired in Bind. Now this
does imply an extra server round trip, which might be annoying if your
client code doesn't have another reason to need to peek at Describe
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, not unless you can make the case why this handles NaNs and
denormalized numbers compatibly across platforms...
NaNs and infinite (plus and minus) should not be a problem.
Really? Need I point out that these concepts, let alone
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, not unless you can make the case why this handles NaNs and
denormalized numbers compatibly across platforms...
NaNs and infinite (plus and minus) should not be a problem.
Really? Need I
37 matches
Mail list logo