188 karma · joined June 29, 2017
And in English, you don't have the T/V distinction. In languages which do have one, it's impossible to talk to someone without implying something about their relative social status.
This is a video of someone using an electromechanical Chinese typewriter: https://www.youtube.com/watch?v=DRKAUDHk_MM -- it's hard to appreciate the topic without seeing one used.
A lot of the alternatives, like LyX, are too opinionated to paste into from the browser.
The loss aversion hypothesis is the hypothesis that given the choice between either of the following two scenarios:
- Having an object x and then risk losing it.
- Being offered an object x but risk not getting it.
people are more "motivated" by the first than by the second. The claim moreover is that: - This is a universal motivator, which means it must explain "economic behavior" (which you mention) as well as anything
else. The fact that -- as the article says -- people prefer *keeping* a stock which is just as likely to lose in value as
to gain, is a *perfect* example to illustrate that it is *not* a universal motivator.
- That it is not rational. There are cases where losing something, like for instance money, is *truly* more damaging
than gaining the equivalent amount of money. For example, if I lost $100,000 it would be much more devastating than if I
gained $100,000 -- in this scenario, it's not a psychological *bias* but in fact a completely rational belief. This example
is in the article. You can not use examples like this one to argue in favour of "loss aversion", because there would be no
evidence of an irrational bias.
Also, the fact that you keep applying the "loss aversion" hypothesis as broadly as possible, to things like wars and arguments, suggests you're assuming it applies everywhere. What about the stock example, which is mentioned in the article? That ought to prove you wrong, no?Also some NP-COMPLETE problems are not fixed parameter tractable as far as we know, but some are.
* As long as you have good coordination.
> And yes, they are the same thing when you realize that the hardware is exactly the same
Quantum computers don't actually exist yet. It's a theoretical model. There's no hardware.
Also I remember that cryptographers consider any leaking of information about a secret to be a break. They call this "semantic security". Maybe there's something special about crypto that means people have to be maximally paranoid. I wonder what level of paranoia is appropriate for CPUs.
Actually, if NetSpectre can already leak information about a plaintext or secret key, then that already breaks all of cryptography from some cryptographers' point of view.
Another thing: Nation states may learn how to execute Spectre attacks faster than academia does. Then again, those same nation states would also want to switch to non-Spectre-prone computers, which would be visible enough for other people to start changing. Or maybe I'm putting too much faith in the IT skills of nation states.
Given all that, I don't know what safety margin is appropriate for CPUs. When do we consider all of our CPUs to be broken? Is it when Spectre attacks are being used to extract our financial info en masse? Is it soon? Or is it when governments start changing their computers (assuming governments are even that clever -- see the NHS and Wannacry)?
Oppositely, the variable X of a polynomial behaves much like an infinity, but is not invertible.
Their argument depends crucially on whether infinitesimals/infinities are invertible.
Or what about those "tech support" calls you get, where they try and take over your Windows computer? It would be fun to follow their instructions in ReactOS, mainly out of curiosity (and to screw with them).
Seriously, next time you get a call from one of them, give them an excuse to ring you back later; then install Virtualbox, ReactOS, some mic and screen recording software, and wait.
In contrast, dynamic programming is based on stitching together optimal sub-solutions.
I find it's the least limiting because you can draw anything, the easiest to use because you don't have to learn a GUI or a language, and the fastest -- yet software people will still wonder how they can GREP it. Another contra is legibility and possibly aesthetics.
char foo[9]; foo[] = "abc"; foo[3..3+5] = "1234";
`foo` is an array. `foo[3..8]` is a slice, which is an object that does its own bounds-checking. I don't think the heap is used here.Another explicit example:
char foo[5] = "abcd"; // still NUL-terminated, carries length aswell
char[] bar = foo[2..3]; // a fat pointer with length 1
bar[0] = 'C';
printf(foo); // abCd
bar[1] = 'D'// ERROR!!! bar has length 1
Note that the array `foo` is now bounds-checked, which may affect backwards-compatibility. Also, `bar` is no longer null-terminated, which means you can't do printf on it. - Word
- Emacs/VIM + Markdown + Latex + Pandoc
- VScode/Atom + Markdown + Latex + Pandoc
- LyX
Very cool otherwise.I'm thinking a few thoughts:
- Interpreted programs can carry out Spectre attacks
- Interpreted programs are un-analysable using a technique that does binary analysis
- This technique would insert fences "everywhere" in an interpreter, adding significant overhead
[edit]I'm thinking it matters a lot whether the analysis is done at run-time or static. If the analysis is static, and it was done on the Python interpreter for instance, it would have to be very pessimistic. But if it's done at run-time, it might not need to insert as many "fences".
a*b + a*c = a*(b + c)
which you ought to remember from school as "factoring/factorization". Except in this case, " * " is replaced with "V", and "+" is replaced with "->". In mathematics, you call that a "distributive law". Some more examples are a^c * b^c = (a*b)^c
p/\q V p/\r = p/\(q V r)
(pVq) /\ (pVr) = pV(q /\ r) ((p V q) -> (p V r)) -> (p V (q -> r))
It's easy to justify this tautology by considering the case when (p) is true and (p) is false.By contrast, the proof in PM and by LT strike me as highly unintuitive. I guess it's an example of using Hilbert Deduction instead of Natural Deduction, where Natural Deduction is closer to how people normally prove things. For programmers, it's as if they programmed in Combinatory Logic [1] instead of Lambda Calculus[2].
[1] - https://en.wikipedia.org/wiki/SKI_combinator_calculus [2] - https://en.wikipedia.org/wiki/Lambda_calculus
Is the lesson that since professors are "less free" than everyone else, they criticize everyone else out of bitterness? Or is it that since they're so specialized and able to make a living only in their specialty, they don't need to practise good judgement outside their discipline? Is it that they live in an ivory tower and don't know the difference between theory and practise? What does that quote mean?
...
Maybe they "abdicate their freedom" when they have to teach students and battle administration. I seriously don't know what that quote means.
I'm thinking it could look like this:
import numpy as np
def M1 %*% M2 with same precedence as *:
return M1.matmul(M2)
foo_matrix = np.matrix([[1,1],[1,1]])
bar_matrix = np.matrix([[2,2],[2,2]])
print(foo_matrix %*% bar_matrix)
Also, it would be nice to have a pipe operator `%>%` such that foo %>% f()
is equivalent to f(foo)
The alternative is to make f a method of foo, and then you can write foo.f()
But what happens if I don't want f to be a method? I just want the style of writing the f after the foo, but I don't want the baggage of OOP. Is that anti-Pythonic?