Re: Re: Re: Re: Bite Buckets JAPH

Replies are listed 'Best First'.
Re: x5 Bite Buckets JAPH by davido (Cardinal) on Sep 08, 2003 at 16:23 UTC
Anyone reading this far into the thread deserves the JAPH explanation (and probably already understands it anyway). The JAPH relies on the less-known and seldom-used fact that evaluating an entire hash (%hash) in scalar context returns a pair of numbers expressed as a fraction, as in "7/16", meaning seven buckets used, sixteen buckets allocated. In developing the JAPH, I ran a quick c-style for loop to populate a hash with unique small integer keys and null string values. As each key/value was added, I printed the iteration number and the bucket info. I then used that data as a crossreference to see how many keys of these small integers had to be created before I would get to, for example, 32 buckets in use (I didn't care about the total allocated). Earlier I had been surprised to find it's not a direct 1:1 keys to buckets ratio. 32 buckets could be used to represent the ordinal value 32, which could be used to represent the ascii value of " " (space). The regexp simply pulls out the first value (buckets used) and doesn't bother with the second value (buckets allocated). As I began coding the JAPH, I simply used a loop to perform the same population technique, but rather than print the results, I just used the results to drive the translation into ASCII values. Next, I came up with a space-saving algorithm that read the ord number, and then any following comma-delimited integers, which would specify the position within an array where that particular character should be inserted. For example, "32 4,12" would mean stick chr(32) in the 5th and 13th element (zero-indexed, of course) of the array. Once the array is populated, print it. It surprises me that Liz's method of setting the ENV variable related to hashes to zero would make 5.8.1 work ok with this methodology. My understanding was that env variable dealt with the order of key/value pairs. This JAPH doesn't rely on the order as much as it relies on the allocation and use of space. But nevertheless, if her method works, I'm pleased to hear it. And am pleased that anyone would take the time to figure out the kludge to my kludge. I'm nearly equally surprised that the JAPH worked in the first place, and especially so, across OS platforms. I figured that it would be more difficult than it was to assure repeatability across OS platforms. Dave "If I had my life to do over again, I'd be a plumber." -- Albert Einstein	[reply]

Replies are listed 'Best First'.

Re: x5 Bite Buckets JAPH
by davido (Cardinal) on Sep 08, 2003 at 16:23 UTC

The JAPH relies on the less-known and seldom-used fact that evaluating an entire hash (%hash) in scalar context returns a pair of numbers expressed as a fraction, as in "7/16", meaning seven buckets used, sixteen buckets allocated.

In developing the JAPH, I ran a quick c-style for loop to populate a hash with unique small integer keys and null string values. As each key/value was added, I printed the iteration number and the bucket info. I then used that data as a crossreference to see how many keys of these small integers had to be created before I would get to, for example, 32 buckets in use (I didn't care about the total allocated). Earlier I had been surprised to find it's not a direct 1:1 keys to buckets ratio. 32 buckets could be used to represent the ordinal value 32, which could be used to represent the ascii value of " " (space). The regexp simply pulls out the first value (buckets used) and doesn't bother with the second value (buckets allocated).

As I began coding the JAPH, I simply used a loop to perform the same population technique, but rather than print the results, I just used the results to drive the translation into ASCII values.

Next, I came up with a space-saving algorithm that read the ord number, and then any following comma-delimited integers, which would specify the position within an array where that particular character should be inserted. For example, "32 4,12" would mean stick chr(32) in the 5th and 13th element (zero-indexed, of course) of the array. Once the array is populated, print it.

It surprises me that Liz's method of setting the ENV variable related to hashes to zero would make 5.8.1 work ok with this methodology. My understanding was that env variable dealt with the order of key/value pairs. This JAPH doesn't rely on the order as much as it relies on the allocation and use of space. But nevertheless, if her method works, I'm pleased to hear it. And am pleased that anyone would take the time to figure out the kludge to my kludge. I'm nearly equally surprised that the JAPH worked in the first place, and especially so, across OS platforms. I figured that it would be more difficult than it was to assure repeatability across OS platforms.

Dave

"If I had my life to do over again, I'd be a plumber." -- Albert Einstein

[reply]