This is a confusion specific to the English language, not consciousness in general. Some languages distinguish between the past-oriented cause-why and the future-oriented goal-why explicitly (e.g. Russian: почему vs зачем).
131 karma · joined June 11, 2015
This is a confusion specific to the English language, not consciousness in general. Some languages distinguish between the past-oriented cause-why and the future-oriented goal-why explicitly (e.g. Russian: почему vs зачем).
I think I'm the same. It's as if I can imagine a geometry, but it doesn't have any texture or colour. It's not black, not grey, not brown... It's a shape in its pure form, maybe like a wireframe, without a physical manifestation.
However, I can imagine music and actually hear it. I had this a couple of times where I "replay" a song in a foreign language I've heard a long time ago, and this time I can parse out more lyrics than before. All inside my head.
...unless your parser strictly implements YAML 1.1, in which case you should be careful to add whitespace around commas (and a few other minor things). This is a valid JSON that some YAML parsers will have problems with:
{"foo":"bar","\/":10e1}
The very first result Google gives me for "yaml parser" is https://yaml-online-parser.appspot.com, which breaks on the backslash-forward slash sequence.I don't know about "most" countries, but my American colleagues in Germany and Switzerland complained about the difficulty of doing anything related to finance (banks, brokers, taxes) because of their extra tax liability. I personally had to sign quite a few forms certifying that I am not a US citizen or a greencard holder or in any other way tax liable in the US, so it does seem to be a big deal.
But the system still has some connection to the outside world, right? That means we could run some heavy GPU load and measure the variation in its power consumption, which apparently has been tried before: https://www.helpnetsecurity.com/2018/04/13/data-exfiltration...
Along these lines, the excess heat has to go somewhere, so maybe one could measure the variation in the work of the coolant system. I couldn't find any research about it right away (BitWhisper is similar, but a bit different), but I trust someone has already tried that.
To be fair, Python 3 provides a very clear error message if you try to use print as a statement, although I don't know when exactly that was added:
$ echo 'print "Hello World"' > test.py && python3 test.py
File "test.py", line 1
print "Hello World"
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Hello World")?...only to find it days later (= billions of years of simulated time), by which point the simulated life had figured out that their universe was written hastily and its laws were full of subtle bugs, like floating-point rounding errors showing up in physical measurements. Their technological advance let them move stars around, which they grumpily arranged in a message saying "your code sucks".
Can't find it at the moment, does anyone recognise the reference? It could be in one of these books, I suppose, but I don't have them.
One method is the Lucy-Richardson deconvolution [1], which is an iterative algorithm, and here [2] is the best practical example I could find right away. Unfortunately the text is not in English, but the illustrations and formulae might be enough to give some intuition of the process.
[1] https://en.wikipedia.org/wiki/Richardson%E2%80%93Lucy_deconv...
So each task gets 16k of stack space, but what if it runs out of it? These are allocated from the "main" heap, so they won't exactly run into each other, but might trigger UB or crash the program. This is something that a real scheduler (like the one in the OS's kernel) would have to deal with anyway, so how does, say, Linux, solve this? Giving a lot of stack space to each running thread would lead to fragmented and underused memory, or is it not a concern at the stack spaces you'd normally deal with?
Wouldn't it be more appropriate to compare deaths (305) to the number of people successfully recovered (348 as per the same page)? This gives the survivability rate of 53%, which does sound scary (and I'd love to be proven wrong here).
It will also annoy users of password managers with auto-filling capabilities. "password" is normally used for actual passwords.
Besides, nothing stops the attacker from replacing your code with a faster implementation.
It's curious to hear this from Nielsen himself. Personally, learning about Grover's algorithm was when I realised why "if you're not surprised by quantum mechanics, you cannot have understood a thing" (attributed to Bohr, I think).
https://web.archive.org/web/20180420113021/http://pub.gajend...
To the topic, I think this quote from the article is very important to note here: “Of course, I do not do all of this every day, but I have done all of it at one time or another and most of it regularly.”
It is nice to have an idea of how you write a parser for a language, but I do not believe the author advocates for being able to write one of the top of your head. Same with most other points.
I am assuming this does not apply to personal projects, but then why would you contribute Google code to something that you cannot use anyway due to licensing issues?