Well, you could just use typed arrays for this, and add a helper function which 
retrieves the bit at a specific index. Like, something like this:

```
function bitset_get(ta, i) {
  var e = (i / ta.BYTES_PER_ELEMENT) | 0;
  i = i %  ta.BYTES_PER_ELEMENT;
  return (ta[e] >> i) & 1;
}
```

You could do similar stuff for manipulation, like

```
function bitset_flip(ta, i) {
  var e = (i / ta.BYTES_PER_ELEMENT) | 0;
  i = i %  ta.BYTES_PER_ELEMENT;
  ta[e] ^= (1 << i);
  return (ta[e] >> i) & 1;
}
```

If your typed array is of a smallish type, like unsigned 16 bits, you should be 
able to predictably use SMI integrals when manipulating them, which might 
prevent some accidental floating point bugs.

And you could even make these robust by ensuring they match the bitwise and 
bytewise endianness of the underlying architecture, with some simple tests.

Operator overloading or value types might make it look a lot prettier some day 
(though iirc element assessor overloading was off limits), but you could get 
pretty far by baking it into a compile-to-js language.

If people were using stuff like that commonly, it might end up in the standard 
lib some day.

Apologies for any typos or nonsense grammar, Swype is bad

> On Aug 11, 2015, at 2:55 PM, Michael McGlothlin <[email protected]> 
> wrote:
> 
> SIMD types appear almost as limited in size as using numbers. Often I need to 
> manipulate thousands or millions of bits efficiently so fumbling around with 
> numbers is messy.
> 
> I've looked at several implementations on npm but none seemed very mature or 
> standard.
> 
> I guess it's philosophical as much as anything. In my mind the heart of 
> programming is bits and bytes so I find it odd that most programming 
> languages treat bits and bytes as strange uncles. In my mind all other data 
> types are derived from bits and bytes so it should be possible to easily 
> derive my own types this way or see the bits behind the types that are 
> built-in.
> 
> In this case I'm implementing a bit index (which is something I use a lot) 
> for quickly finding relationships in complex data. Often I want to mess with 
> bits for working with specifics of file formats and network protocols. When 
> working with large numbers it's nice to not worry about limits. And I work 
> directly with bits when doing electronics.
> 
> I'm not surprised that it's not supported but it seemed to go with the idea 
> of a byte array so I was hopeful. And it seems more generally useful than 
> things like SIMD types.
> 
> Thanks,
> Michael McGlothlin
> Sent from my iPhone
> 
>> On Aug 10, 2015, at 7:36 PM, Daniel Ehrenberg <[email protected]> wrote:
>> 
>> SIMD types have bitwise operators, but SIMD.js exposes just fixed-size
>> vectors that are optimized to what hardware can optimize certain
>> operations for. A future extension (the "long SIMD API") may operate
>> on whole arrays. I wouldn't recommend using SIMD.js unless you really
>> feel like you're taking advantage of the better performance, and the
>> particular vector size works for your requirements.
>> 
>> The point of SIMD is to expose higher-performance hardware features to
>> users. You may want to use this for implementing bitwise operations in
>> user code. However, if you don't need that, it may be enough for you
>> to use existing operators & | ^ ~ etc, in a loop. A search on npm
>> yields tons of bitarray libraries which probably do this already,
>> though I haven't assessed how good they are.
>> 
>> If you were getting at operator overloading in particular, operators
>> are already well-defined on things like Uint8Array: Roughly speaking,
>> they will call .valueOf() and, if that results in a Number they will
>> do the operation on the underlying Number. There's no built-in valueOf
>> method for that object, but you can always monkeypatch one in. Here's
>> an example session in the V8 command-line shell:
>> 
>> d8> Uint8ClampedArray.prototype.valueOf = function() { return 1 }
>> function () { return 1 }
>> d8> new Uint8ClampedArray([1, 2]) << 3
>> 8
>> 
>> The downside of doing anything beyond existing npm packages and
>> changing the language is that it increases complexity. What is the
>> upside you have in mind to building it into the language?
>> 
>> Have fun!
>> Dan
>> 
>>> On Mon, Aug 10, 2015 at 4:35 PM, Isiah Meadows <[email protected]> 
>>> wrote:
>>> Do SIMD types solve your problem?
>>> 
>>> https://github.com/tc39/ecmascript_simd
>>> 
>>> 
>>> On Mon, Aug 10, 2015, 10:58 Michael McGlothlin <[email protected]>
>>> wrote:
>>>> 
>>>> Would there be a downside to extending Bitwise operators to work with
>>>> typed arrays such as UInt8ClampedArray? To me it seems natural to want to
>>>> perform bit operations on these. Or is there a better way to make a BitSet
>>>> that I'm missing?
>>>> 
>>>> 
>>>> Thanks,
>>>> Michael McGlothlin
>>>> Sent from my iPhone
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [email protected]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
>>> 
>>> _______________________________________________
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>> 
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to