I don't think generating 16bit values is beneficial -- either 8bit values for
byte at a time processing or full [u]int32 makes more sense. I think the only
reason for 16bit to come up is ecmascript's notionally 16bit characters.
I would prefer polymorphism of some form, for example
any gimmeRandom(numberOfRandomElements, constructor = [[]Builtin Array
constructor], min = 0, max = 1<<32 - 1) {
var result = new constructor(numberOfRandomElements);
for (var i = 0; i < numberOfRandomElements; i++)
result[i] = reallyRandomValue(min, max);
return result;
}
This would solve all the use cases presented so far (except a string of
cryptographically secure values, which can be handled trivially so i've left
that as a task for the reader ;) ), and would avoid the shortcomings of the
existing array methods (only a finite set of types can be produced as output).
--Oliver
On Feb 16, 2011, at 5:37 PM, Brendan Eich wrote:
> On Feb 16, 2011, at 5:33 PM, Allen Wirfs-Brock wrote:
>
>> On Feb 16, 2011, at 4:54 PM, David Herman wrote:
>>
>>> I say: let's make it typed array in the short term, but TC39 will spec it
>>> as an array of uint32 according to the binary data spec. We will try to
>>> make the binary data spec as backwards compatible as possible with typed
>>> arrays anyway. So in the near term, implementors can use typed arrays, but
>>> when they have implementations of the full binary data spec, they can
>>> change to use those. It'll probably be a slightly backwards-incompatible
>>> change, but by keeping them relatively API-compatible, it shouldn't make
>>> too much difference in practice. Plus we can warn people that that change
>>> is coming.
>>
>> Dave, most browsers other than FF4 internally box all integers with with
>> 32-significant bits.
>
> I'm not sure this is still true. Certainly on x64, but also on x86,
> NaN-boxing has taken over in many VMs.
>
>
>> Some may box with 31 or even 30 significant bits. So if we spec. the value
>> as a uint32 and (they are truly random enough) then at least half and
>> possible 75% or more of the values in the array will be boxed in many
>> browsers. Such boxing will have a much higher cost than immediate uint16
>> values. That's why I propose 16-bit values.
>
> Given the implementors on es-discuss, we should survey first. I'd hate to
> prematurely (de-)optimize.
>
> I agree with David Wagner that the API has to be dead-simple, and it seems to
> me having only 16-bit values returned in a JS array may tend to result in
> more bit-mixing bugs than if we used 32-bit elements, if programmers are
> carelessly porting code that was written for uint32 arrays.
>
> /be
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
