Luke VanderHart wrote:
> On Oct 29, 4:01 am, Mark Engelberg wrote:
>> I see your point that hashCode could be made to work on infinite
>> sequences, but since hashing is almost always a prelude to testing for
>> equality, I'm hard pressed to think of an example of why you'd want to
>> be able to
Wouldn't hashCode be called every time you use an infinite sequence as
a key in a hash map?
That strikes me as a problem, since everything else in Clojure makes
perfectly good map keys.
On Oct 29, 4:01 am, Mark Engelberg wrote:
> On Wed, Oct 28, 2009 at 11:08 PM, John Harrop wrote:
> > For th
On Wed, Oct 28, 2009 at 11:08 PM, John Harrop wrote:
> For the specific case of hashCode, no; identical values must have identical
> hashes but different values need not have different hashes. Collisions due
> to the hypothetical cutoff get exponentially less likely with each
> additional increme
John Harrop wrote:
> On Wed, Oct 28, 2009 at 9:35 PM, Alex Osborne wrote:
>
> Choosing some arbitrary magic cutoff point just
> seems cause for trouble and much confusion.
>
> For the specific case of hashCode, no; identical values must have
> identical hashes but different values need
Hello,
On Thu, Oct 29, 2009 at 3:35 AM, Alex Osborne wrote:
>
> John Harrop wrote:
>> Probably the seq .hashCode should consider only the first N elements
>> for some maximum N and if two longer (or even infinite) sequences
>> collide so be it.
>
> I strongly disagree. Choosing some arbitrary m
On Wed, Oct 28, 2009 at 9:35 PM, Alex Osborne wrote:
> John Harrop wrote:
> > Probably the seq .hashCode should consider only the first N elements
> > for some maximum N and if two longer (or even infinite) sequences
> > collide so be it.
>
> I strongly disagree. Choosing some arbitrary magic cu
John Harrop wrote:
> Probably the seq .hashCode should consider only the first N elements
> for some maximum N and if two longer (or even infinite) sequences
> collide so be it.
I strongly disagree. Choosing some arbitrary magic cutoff point just
seems cause for trouble and much confusion. Put
On Oct 28, 4:33 pm, Richard Newman wrote:
> I think John's point is this:
>
> user=> (take 3 (repeatedly rand))
> (0.07020342855887218 0.590736243072285 0.04997104958104426)
> user=> (take 3 (repeatedly rand))
> (0.6445602419794128 0.12488917903865004 0.5784287452848529)
>
> Different sequences,
> So when the resulting lazy sequence has its hash code requested, it
> could return a value similar to the following:
>
> (+ (.hashCode rand) (* 37 (.hashCode repeatedly)))
I think John's point is this:
user=> (take 3 (repeatedly rand))
(0.07020342855887218 0.590736243072285 0.04997104958104426
On Oct 28, 1:34 pm, John Harrop wrote:
> This runs into problems with things like (repeatedly rand) though.
How so? The repeatedly function returns a lazy sequence that
(presumably) stores a reference to repeatedly as its generator
function. That instance of repeatedly would, in turn, have to
On Wed, Oct 28, 2009 at 3:56 PM, Tim Clemons wrote:
> How about having hashCode() on infinite sequences drill down into the
> composite infinite sequences until we arrive at the generative
> function? Given that values are generated on demand, the generators
> themselves can be compared.
This
How about having hashCode() on infinite sequences drill down into the
composite infinite sequences until we arrive at the generative
function? Given that values are generated on demand, the generators
themselves can be compared.
To take from your fibs example:
hashCode(iterate f x) = hashCode(x
On Wed, Oct 28, 2009 at 12:05 PM, Mark Engelberg
wrote:
> This is basically the behavior I would expect. I expect that when I
> put two sequences into a set, they are compared for equality, which is
> clearly impossible if they are infinite. I don't think I'd want some
> automatically truncated
agreed, I'm not sure how meaningful it would be to compare two
infinite "things".
On Wed, Oct 28, 2009 at 12:05 PM, Mark Engelberg
wrote:
>
> This is basically the behavior I would expect. I expect that when I
> put two sequences into a set, they are compared for equality, which is
> clearly im
This is basically the behavior I would expect. I expect that when I
put two sequences into a set, they are compared for equality, which is
clearly impossible if they are infinite. I don't think I'd want some
automatically truncated comparison. If I really wanted truncated
comparison, there are
and it's not hard to guess, and then prove, why:
user=> (defn fibs [] (map first (iterate (fn [[a b]] [b (+ a b)]) [1 1])))
#'user/fibs
user=> (take 10 (fibs))
(1 1 2 3 5 8 13 21 34 55)
user=> (.hashCode 12)
12
user=> (.hashCode "foo")
101574
user=> (.hashCode (take 10 (fibs)))
-1796812414
user=>
16 matches
Mail list logo
