Re: UInt8ClampedArray Bitwise operators?
I can see why, since nearly everyone depends on that coupling. Minifiers depend on it. Mixin utilities depend on it. Breaking the Web would be an understatement. On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote: Caitlin Potter wrote: ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the element. I recall from an old presentation on Value Types that overloading `[]` was off limits because those invariants needed to keep working. No operator proposal has included property access, not so much for reasons you give (which are good ones) but for separation of concerns. Allen did propose: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation This was controversial in the committee when last considered. Just sayin'! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Oh. Pardon my ignorance. Misunderstood the idea. On Wed, Aug 12, 2015, 23:19 Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Aug 12, 2015, at 7:30 PM, Isiah Meadows wrote: I can see why, since nearly everyone depends on that coupling. Minifiers depend on it. Mixin utilities depend on it. Breaking the Web would be an understatement. Not so clear. The proposed default default for an indexed access would be exactly the same as for legacy property access. It is pretty much just providing a signal to the meta level that opens the possibility of newly defined object treating [ ] member accesses differently from . member accesses. Allen On Wed, Aug 12, 2015, 14:36 Brendan Eich bren...@mozilla.org wrote: Caitlin Potter wrote: ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the element. I recall from an old presentation on Value Types that overloading `[]` was off limits because those invariants needed to keep working. No operator proposal has included property access, not so much for reasons you give (which are good ones) but for separation of concerns. Allen did propose: http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation This was controversial in the committee when last considered. Just sayin'! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Oh, forgot to add a bit to those snippets to divide the bytes_per_element into
bits, but yeah
On Aug 11, 2015, at 2:55 PM, Michael McGlothlin mike.mcgloth...@gmail.com
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 little...@chromium.org 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 isiahmead...@gmail.com
wrote:
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
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 mike.mcgloth...@gmail.com
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 little...@chromium.org 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 isiahmead...@gmail.com
wrote:
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
Re: UInt8ClampedArray Bitwise operators?
ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. Proxies enforce invariants, which is problematic for this use case because it’s A) expensive, and B) also restricts you from “lying” about the actual properties which exist on the element. I recall from an old presentation on Value Types that overloading `[]` was off limits because those invariants needed to keep working. On Aug 12, 2015, at 1:44 PM, Daniel Ehrenberg dehrenb...@chromium.org wrote: On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: 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. ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: 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. ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Also `instanceof` overloading via `Symbol.hasInstance` On Wed, Aug 12, 2015 at 10:44 AM, Daniel Ehrenberg dehrenb...@chromium.org wrote: On Wed, Aug 12, 2015 at 4:50 AM, Caitlin Potter caitpotte...@gmail.com wrote: 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. ES2015 already has element accessor overloading with proxies, right? It's everything else that's missing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
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 little...@chromium.org 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 isiahmead...@gmail.com
wrote:
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Bits and bytes are fundamental to JavaScript too, which is why the
language has, for a long time, included operations like , , ,
, |, ^ and ~ on Numbers, exposing the ability to manipulate 32-bit
integers. This is comparable to what C provides. Like C, JavaScript
has a relatively minimal standard library, so collections of these are
not included in the standard library itself.
Uint8ClampedArray is more of a historical artifact than something you
should actually aim to use. Uint8Array is probably what you'd want to
get at as a basis for a user-level library.
On Tue, Aug 11, 2015 at 5:20 PM, Daniel Ehrenberg
little...@chromium.org wrote:
Bits and bytes are fundamental to JavaScript too, which is why the
language has, for a long time, included operations like , , ,
, |, ^ and ~ on Numbers, exposing the ability to manipulate 32-bit
integers. This is comparable to what C provides. Like C, JavaScript
has a relatively minimal standard library, so collections of these are
not included in the standard library itself.
Uint8ClampedArray is more of a historical artifact than something you
should actually aim to use. Uint8Array is probably what you'd want to
get at as a basis for a user-level library.
On Tue, Aug 11, 2015 at 11:55 AM, Michael McGlothlin
mike.mcgloth...@gmail.com 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 little...@chromium.org
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 isiahmead...@gmail.com
wrote:
Do SIMD types solve your problem?
https://github.com/tc39/ecmascript_simd
On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Daniel Ehrenberg wrote: Uint8ClampedArray is more of a historical artifact than something you should actually aim to use. Uint8Array is probably what you'd want to get at as a basis for a user-level library. Thanks for posting this, Daniel. Just to be super-clear (and I was around when it was born), Uint8ClampedArray is *totally* a historical artifact (of the HTML5 canvas element). Avoid unless you really are doing canvas-y things. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
I don't think my earlier mail went through, so I'm posing it below for
the record:
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 Tue, Aug 11, 2015 at 5:24 PM, Brendan Eich bren...@mozilla.org wrote:
Daniel Ehrenberg wrote:
Uint8ClampedArray is more of a historical artifact than something you
should actually aim to use. Uint8Array is probably what you'd want to
get at as a basis for a user-level library.
Thanks for posting this, Daniel. Just to be super-clear (and I was around
when it was born), Uint8ClampedArray is *totally* a historical artifact (of
the HTML5 canvas element). Avoid unless you really are doing canvas-y
things.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: UInt8ClampedArray Bitwise operators?
Do SIMD types solve your problem? https://github.com/tc39/ecmascript_simd On Mon, Aug 10, 2015, 10:58 Michael McGlothlin mike.mcgloth...@gmail.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
