For something to have the ability to become conscious it need some form of intelligence. There is absolutely zero intelligence in any ML/AI with today's models. None. No wisdom, nothing. Not even remotely close to a retarded cockroach.
The only way "AI" would be conscious would be if the 'machine' it ran on could be possessed by something, somehow. The question then becomes, possessed by what.. We probably don't want that.
> The majority of these escape codes start with \x1b[
This is actually the 7-bit version for CSI. A less known variation is the 8-bit CSI which is simply \x9b and is the same as \x1b[ combined. So, for example \x9b33m does the same as \x1b[33m .
Unfortunately, there exist a couple of (8-bit) terminals that don't support this version.
Since many here uses desktops I wanted to share a small tip, but first an anecdotal observation: I got my first computer at age 10-11 back in the 80s (a VIC20) and we only had a 50Hz (Europe) interlaced 21" TV as a "monitor" at that time. After using it a few months even my teacher pointed out I was getting dark circles under my eyes. My sleep was getting worst. Many years later and years in front of computer screens I also found that I had gotten delayed sleep-phase syndrome as well - this at a time CRTs was the norm. For those who say that this light is not enough to affect sleep, I would say you're wrong. But that's anecdotal..
As to the tip: here is what I did - in your color management settings, create a ICC profile which turns off almost all blue and most green. This will leave you with a darker orange color which is perfect if you need to sit late and work. This also affect all programs on your screen. You can also use tools to create ICC profiles that inverts bright colors etc.
Now you can simply toggle between your normal ICC and the dark/orange one.
Also we know that pre-teens are more than twice as sensitive to light as people in their late teens [1], and CRTs were 9300K also [2], though they were quite a bit dimmer than current ones.
I think this for the most part is useful for WASM, but also storing/reading/writing to binary buffers as in handling file formats that stores (u)int64s (such as f.ex. CAF on the Mac) and with binary protocol responses from environments such as Java/.Net that already supports bigints (and of course, eventually Node), finance calculations.. nice.
Just curious, how will you deal with things like triple-comparing (`0x1n === 0x1` ?) internally (from the perspective of performance)?
> BigInts [..] are always signed (in ref. to the >>> operator)
Disclaimer: I haven't taken a deep-dive into the BigInt spec yet, but things like this comes to mind (say you want to shift and mask using unsigned 64-bit values):
When mixing Number and BigInt, abstract equality (==) works fine, but strict equality (===) is always false, since they are two different primitive types.
Most bitwise operators are allowed, so long as all operands are the same type (Number or BigInt). The only exception is zero-fill right shift (>>>) since that doesn't make any sense with respect to BigInts.
From my console: (node 10 with --harmony-bigint)
> 1n == 1
true
> 1n === 1
false
> 12345n >> 1
TypeError: Cannot mix BigInt and other types, use explicit conversions
> 12345n >> 1n
6172n
> 12345n >>> 1n
TypeError: BigInts have no unsigned right shift, use >> instead
Yes, I'm aware of this, but I was more asking in the realm of internal performance/optimization (as I sort of point out - and not necessarily because of the comparer). F.ex. they are in all practicality the same integer and in other cases, IIRC (please correct me if I'm wrong), V8 optimizes the native Number that could easily be stored internally as IEEE-754, to actual internal integers when using bit-ops on them (to indicate to the optimizer you handle integers) and so forth.
In this case I was curious if this would be optimized internally so these comparisons could be moved directly to CPU registers as integers (assuming being on a 64-bit arc) and compared there, for example. But, future will tell - I'm equally aware of that optimizations is not first priority at this stage (it's just me excited to see this manifest). It's in any case a welcome and useful feature optimized or not.
apaprocki linked (thanks!) to a method that can do unsigned right-shift via a method (1.1.11 BigInt::unsignedRightShift).
> I think this for the most part is useful for WASM
Also, for compile-to-JS versions of languages where the hosted language has BigInts, which now [0] can be more fully equivalent to the non-JS implementations of the same language. I think it's a while before GC-dependent languages will be WASM hosted, but there are a lot that compile to JS.
[0] where “now” is “sometime in the future where this has broad support among browsers”
This looks to have nothing whatsoever to do with WASM. It is very much not just (u)int64 support, which is all WASM needs/wants. This is proper BigNumber. Which you could use for (u)int64 support, sure, but it'd be incredibly slow at it vs. the much simpler to do "just use an actual hardware 64-bit number"
The only way "AI" would be conscious would be if the 'machine' it ran on could be possessed by something, somehow. The question then becomes, possessed by what.. We probably don't want that.