Avi Kivity <[EMAIL PROTECTED]> writes:
| On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
|
| > > most architectures have different bit representations for +0.0 and -0.0,
| > > yet the two values compare equal.
| > >
| >
| > Yet, their sign bit is observable through things like
| >
On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
> > most architectures have different bit representations for +0.0 and -0.0,
> > yet the two values compare equal.
> >
>
> Yet, their sign bit is observable through things like
> assert(a == 0.0);
> assert(b == 0.0);
> 1/(1/a+ 1/b)
Avi Kivity wrote on 06/07/2005 15:38:38:
> On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
> > Paolo Carlin
> > It is definitely a good thing to use the full bits of value
> > representation if we ever want to make all "interesting" bits part of
> > the hash value. For reasonable or
Avi Kivity <[EMAIL PROTECTED]> writes:
| On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
| > Paolo Carlin
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the hash value. For reasonable or sane
On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
> Paolo Carlin
> It is definitely a good thing to use the full bits of value
> representation if we ever want to make all "interesting" bits part of
> the hash value. For reasonable or sane representations it suffices to
> get your hand on
Michael Veksler <[EMAIL PROTECTED]> writes:
| There is one more thing to consider: the ABI.
| By changing the code in the header file will break the ABI
| of tr1::unordered_set. Code compiled with older gcc and
| newer and fixed-gcc will not interoperate.
tr1 is very experimental and we don't gua
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 23:48:03:
> Paolo Carlini wrote:
>
> >Michael Veksler wrote:
> >
> >>There is one more thing to consider: the ABI.
> >>By changing the code in the header file will break the ABI
> >>of tr1::unordered_set. Code compiled with older gcc and
> >
Paolo Carlini wrote:
>Michael Veksler wrote:
>
>>There is one more thing to consider: the ABI.
>>By changing the code in the header file will break the ABI
>>of tr1::unordered_set. Code compiled with older gcc and
>>newer and fixed-gcc will not interoperate.
>>
It occurs to me that by "ABI" you me
Michael Veksler wrote:
>There is one more thing to consider: the ABI.
>By changing the code in the header file will break the ABI
>of tr1::unordered_set. Code compiled with older gcc and
>newer and fixed-gcc will not interoperate.
>
>
No, no, there are no problems. First, I don't see how changin
There is one more thing to consider: the ABI.
By changing the code in the header file will break the ABI
of tr1::unordered_set. Code compiled with older gcc and
newer and fixed-gcc will not interoperate.
I don't see an easy path to avoid ABI breakage this time,
however how about preparing for
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >If you regard the object representation as an array of bytes, does it
| >take long realize it is not much different from hashing a character
| >string?
| >
| It takes less if your proposal comes together with a specific one
Michael Veksler wrote:
>Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 19:05:40:
>
>
>>However, sorry, as a matter of politeness, in my opinion expressions
>>like "absurdity" or "very bad way" are much better accepted if
>>accompanied by corresponding constructive contributions. Or,
>>al
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 19:05:40:
>
> However, sorry, as a matter of politeness, in my opinion expressions
> like "absurdity" or "very bad way" are much better accepted if
> accompanied by corresponding constructive contributions. Or,
> alternately, just avoid suc
Joe Buck wrote:
>If I were you I'd be tempted to crib from Python. Because of the
>centrality of good hashing for Python performance, I'm sure that they've
>done a good job.
>
I agree Joe, probably that's a good empirically tested solution.
Paolo.
On Tue, Jul 05, 2005 at 08:13:41PM +0200, Paolo Carlini wrote:
> Hi Joe and Gaby and thanks for your messages,
>
> >Close, but not quite.
> >
> >Hash functions are, by nature, many-to-one. A good hash function has
> >few collisions for values that frequently appear; the program will preform
> >ve
Gabriel Dos Reis wrote:
>If you regard the object representation as an array of bytes, does it
>take long realize it is not much different from hashing a character
>string?
>
It takes less if your proposal comes together with a specific one for
character string hashing: not, trivially, because in
Michael Veksler <[EMAIL PROTECTED]> writes:
| Joe Buck <[EMAIL PROTECTED]> wrote on 05/07/2005 21:10:25:
|
| > On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > > It is definitely a good thing to use the full bits of value
| > > representation if we ever want to make all "inte
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Joe Buck <[EMAIL PROTECTED]> writes:
| >
| >| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| >| > It is definitely a good thing to use the full bits of value
| >| > representation if we ever want to make
Joe Buck <[EMAIL PROTECTED]> wrote on 05/07/2005 21:10:25:
> On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
> > It is definitely a good thing to use the full bits of value
> > representation if we ever want to make all "interesting" bits part of
> > the hash value. For reas
Gabriel Dos Reis wrote:
>Joe Buck <[EMAIL PROTECTED]> writes:
>
>| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
>| > It is definitely a good thing to use the full bits of value
>| > representation if we ever want to make all "interesting" bits part of
>| > the hash value. For
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the hash value. For reasonable or sane representat
Hi Joe and Gaby and thanks for your messages,
>Close, but not quite.
>
>Hash functions are, by nature, many-to-one. A good hash function has
>few collisions for values that frequently appear; the program will preform
>very poorly if many inputs hash to the same value. The existing function
>will
On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
> It is definitely a good thing to use the full bits of value
> representation if we ever want to make all "interesting" bits part of
> the hash value. For reasonable or sane representations it suffices to
> get your hand on the obj
On Tue, Jul 05, 2005 at 07:05:16PM +0200, Paolo Carlini wrote:
> Michael Veksler wrote:
>
> > std::tr1::hash is implemented in a very bad way.
> > it casts double to size_t, which of course does a very poor job on big
> > values (is the result of 1.0e100 cast to size_t defined ?).
> >
> >
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
|
| > std::tr1::hash is implemented in a very bad way.
| > it casts double to size_t, which of course does a very poor job on big
| > values (is the result of 1.0e100 cast to size_t defined ?).
| >
| >
| A possible solutio
Tuesday, 05 July, 2005 10:36
> To: undisclosed-recipients:
> Subject: tr1::unordered_set bizarre rounding behavior (x86)
>
> The attached message just arrived in my mailbox. While it mentions
> a particular implementation, I believe it raises an important issue
> that ari
Michael Veksler wrote:
> std::tr1::hash is implemented in a very bad way.
> it casts double to size_t, which of course does a very poor job on big
> values (is the result of 1.0e100 cast to size_t defined ?).
>
>
A possible solution would be using frexp & co to extract the mantissa
and the
Gabriel Dos Reis wrote:
>| Sorry, I am not on the gcc team (I am working on constraint solvers rather
>| than compilers). I performed this review purely voluntarily.
>
>And it is clearly welcome! I hope more will follow :-)
>
>
Indeed.
However, sorry, as a matter of politeness, in my opinion e
Michael Veksler <[EMAIL PROTECTED]> writes:
[...]
| > 2. You don't know the answer. In that case you are supposed to file
| > a PR and trust bug-masters and maintainers about the issue.
| >
| > > std::tr1::hash is implemented in a very bad way.
| > > it casts double to size_t, which of co
Paolo Carlini <[EMAIL PROTECTED]> wrote on 05/07/2005 16:33:12:
> Michael Veksler wrote:
>
> >The behavior of the second run does not look right. What does it mean?
> >1. Is it forbidden by tr1 to define unordered_set ?
> >2. Is it a bug in the tr1 document (which should have forbidden this).
>
Michael Veksler <[EMAIL PROTECTED]> writes:
| Hello,
|
| In previous discussions on rounding of double on x86 I wanted
| to find an example that points to the absurdity of current
| gcc behavior.
| At last I found such an example:
Thanks for investing time in this and reporting.
| t.cpp st
Michael Veksler wrote:
>The behavior of the second run does not look right. What does it mean?
>1. Is it forbidden by tr1 to define unordered_set ?
>2. Is it a bug in the tr1 document (which should have forbidden this).
>3. Is it OK to have repetitions in unordered_set?
>4. Is it a bug in gcc, for
Hello,
In previous discussions on rounding of double on x86 I wanted
to find an example that points to the absurdity of current
gcc behavior.
At last I found such an example:
t.cpp start ---
#include
#include
double x=3.0;
int main()
{
std::tr1::unordered_set myset;
myset.inser
33 matches
Mail list logo
