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 "ar
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
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
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
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 simil
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
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 endian
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", whic
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 possibilit
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 tha
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
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'
>>> 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 i
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
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
> 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 ra
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
>
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
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 to
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.
>>
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, le
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 Des
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
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
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 "possib
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 docum
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?
Wel
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 wha
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 broadcast)
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
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
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 I
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 i
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 wind
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,
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 versi
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
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), and server version 8.1.9 on Wind
38 matches
Mail list logo
