HackerTrans
TopNewTrendsCommentsPastAskShowJobs

dr2chase

no profile record

comments

dr2chase
·8 месяцев назад·discuss
Depends how you define "equal". One approach is simply to scale the charge by income -- effectively, convert time to money, and charge you a congestion tax of some amount of money-earning time. "6 minutes" is 1/10000 of your annual income -- $2 for someone earning $20,000 per year, $20 for someone earning $200,000 per year.

But does a vehicle with several people in it pay for the max, min, median, average, or the driver's time? I suspect "driver" is easiest, it seems like it might work but I'll bet there are some screwy ways to game that rule, too.
dr2chase
·8 месяцев назад·discuss
author here, you are right, I missed that. In my pathetic defense, the normal argument around here (Cambridge, MA) is about literal lane widening and narrowing, and not adding and subtracting.
dr2chase
·8 месяцев назад·discuss
Hi, author of the article. I'm assuming urban traffic speeds, which is what I observe all the time myself, but you can look at the video of those kids, and count, and look at the seconds. 125 bikes in 45 seconds, between 0:02 and 0:47. Understanding it is another issue, but it's a fact. (This is one of those things that I do myself and would not claim that I exactly understand the details, I just do it.)

There have been more academic studies. e.g. https://nacto.org/wp-content/uploads/5_Zhou-Xu-Wang-and-Shen... estimates 2512 bicycles per hour per meter of road width, or 7536 bikes per hour on a 3-meter (10 feet) wide lane. That's only 4.2x car throughput, versus those kids who managed 5.5x.

You are right about the trailers, but at least where I ride, they are not common-case for carrying things, lots more cargo bikes instead, and those are "better" than trailers -- it's possible to ride two cargo bikes side-by-side even in a US protected lane (specifically on Garden Street in Cambridge, MA), though this of course assumes competent riders.
dr2chase
·3 года назад·discuss
The way to view it is "unless there is syntactic sharing, it is a for loop, same as before". The compiler uses a syntactic test (with little knowledge of control flow or value use) to exclude loops from the change. This excludes most loops.

After the change, escape analysis figures out if the changed iteration variable actually needs heap allocation; in an internal sample of code that was actually buggy (i.e., biased, guaranteed to have at least one loop like this) for 5/6 of the loops escape analysis decided that heap allocation wasn't needed.

The reason this optimization isn't part of the language change proposal is that escape analysis is "behind the curtain"; ignoring performance, a program should behave the same with or without it, and it is removing heap allocations all over the place already. Escape analysis is also extremely difficult to explain exactly, so you would not want it in the spec, and "make escape analysis better" (that is, change it) is one of the prominent items in the bag of things to do for Go.