Area under ROC forces you to conflate these two.
Why not evaluate the probability estimation directly, using Brier score [1] or something similar?
1,257 karma · joined August 29, 2011
Area under ROC forces you to conflate these two.
Why not evaluate the probability estimation directly, using Brier score [1] or something similar?
I've encountered a couple annoyances:
A. Using rustc to link somehow removes debugging information from static libraries I wrote in assembly [2]. This is extremely annoying, but I haven't had time to really look into it and it seems others can't reproduce it.
B. There seem to be some occasional oddball problems when stepping through code. Like it'll skip lines, or stay on the same line for many steps. And also an annoyance regarding how that VS Code extension handles "Step Into" for functions you don't have the source for: you can easily get into an infinite popup situation and have to restart the debugger.
IMO the sad truth is that if a great debugger is a prerequisite to use a language, then you're limited to about 5 total languages.
[1] https://marketplace.visualstudio.com/items?itemName=webfreak...
Have you been on a university campus recently?
Contrary to what some reactionary conservatives seem to think, they are not generally oppressive places with no tolerance for conservative thought.
Yes, occasionally 19 year olds say and do some silly things. That's kind of what being young and having your first taste of adulthood is supposed to be about. And if you only consume media that highlights those silly things and never actually visit a university and talk to young people, yeah, you can easily get a very negative view of what universities and academic culture are like.
> People are classified as "racist" for believing that the culture that came out of northern Europe is not inherently oppressive.
Well, it is inherently oppressive, as is just about every other traditional culture, and citizens have to be constantly vigilant about to make sure that oppressive nature is held at bay as much as possible. Can there really be any doubt about this? Consider, among many other facts, the fact that Alabama just very nearly elected to the US Senate a man who thinks the US was better under slavery and that the constitutional amendments granting women and blacks the right to vote should be revoked. If that's not enough to convince you that racism is a serious problem I don't know what would be.
Well, here's my bet on what will happen:
3. There will be no immediate catastrophic consequences. Over time, the Internet will become less amenable to innovation and small players and will just overall be worse than it would otherwise. But there will be no sudden dramatic change that will spur action for people who weren't already concerned.
1. Non-engineers are better leaders because they can find solutions to "wicked problems", problems with many interacitng parts where there is no predefined objectively right or wrong solution.
2. Non-engineers are better leaders because they are better at persuading others that their shitty solutions are actually good.
I might buy #2 (for some definition of "better leaders"); I'm not so sure about #1.
In fact, in my experience it's not even usually possible to read material before the lecture because students are only given at best a vague idea of what specifically is coming next.
> Its astonishing how many students resist this fact, even when it is clearly spelled out for them.
I've taken a lot of classes, I've been a teaching assistant for a lot of classes, I've observed a lot of classes, and I've never gotten the impression that the instructor expected the students to have already looked at the material. Certainly no one ever said that explicitly.
I will say that it is true that the handful of times I tried to structure my class differently and have students read material on their own before lecture, they were indeed resistant and it didn't go well. And I do think that would be a better approach. But my point is that this is overwhelmingly not what is generally expected of students, at least in my experience, mostly at state colleges in the US.
But it's completely arbitrary that you consider this "a compiler optimization" as opposed to "the way the language behaves." The languages you're used to work the way you describe: if the stars are aligned, a particular compiler may do TCO as an extra optimization.
But there is absolutely no reason it has to be this way. It is perfectly possible for a language standard to mandate that TCO must happen and to specify in an easily understood way when it must happen. As Scheme did over 40 years ago.
Why? I find recursive functions are often simpler to understand and write than iteration. Why does the compiler need to stop me from doing so? You write "technically" as though it were just an obscure technicality that it's possible to implement a function call without taking up excessive stack space, but to my mind it's a fundamental fact.
> Iteration ain't that hard either folks, and it has the notable advantage of mapping more obviously to the behavior of actual machines we use to execute our code.
In what sense is this true? Recursive function: update these variables (in registers or memory) and jump back up to this instruction. Iteration: update this variable and jump back up to this instruction.
There's a spectrum between "just keep trying tons of crap and see what works" and "do this simple, well-understood calculation to see exactly what will work." Is it not obvious why it's nicer to be on the latter end of the spectrum than the former?
To clarify: linear functions would still be differentiable without an activation function. The problem is that the composition of linear functions is just another linear function, so you gain nothing by having multiple layers; you might as well just do some kind of linear regression or classification. Activation functions introduce nonlinearity so that deep learning methods can hopefully learn things linear methods can't.
Consider doing less. If you are working a full time job, then depending on exactly how serious you are, 3 learning projects is likely overkill. (But I tend to do the same thing myself.)
Pick the resources you'll use in advance. I've generally had a negative opinion about video lectures, preferring books, but I've somewhat changed my thoughts lately. In particular it's nice to be able to follow a course as it was taught at a serious university, with a syllabus and schedule all laid out for you.
Set a weekly schedule in advance. Something like, M/F I'll watch a data science lecture and Tu/Th I'll do art. Whatever. Include a planned endpoint: by this date I will be finished with the 9 chapters of this book I plan to cover.
Each evening, write a brief journal entry about what you accomplished that day. Also write out a schedule for the next day. I like to put at the top of my daily schedule a list of the major tasks I want to accomplish that day, and then also a couple "extras", which are things I can work on if I turn out to have extra time. The extras can be large or small, but it's nice if you have a small one because you can cram it in wherever you have free time. Even something like "Problem 12.3 from this textbook, which I couldn't figure out last week". If you randomly turn out to have 10 minutes free, well pull out your notebook and think about that problem for 10 minutes.
(By the way, I know an eminent mathematician, one of the few who has done serious work in multiple fields, who says one of the attributes that has helped him the most is his ability to efficiently context switch and get serious work done throughout the day. If he has a random 18 minutes free, he is going to make 18 minutes' worth of progress on a research project.)
Jerry Seinfeld's "Don't break the chain" idea is nice.
As far as tips for learning: engage and fight with the material, do projects incorporating what you're learning, make connections to other things you know. Incorporate reviews of earlier chapters/lectures, rather than just continually charging ahead. There's a bunch of resources for how to learn (see for instance those mentioned in this HN thread [1]), which I think are good ideas, although honestly I have only haphazardly incorporated these techniques.
A major thing I haven't really figured out is maintaining / reviewing. I can personally attest to the fact that it is literally possible to be an expert in a subject one day, and less than a year later struggle to remember elementary knowledge that every beginning student learns. Maybe there is no perfect solution to this problem, but maybe it's possible to come up with some review schedule that helps more than "every now and then I randomly go back and look at a book I once read."
(Actually, it doesn't even need to be a switch statement... Just a succession of `if`s works fine.)
Then again, now I wonder if statically typed languages could get the benefits Hickey talks about just by having convenient Map and Keyword types like in Clojure and using them where appropriate.
Really? There is a possibility that this is my lack of industry experience talking, but I find the idea that a company looks at high school grades very difficult to believe. As for middle school... I would seriously wonder about the basic competence (and sanity) of someone who asked me about middle school grades.
(Really, I'm wondering: did you just overlook them or is there a reason they are not competitive with the other platforms?)
(I personally would also disagree with your second point, but that is more a matter of opinion.)