I made a comment earlier that was rightly flagged for its tone, and I would like to restate the technical point more constructively.
The post author, Dan Piponi, clearly knows about fractals, but his post raises the question of whether asking Fermi questions in interviews is actually effective. I am skeptical that such questions would have prevented this type of bug.
I suspect the issue stems from small measurement imprecisions accruing over long distances, which is—in my view—tied to the fractal nature of roads traversing natural landscapes.
However, as others have pointed out, it may also be tied to road closures: if closed segments are set to a higher length internally (to discourage routing), these values might be getting summed up blindly over longer distances.
None of these issues would have been prevented by being good at estimating quantities alone.
Apologies again for the unconstructive tone of my previous comment.
Here's a Fermi-ish question: given the fractal nature of typical landscape, should a truck driver budget for 10 times as much time as would be predicted by using the known typical speed of the truck and the distance as the crow flies?
(Aside: the nearest grocery store to my house is 1 mile away but the shortest route by car, as measured by the car odometer, is 10 miles.)
A pure spirit is required to admit your own mistake. Don’t be let down by an error, never lose the opportunity to fix it. May this be of example to everyone to keep improving this already wonderful but not perfect community.
This video is truly remarkable. I'm so grateful to artists like 2step for sharing this kind of work on YouTube. It reignites a passion for math that many of us might have forgotten, especially those of us who have been away from formal math education for a while.
It's understandable to hold different perspectives on the video. However, simply dismissing it as "AI" without any supporting evidence or referring to the audio as "noise" is unproductive and doesn't foster a constructive discussion.
It isn't the same principle. Firstly, coastlines are more jagged because they are hit by waves perpendicularly, while rivers are shaped by water flowing along the banks, smoothing them. Secondly, the borders are typically defined by either the thalweg (greatest depth) or median line, either being smoother lines than the banks. Thirdly, river borders are then in practice defined by measuring the coordinates of particular sample points along the idealized line and then using straight lines or simple mathematical curves to connect these, forming a simple non-fractal boundary.
Exactly. The coastline paradox is a mathematical curiousity, not a practical objection to measuring things. Coastlines are not infinite length in practice. You define a system of measurement then a length in that system
It also makes sense to pick a resolution because coastline changes on an hourly basis (and minute-basis, for rivers during rainfall), so that these differences would not massively affect the measurement every single second
Why should a platform allow sharing ways of violating its terms of service? Sure, any tech savvy person will be able to figure it out, but business are businesses.
Should supermarkets allow you to ressel coupons in their premises for a profit? Because he's 1. monetizing the video, 2. being sponsored by a third party in the video and 3. showing ways of circumventing the platform TOS.
He could remove that frame where he shows the yt plugin, but he's using this to farm engagement.
> On top of that, there is no easy way to create a template
Templates are just functions [0].
I think much of the frustration comes from typesetting being a harder problem than it seems at first. In general a typesetting system tries to abstract away how layout is recomputed depending on content.
Supporting contextual content -- cases where the content depend on other content, e.g. numbered lists, numbered figures, references, etc -- involves iterative rendering. This is evidentidly a complexity sinkhole and having a turing complete script language will bite you back when dealing with it. I recommend reding their documentation about it [1] where they explain how they propose solving this problem.
I can't agree more. Linus position here is not dissimilar to CEOs and alike. He's trying to deal with R4L using his (allegedly) 100% technical and 0% political perspective but in this case it simply doesn't work. R4L is a political challange that require political discussions; who decides? what's the bar? who maintains what? etc
By not answering this questions and saying he doesn't want to have anything to do with the arguments, Linus simply decided that he doesn't want to solve the problem that only him can solve. The result is clear: R4L will fail if Linus decides that any maintainer can stop the "cancer" to spread and block Rust changes.
R4L implies that Rust will be present in the kernel and will need to be maintained. If Linus is ok with maintainers that have a deep/fundamental problem maintaining/coordinating the maintenance of Rust code, R4L will never happen.
Really solid program. I bought a license years ago because it is the only software that correctly remuxes media for direct play in Chromecast, including surround sound and HDR.
I wish Jellyfin could catch-up with the compatibility level AirFlow has to offer.
Jellyfin has slowly been getting better. Client also makes a big difference. I fought issues with Roku advertising capabilities properly before eventually hitting limits (100Mbps Ethernet) and moving to Nvidia Shield which has been working better (but still had an issue with HDR)
The post author, Dan Piponi, clearly knows about fractals, but his post raises the question of whether asking Fermi questions in interviews is actually effective. I am skeptical that such questions would have prevented this type of bug.
I suspect the issue stems from small measurement imprecisions accruing over long distances, which is—in my view—tied to the fractal nature of roads traversing natural landscapes.
However, as others have pointed out, it may also be tied to road closures: if closed segments are set to a higher length internally (to discourage routing), these values might be getting summed up blindly over longer distances.
None of these issues would have been prevented by being good at estimating quantities alone.
Apologies again for the unconstructive tone of my previous comment.