With CRC32 you can only ever have 2^32 different values, which is not
different enough when x has more than 2^32 items.
Reducing the chance of collision is the main point of hashing.
On Wed, Jul 30, 2014 at 9:30 PM, bill lam <bbill....@gmail.com> wrote:
> Sorry Roger. I forgot pointer arithmatic.
>
> BTW I think hardware crc32 can also be used in J64. What will
> be its downside apart from higer chance of getting collison when
> compared to crc64?
>
> Ср, 30 июл 2014, Roger Hui написал(а):
> > Actually, no. z would be declared to be a pointer of the appropriate
> type
> > and z=z+1; would make z point to the next item.
> >
> > z=z+sizeof(*z); would in fact be wrong. For example, if z points to a
> > 4-byte integer, sizeof(*z) would be 4 and z=z+sizeof(*z); would make z
> > point to 4 items further. You can verify this by writing and running a
> > short C program or by rummaging around in a C debugger.
> >
> >
> >
> >
> > On Wed, Jul 30, 2014 at 7:05 PM, bill lam <bbill....@gmail.com> wrote:
> >
> > > Sorry for being meticulous, the last step probably better be expressed
> as
> > > z=z+sizeof(*z)
> > > On Jul 31, 2014 12:37 AM, "Roger Hui" <rogerhui.can...@gmail.com>
> wrote:
> > >
> > > > Thanks for your comments and questions.
> > > >
> > > > 0. The C code presented is only for a primitive datatype (in C). The
> > > paper
> > > > (script) says this. The basic hashing logic still works for other
> > > > datatypes, but instead of using == and != (the C equals and
> not-equal)
> > > > you'd need something more elaborate. Still simple conceptually
> because
> > > in
> > > > your head you can subsume the details by thinking "match" or "not
> match".
> > > >
> > > > 1. The APL\360 defn assumes that the left argument is a vector. The
> > > > "anomaly" you found only occurs if the left argument is not a vector.
> > > >
> > > > 2. *z++=*h<0?xn:*h; is equivalent to:
> > > >
> > > > blah= *h<0 ? xn : *h; // if *h is less than 0 then xn, otherwise *h
> > > > *z=blah; // set the location pointed to by z, to blah
> > > > z=z+1; // increment the pointer z by 1
> > > >
> > > > This is standard C. In that context the statement is also
> equivalent to
> > > > z[i]=*h<0?xn:*h;
> > > >
> > > >
> > > >
> > > > On Wed, Jul 30, 2014 at 8:53 AM, Brian Schott <
> schott.br...@gmail.com>
> > > > wrote:
> > > >
> > > > > Roger,
> > > > >
> > > > > Because my C is so weak I could use some explanation in words of
> what
> > > > the C
> > > > > is doing, not in general, but to discuss the questions below.
> > > > >
> > > > > Would you say that the basic approach that is being taken in DO's
> is
> > > more
> > > > > like the APL\360 definition or more like the Extended definition. I
> > > > guess I
> > > > > am a little surprised that a Loop is required through both the x
> and
> > > the
> > > > y
> > > > > values. In the Dictionary entry for Index of is the following
> example,
> > > > > where the y component is not an atom, but a string. Is that a
> typical
> > > > case
> > > > > for which y must be looped through as well as x? I thought maybe
> the
> > > > answer
> > > > > was yes, and tried.
> > > > >
> > > > > A=: 'abcdefghijklmnopqrstuvwxyz'
> > > > > m=: 5 4 $ 12{. A
> > > > > m;(m i. 'efgh');(1{m);(4{m)
> > > > >
> > > > > I then found a slight "anomaly" though, trying the APL\360
> definition
> > > > with
> > > > > that example.
> > > > >
> > > > >
> > > > > +/*./\m~:/'efgh'
> > > > > 1 5 5 5
> > > > > 5 1 5 5
> > > > > 5 5 1 5
> > > > > 5 5 5 1
> > > > >
> > > > > However that "anomaly" was fixed by the Extended definition, so
> maybe
> > > > > therein is an example of why the y value must be looped through,
> too.
> > > > >
> > > > > +/*./\m~:/&:<"(_1+#$m)'efgh'
> > > > > 1
> > > > >
> > > > > Can you comment, please?
> > > > >
> > > > > Also, in the second DO there is a phrase like this:
> *z++=*h<0?xn:*h;
> > > > >
> > > > > I am familiar with the B?T:F part of the phrase, but I have never
> seen
> > > a
> > > > ++
> > > > > followed by an assignment. Does that just add one to the result
> from
> > > the
> > > > > assigned amount?
> > > > >
> > > > > Oh, and thanks for posting your paper.
> > > > >
> > > > >
> > > > > --
> > > > > (B=)
> > > > >
> ----------------------------------------------------------------------
> > > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > > >
> > > >
> ----------------------------------------------------------------------
> > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > > >
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
