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 <[email protected]> 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" <[email protected]> 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 <[email protected]> > > 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
