jliszka
jliszka on Hacker News
Stay tuned! We're working on improving phrase matching as we speak.
As for the Control-F thing... stay tuned on that too :)
Yep. We normalize our features as part of training, and the stdevs of each feature are part of the resulting model, along with the weights. (The means are always 0 because of the way we construct our training set.) The weights we use in production are actually normalized_weight / stdev.
Posted by
jliszka on Wednesday May 11, 2016 @12:28PM
from the jliszka.github.io dept.
Posted by
jliszka on Tuesday April 05, 2016 @09:06AM
from the jliszka.github.io dept.
Posted by
jliszka on Monday March 16, 2015 @10:34AM
from the github.com dept.
Posted by
jliszka on Tuesday June 03, 2014 @10:14AM
from the jliszka.github.io dept.
Posted by
jliszka on Wednesday December 18, 2013 @01:09PM
from the jliszka.github.io dept.
Posted by
jliszka on Thursday November 14, 2013 @01:38PM
from the jliszka.github.io dept.
That would be ideal, but a lot of people are uncomfortable doing that, and you would not get critical feedback as often or as reliably.
Posted by
jliszka on Thursday November 07, 2013 @01:05PM
from the jliszka.github.io dept.
Posted by
jliszka on Thursday October 31, 2013 @12:37PM
from the jliszka.github.io dept.
You're right, it is begging the question, for any simple function, you basically have to tell it what all the derivatives are for it to work.
The power of this technique is that it handles the product rule and chain rule for you, so composition and multiplication of functions work automatically without extra work.
For the case of 1/(1-x), you only need to tell it the derivatives (wrt x) of
f(x, a) = x * a
g(x, a) = x + a
h(x) = 1/x
Then it automatically knows how to compute the derivatives of h(g(f(x, -1), 1)).
You're right, there's only O(n) information in these particular n x n matrices, so you can multiply them in O(n^2).
The code provided memoizes cell values using the key (r - c), so only O(n^2) work is required to read off the top row of the matrix. I'm planning to make that more explicit in a follow-up post.
Posted by
jliszka on Thursday October 24, 2013 @01:28PM
from the jliszka.github.io dept.
Posted by
jliszka on Monday October 21, 2013 @12:55PM
from the jliszka.github.io dept.
Posted by
jliszka on Thursday October 10, 2013 @11:27AM
from the jliszka.github.io dept.
Thanks! What's your research on?
Yeah, I failed there. The whole article started out jokey but I ended up cramming a bunch more "serious" analysis in.
Really appreciate the feedback, comes with the territory :)
I added an update to the article looking at what happens when you vary the average car length (corresponding to the % of trucks on the road), fwiw.
> You can see on the right side how his "cars per second" is _exactly the same_ than on the left side.
Yes, but there are way more cars on the left side. That is the difference. Occupancy (density) determines speed when flow rate is fixed, and that graphic is actually a perfect illustration of this. You can't make the cars on the left travel at 80mph because it would not allow for a safe following distance.
One thing that is the same on both sides is that if you're the nth car back from the merge, it's going to take 2n seconds for you to get to the merge. Yes, the important thing is how many miles you can cover in that time, but this way of thinking places an upper limit on how many miles that can be, based on the occupancy of the road.
Also, pretty sure the advice at the end was tongue-in-cheek ;)
OP here. That's a really good point. I just think the original article overreached in saying that zipper merging is a "simple cure" for traffic jams, without taking into account that the road might at or near capacity (and you hit capacity in a hurry when you lose a lane).
My article doesn't account for variance in flow rates in congested traffic, but variance in car length (% of trucks on the road) might explain it. I'm not convinced that merging behavior is the culprit; the original article only speculates that that's the case. I'm putting forward a reasonable explanation for why that isn't the explanation, and a basis for evaluating whether it might be — in particular, whether a zipper merge results in higher flow rates after the bottleneck.
OP here, excellent point. Since so much is determined by occupancy (cars per km), I think the only way to switch domains is to lower the road's occupancy, which is exactly what you're doing when you leave extra space in front of you. However, I tried to point out that this probably comes at the expense of increased occupancy somewhere else, so you're just moving the jam around.
That was a joke ;) Onramp regulators are the real answer, letting only 1 car merge into traffic at a time at a rate well under 1 every 2 seconds.
Posted by
jliszka on Tuesday October 01, 2013 @11:36AM
from the jliszka.github.io dept.
Posted by
jliszka on Wednesday September 25, 2013 @10:40AM
from the jliszka.github.io dept.
Posted by
jliszka on Tuesday September 10, 2013 @06:17PM
from the jliszka.github.io dept.