skysight-inc/HackerNews huggingface dataset:
Yep. There is a difference between a stereotype and a generalization. Stereotypes are often bound to a kernel of truth, but the problem is that the scale is exaggerated so greatly, taken seriously, and held for so long that it begins to distort the worldview of the person who holds a stereotype. What's the old saying: "In the province of the mind ideas are either true or become true".

The article has a valid point, and yes, it is sensible to talk about stereotypes in the wake of an election and how it can unhelpfully distort the way you think about people.

However, it is always relevant, it isn't destroying US politics (whatever that means); stereotypes are cartoonist approximations and are sort of an easy trap to fall into, and their scope is as broad as civilization.
"Falling into the nucleus", as stated in that Stack Exchange question, is a classical (as in "wrong" :) ) way to look at it.

The 1s orbital of the electron is spherically symmetric, with non-zero probability of the electron being right in the center of the atom (so within the nucleus), and decreasing probability of it being farther away. So e.g. a good approximation of the He atom is of two neutrons, two protons, and two electrons, all in exactly the same position (with the electrons having "more spread").

At the end of the day, there are interactions that are seen in Nature and interactions that aren't. We codify the patterns as conservation of lepton number, baryon number, etc. If the numbers of what you have add up to zero, they can annihilate.

These conservation laws also accommodate other weird things, like beta decay, in which a neutron decays ("splitting") into a proton, an electron, and an anti-neutrino. It's not that the neutron is "composed" of those three things. But its total energy is higher than the sum of the energy at rest of those three particles: Whenever that's the case and the conservation laws allow it, we see it happen naturally.
> At least anecdotally, here in SF Lyft is almost always more expensive than Uber.

Really? I took three trips this weekend, price checked both apps, and Lyft was consistently cheaper. There is definitely a price war going on.
Another point grandparent is missing: when macros of this type introduce the well-known symbols into a scope, those macros themselves are not "surprised" when user code shadows those same symbols. That is to say, those macros usually provide the symbols to the user code, but do not themselves rely on those bindings (while that is possible, it would be a correctable mistake in the implementation).
They likely are banking on the network effect of having the most drivers and users. Having a lot of drivers makes pickup times for riders shorter. Having a lot of user makes it easier to pool people together and give lower prices. Plus more users means the drivers spend less time waiting around to get a pickup. Any new startup needs to (1) get people to download their app and (2) build up enough drivers/users to get pickup times down.
The things that have always tripped me up for Erlang are capitalized variables, lowercase modules, and bare word atoms. There certainly isn't anything wrong with those choices, but it is counter to everything I'm used to from other languages that it presents some cognitive overhead.

In the end, even as somebody who cares about the look of code a lot, it doesn't matter to me. The BEAM and OTP are elegant enough to compensate for any syntax.
I've noticed the same in LA.
Thank you. I tried to stay as much with the 'grammar' of C but with the syntax of s-expressions. Whatever came out most naturally as a C programmer was what I used in the S-Expr language.
> Flour, rice, noodles only go bad if you get moths.

They can develop mold, which sometimes is not noticeable, but will attract booklice. I have had that happen to a bag of rice. There are also rice weevils.
When you suspect there's going to be an issue with timeliness, just call both an Uber and a Lyft, and whichever one gets there first wins. ;)

The cancellation fee only kicks in after 5 minutes.
No, you're right, there's no "law" molecule in nature.

What gives the state its authority is that me and three hundred million other people continue to give the state its authority. Break a severe enough law and we'll take away your freedom of movement for a while.

Behold, society!
And as a leftist, Hacker News is very, very libertarian-leaning most of the time by nature of its general support for startup companies no matter what laws they break and its general dislike of laws and systems designed to protect people from the sociopathic entities we call companies. There's some dissent, but it's certainly not a progressive haven.

This is one of those places where people will happily sit around and argue that breaking laws is moral and necessary, no matter what the law.
Even using Siri, which everyone can agree is terrible, having her set a timer using voice is much, much faster than picking up your phone, unlocking it, navigating to the Clock app, switching to the right tab of the app, then setting a timer.

"Hey Siri, set a timer for fifteen minutes". Done.
I just bit the bullet and installed Lyft on my phone. Then I tried to complete the account creation flow, and the app insisted my (Republic Wireless) phone number is invalid. I lose, Lyft loses... While this is admittedly anecdotal, it does not bode well for Lyft's expansion.
It's funny - we've been remodeling our house, and as part of it, added a bunch of z-wave compatible switches. I was moving some stuff back in (we've been out of it), walked into the house at night, and after living with an Echo and a Google Home for the last year and a half, had a very strong urge to say "Hey, Google, turn on all the lights." -- unfortunately, I hadn't moved the Home in yet! :) I was carrying a large box and it would have been fantastic.

My experience with both devices is that there's no one Big Thing, except maybe music. There's a lot of stuff that just works surprisingly well by voice. Quoting my daughter: "Hey, Google, play Puff the Magic Dragon" - "What's the weather today?" - "Turn on/off the lights" - "Set a timer for 5 minutes" - "What's 17 tablespoons in cups?" - "How long does it take light to get to Mars?"

It's probably not smartphone big. But I think that in the long term, we're going to find that some kind of voice-based interactive device like this will become very common.
I've found it more common at interstate gas stations than at local gas stations. E.g. the one that always does it for me is Hooksett, NH; with a Tesla Supercharger, it is more a place that serves everyone and their mother than a lower income area.
Here's what I'm not understanding about Uber. There' nothing they provide that couldn't be cloned. It's clear there's no way to grow into profitability so once the VC subsidies go away Uber will have to significantly raise prices to survive, putting them in the same price range as traditional car services. At that point, what's to stop Yellow Cab from creating their own Uber clone and eating Uber's lunch?
Uber will be a dead Unicorn in the medium future. They've got too many legal pressures, competitors with native advantages (i.e. the automakers), and their expansion plans have them overextended. Here in Edmonton, AB, Canada, regulatory changes have pushed the Uber prices to almost 2x during non-surge times over regular taxis. Taxi's have stepped up. Local competitors have sprouted. Carshares are abounding. It's all too much for them to compete effectively and the drivers are realizing they are making nothing. The driver pool has significantly dwindled here. The Uber model has no barrier to entry and they've lost their first-to-market advantage. Doesn't paint a pretty picture.
> If every major language provides an O(n log n) sort function, is it still a leaky abstraction? I'd say no.

Great example :) You get different results if you use merge sort or quicksort.

The former is stable; the latter is not.

Okay...so you can be more specific with your API and specify whether stability is guaranteed. Eventually you can be specific enough that you essentially characterize the implementation.
Only if that's the only idea you ever have.
*piqued (not complaining, just thought you should know).
> That said Null is still a valid response. [...] I'd expect to return Null or Default if available for an unset property. There are many cases for null but that doesn't mean that it isn't abused.

We use a `Maybe<X>` return type that can handle returning a value (including `null`), an absence of value, or an exception. It extends `Optional<X>` and adds a new `isPresent()` method, and wraps the exception in such a way that the result `isAbsent()` and calling `get()` will rethrow the exception. Very useful...
I didn't see any comment about Uber's main advantage tho, which is a shame...

1. being able to scale supply to meet demand.

In the traditional taxi model, the number of taxis and drivers are mostly fixed. during times of low demand more fixed costs brings more waste (cars driving around not making money) and in times of high demand represent lost profit (cars not capturing market potential).

taxi company's can try and scale 'fixed costs' better, but then they basically just become uber. Having drivers use their daily driving cars as taxi cars allows scaling of supply much much easier than having to use purpose built taxi cars.
An authorization hold should happen for all rides, but it's normally not very large. The whole point of it is so you can't get a ride and then have their charge fail because you don't actually have any money. Any company that provides a service before payment can be expected to do the same thing (e.g. basically any company that's part of the gig economy). The perfect authorization hold is one that's for the exact amount you'll be paying later, but in most cases that amount can't be predicted, so companies try to slightly overshoot (because they can always charge less than the hold, but if they try and charge more it will fail if you don't have any more money).

If you got a $25 authorization hold from Lyft there's a couple possibilities that come to mind. The first is that Lyft thought your ride would in fact come somewhere close to $25 (after tip). The second is that if you're a new customer, they likely consider you a much higher risk of fraud, and therefore want to err generously on the side of overshooting the estimate, instead of trying to place a lower hold and risk not being able to capture the real cost of the ride. Also, if you hailed your ride without providing a destination, they wouldn't have been able to produce a usable estimate.
I was thinking more along the lines of someone that notices something like "alcohol on breath", a person that acts as a customer's ally/mediator for corporate in cases of transgressions, an accountability person with little purpose than for corroborating corporate's opinions on "bad apples" (whether rightly or wrongfully) etc.
That looks really interesting, do you have any experience working with it that you can share?
Nice, I implemented something very similar, except in my game not every controllable entity a) implements every control, and b) implements controls the same way, so I store what a control would do as a member function of each object and store an array with the names of these functions in each object. The indices of the array with the names of the functions match the indices of an array that stores the key codes I listen for, from there I match the indices, grab the name of the function and call it from the object being controlled.
You are assuming perfectly rational market. It isn't.

Many people here would dodge Uber if they expect surge pricing (And something along these lines was said today on one of the popular for young people radios stations, here).

Also, there are plenty of taxi just waiting around everywhere downtown.

Many (older?) people, would never get Uber to go to the airport, which is a very good profit opportunity.

So, I don't see Uber having a 100% monopoly in any future, as various people have various needs and opinions and it's not a race to the bottom on price in this segment.

They will both coexist, but for people taking the cab in the first place, $0.75 is not even on the list of thoughts in downtown Toronto. You get out of a Johny Cash event, $200 a person ticket, it's snowy, and you'll wait few minutes for uber when the Taxis are parked up front?

As you move outwards from the core, more people drive Uber, and one was even my ex coworker, so he told lots of stories.

So, to conclude, you can't assume race to the bottom on price alone. Or IPhones, rolexes, Alienware PCs, etc would have been long gone.
Just released the first of many code examples to automatically verify that our web-site displays the same complete data as within the Bitcoin Blockchain (this can be done manually very easily also without any technical knowledge using our site). The first example is one in PHP using simple_html_dom.php - https://lockedpost.com/validate/PHP-Validation-Code/ any code improvements are very welcome.
autonomous driving could potentially cut one of the main expenses (like the driver's fee), which could cut down prices even more, and probably get them enough of a margin to make them profitable.

that's probably why it makes sense to dominate the market while they still can.
Yeah it's usually clear what they mean with "into the green" but a thread about electric vehicles definitely makes that confusing.
That's why I don't understand why IBM would give a shit about some thing specifically not designed for non-apple OSes
Indeed, that doesn't make sense. You're witnessing probable criminal activity, and aiding it by providing the ride which could make you an accomplice once you were aware of the activity.

What law could possibly prohibit you from reporting this or leaving the passenger behind?

EDIT: Looking it up I'm not finding anything except stories of Uber drivers kicking people out mid-ride. Perhaps a particular municipality has a more specific regulation? There are lots of reasons to kick passengers out, and criminal activity is #1 (perhaps tied with "they're about to puke/piss in my car because they're so wasted").
I'm pretty sure OpenBCI has an EMG board, called MyoWave.
That's a good question. I've built systems that boot into a command prompt, and booting into emacs wouldn't be too big a step away from that. But what always seems to happen is that after a while the nostalgia wears off and I remember why I like my Jupyter.

I guess it's the REPL-on-steroids nature of Jupyter that I like. Also, having inline matplotlib graphs is pretty killer.
I presume on your phone? I set echo timers/alarms nearly every day and don't think I have ever had to repeat myself. The far-field mics make a huge difference in recognition accuracy when you aren't talking directly into the device.
Uber (combined with Lyft) spent $10,000,000 to lie to the people of Austin about the effects of Prop 1. At a conservative cost of $50 per finger-printing, that's enough to fingerprint 200,000 drivers.

I know because I received over 30 pieces of direct mail in the two weeks leading up to the vote from whatever clown-show operation they hired. Twelve of the direct mail pieces were the same mailer.

Given the waste of paper and their previous history (especially the behavior of the executives), I don't care if Uber ever "comes back."
A keypress should never do much other than to update some game state to say that whatever key was pressed and it is mapped to whatever game concept in your input mapping. Nearly any code I've ever seen with an if/keypress, do this is an anti-pattern. Once you have your state, you just need to handle it somewhere later during a game tick, and keep in mind that might be even multiple places.

I would recommend thinking in loops, so it sounds you're already on the right track, you just need to expand that more to everything else. You generally want to do the same "thing" to many "things." Since you are newer to programming engines, I won't get too technical and I'll say that the gist is that the CPU likes this. The bi-product is if you take this approach, you'll tend to have better architecture as well as performance and solve some of the problems you listed. This is really the basis of an entity system approach if you want an example architecture.

Whether using entity systems or something else, my recommendation would be to separate out functionality and make them rather agnostic to each other. Again, this fits in with the loops paradigm. You still often need things to communicate as your problem suggests, but the way to do that is to often take some state, update it with new state, and pass it down the chain to see if anyone cares. That chain itself can be a loop, i.e. a bunch of systems in your game loop calling a method like update(tick, state, ... ). That said, you also need to be careful what and how much state gets passed around for performance reasons (ex: avoid excessive copying) and to prevent weird things from happening if you start introducing concurrent and/or parallel programming. To that end, I tend to keep things minimal as I can, or at least have some sort of way to hand things just what they need, not everything.

Queues also relate to all of this and can be your friend. A common communication approach is to use mailboxes for example and tends to be more straight forward to debug and optimize than using callbacks and event-based approaches (they tend to murder the cache and your stack traces). Queues also play nicer for being building blocks for concurrent programming.

Also keep in mind you may need to flip your thinking. Sometimes you don't actually need some action that happens during a tick to be processed the same tick. You can often or will often want to defer things to the next tick, or even several ticks after that. There's a Naughty Dog presentation on Last of Us port to PS4 that relates to this and how they flipped even the way frames are processed on an existing codebase to get better performance. The point is not for you to do what they did, rather to start thinking in terms of what the user will see as the end result. The user often doesn't care that you didn't finish processing some action last tick if it had no bearing on the gameplay.
> finding out they were working with numpy makes it even more so (since numpy takes the pain out of the matrix operations)

hmm, I did the cs231n homework and had the opposite experience. It was really easy to complete it by ignoring numpy's provided matrix methods (just write a bunch of for loops in python) but that solution was really slow. If you could use numpy's matrix methods, however, the code executed a lot faster (the loops and control flow now run in C instead of python, so to speak). The hard part of the assignments was expressing my python code, with all its ad-hoc mixture of nested loops and conditionals, in numpy.
They still have the momentum.

This isn't a start up trying to figure out how to make money (Twitter) or a company that can't/won't change (Blackberry).

This is a company making money that is pursuing a blitzkrieg on the industry. They can sit back any day and rake in billions. I agree there isn't a high entry barrier, but I don't think they've lost the first-to-market advantage.
Well, Yellow Cab could hardly even get credit payments to work in their cabs, so they are not exactly a technology company. It's not going to be easy for a cab company to clone what Uber (or lyft) have built during the last 7 years. Plus Uber has a network of drivers/users that has significant value.
What exactly is the Juno model? Just a clone of early Uber?
Don't get me wrong - I may not fully comprehend the math behind what is going on (as I noted, I have little understanding of calculus, and it is one of my failings that I am working to improve on) - but I do understand the need for the abstraction; I understand that it allows us to model the activation function and workings of a neuron, to a certain level of accuracy. I understand that it may -not- be the same way that a real neuron does it, but that it is close enough and works well enough to be useful.

At the same time, I wonder if there isn't a simpler way of doing all of this - if there isn't a simpler model for the abstraction of a neuron that doesn't require back-propagation or calculus? In other words, have we become so use to the current concepts and models of ANNs that we have become hesitant or resistant to imagining other possibilities?

Yes - what we have works, and it works well. Honestly, from what I know, and what I have learned (while I may not fully grasp the mathematical and calculus underpinnings of a neural network, I do have a good feel for how both forward and back-prop is implemented), our current general knowledge on ANNs (ie "how to implement a simple neural network") isn't super-complex. I only question whether it could be made simpler (and I'm not talking about a network of perceptrons or RELUs), or if, because of the early work (Pitts and McCulloch mainly), we are going down a less-than-optimum path (to use an ML analogy, we are stuck in a local minima) - one that fortunately works, but maybe there's something better out there?

Again - I recognize as a non-expert in this field (I only consider myself a student and hobbyist so far) - I am likely very well off in la-la land. Even so, we know that quite often in engineering, the optimum solution tends to be the simplest solution; sometimes, that solution is simpler than nature (an airplane vs a bird, for instance). I have a feeling that may be the case with ANNs as well.

I am not wedded to this idea, though - I just want to put it out there for consideration and maybe discussion. As I noted, what we currently have works well, and isn't a complexity nightmare, and is understandable to anyone willing to understand it. It very well could be it -is- the simplest explanation.
I disagree. To paraphrase the intro to my Linear Systems book "math is a contact sport." This applies to most intricate topics. If an expert takes you through a one hour tour of a subject, you will get the salient points, but there's a lot of intuition and that gets lost by you not struggling with the material on your own. That's why we have homework.
Galvanism and the Telegraph
as a google employee, this often makes me sad too, but when it comes to human life, it's a bit more nuanced than that.

engineers don't have the luxury to do many things they could otherwise do on their server side software. You break a server, you fire-drill it, get the resources, roll back the release or so on. You lose money, sometimes tens of millions of dollars, but not human life. You write your post mortem, and put the protections in place, you learn from it.

Noone can afford to lose a life.
I love text games. Looking forward to taustation which is going into alpha soon and written by a prolific perl author. Good stuff. Check out the blog articles.