space filling curves can also be used under the hood in data structures that support efficient spatial queries: https://en.wikipedia.org/wiki/Hilbert_R-tree
5,852 karma · joined January 22, 2011
I'm guessing this application would be selecting an ordering to engage multiple simultaneous targets in minimal-ish time - MIRV warheads or missiles launched in a barrage.
E.g. if your job is writing game engines or middleware used by AAA games with fancy graphics to run on consumer hardware, getting the most efficient use out of the players' limited memory bandwidth may be very important.
For many (most?) arbitrary commercial software projects in other contexts, performance isn't high priority & memory bandwidth isn't a bottleneck. Performance just has to be 'good enough' & 'good enough' performance may be easily attained by writing typical OO code that uses cache & memory very inefficiently - so in those cases DoD is an engineering trade off that solves a problem that doesn't need to be solved & may create new problems if introduced.
Maybe a bit of a tangent to your point:
one major difference that jumped out at me about Alexander's work vs the software engineering 'patterns' is how much emphasis Alexander places on involving the people who will live & work in the buildings in the design process. Some of this involved including the building's eventual inhabitants during rapid prototyping -- it's really cheap to experiment with different building outlines when it's just folks standing around in an empty plot of land prototyping the outlines with pegs & string.
I first read about Alexander's work in the book _Peopleware_, they described this aspect of it as "local control of design by those who will occupy the space". A space that can be customised to the needs of those who use it.
That's something completely absent in the software engineering 'pattern language' stuff, which tends to feel more like ivory tower big design up front by the architect / throw it over the fence to the users.
Now, how do things change if you sell a software product instead of a service? & how do things change if you give that software product away for free, instead of selling it? There's still a chance that some user of your free open source software product suffers real harm because of it. Particularly if they're using your free software in a commercial context with a lot of scale, perhaps they've suffered millions of dollars of losses because your free software product was defective. Are you liable to compensate them for their damages? Maybe!
Superficially it sounds a little crazy, but it's probably a lot less crazy than far more mainstream antipatterns (e.g. 'lets have our CI download all the dependencies from npm over the internet each time the build runs')!
Did running the unit tests on IA-64 ever flush out genuine issues that were 'working by accident' on x86?
e.g. if you're playing a single player turn-based strategy game, you might be taking a few seconds between each decision & UI interaction. Some hard turns you might step away from the computer to think things through for minutes without touching the controls. 30fps for a game like that could be fine. 15-20fps might even be fine, especially if the game engine manages to avoid adding unnecessary input latency & is able to process input events at a faster rate even if the render runs at a low framerate.
If you're playing competitive FPS games, where reflexes matter, you'd want to get input, network & video latency as low as possible, within reason. Not high-frequency trading low. I have no idea at what point it stops making a competitive difference. If you have +100ms more latency than I do, I suspect that'd give me a noticeable advantage. If you have +10ms more latency than I do, I'm not sure that matters.
Dan Luu wrote an article about input latency [1] in 2017 where he measured latency by running experiments pressing a key & measuring how long it takes to see a response on the screen. New computers from 2017 would have around 70ms-170ms latency, depending on the model.
your usage patterns may have been similar to usage patterns of other customers that are often problematic, so some automated anti-abuse system made some statistical decision & banned you. you're a false positive, it's not worth their time reviewing the decision as most people they ban are problematic customers, and they've estimated that you're probably problematic.
Perhaps the cost of providing a 20x subscription exceeds the monthly subscription revenue, if a customer uses it heavily. Perhaps most heavy users only have a single subscription, and they can account for running at a small loss as a marketing expense & hoping you may convert to a profitable tier in future. But if you have 13 subscriptions of their 20x consumer plan at once, maybe they lose so much money from it that they decide it's not worth continuing to doing business with you -- purely commercially -- so at their discretion they ban you.
In both cases, they've decided it isn't worth doing business with you, for different reasons, so if they estimate that a new customer signing up is in fact you, the same person they previously decided to ban, they'll keep banning your attempts to open new accounts. They're not going to explain how they figure out you're the same person as that undermines the effectiveness of their banning process.
If you were banned purely because you're costing them too much money vs what you are paying, in theory that's fixable if you are willing to pay enough money to sign up for a proper business plan & can find some salesperson to negotiate with. but in practice presumably they have all their salesfolk pointed at enterprise customers because that is where the real money is.
Misc thoughts:
- I'm not familiar with the LABS problem, but the LABS benchmark page is interesting & compares against Gurobi. I'd be curious to see how an existing commercial non-mip approximate solver such as Hexaly (formerly LocalSolver) compares here.
- the other two benchmarks aren't very convincing as they don't compare against other methods or show running times
- the front page mentions peer reviewed methodology - consider linking to the publications
- good idea to have case studies of applications. I was a bit confused to see this listed under 'References' but on comparison the Gurobi & Hexaly marketing websites also do this (references -> case studies & references -> customer stories, respectively)
- re the client API, you may want to make the server URL have a default, so your trial users / customers don't have to specify it. It may be easier for you to roll out changes to your server URL in future if you can do it by changing the default server URL in a new version of your client library rather than requiring your customers to update their source code.
All the best!
The economics of laying fiber to the premises are heavily driven by density of potential customers * probability that a potential customer will sign up if you run fiber down their street. You can get reasonable intuition by focusing on the density alone & ignoring the competition / pricing side of things.
I'm not familiar with current US construction costs to install fiber but have some intuition from Australia.
With Australia's national broadband network project from a decade or so ago, it'd cost in the ballpark of $100 AUD per meter to run fiber down the street in an underground trench - most of the capex is digging the holes in the ground etc, the cost of the cable itself is essentially free. The construction budget for a suburb would be something like $2000 / premises. To give a ballpark estimate, suppose 25% of your budget is the premises-specific work to connect the house to the cable running down the street, if they choose to sign up for your broadband plan. That leaves at most $1500 / premises for the rest of your capex budget, so the economics only work if you've got a neighbourhood with a density of least one house every 15 meters. Those numbers aren't exact but they'd be in the ballpark.
There's a bit of variability in the cost per meter to install, if you can reuse existing poles & run the cable aerially that might be only 30%-40% of the cost of digging holes, so you might be able to support a lower density suburb that way & still stick to your construction budget.
In Australia for the lower density rural / semi-rural areas they'd use fixed wireless, & finally satellite for the remote extremely low density areas where it didn't even make sense to build a wireless tower.
seems completely reasonable to model this as income.
> health insurance contributions
If your employer provides a health insurance benefit that would otherwise cost you $X / yr, you could model that as +$X / yr income and +$X / yr expenses.
Simple FIRE calculators like that Networthify one assume that your expenses in retirement are the same as when you are working, but that's probably not true for many people, for numerous reasons: health insurance once you're not longer working, paying off a mortgage, children launching into the workforce, increasing health expenses as you age, lifestyle changes when you're not working, potentially moving to a different area with a different cost of living.
But as a 0-th order approximation, assuming expenses in retirement are the same as when you are working is a place to start when assembling a rough plan.
If you're not familiar with savings rate, here's a simple calculator to help build intuition. The assumptions of asset returns & portfolio required to sustain retirement are a bit optimistic, but it's directionally correct: https://networthify.com/calculator/earlyretirement
You need roughly a 15% savings rate to support traditional retirement age. If you're fortunate enough to create & sustain a situation where your income net tax is a lot higher than your annual expenses, the timeline accelerates significantly.
If the client hasn't invested in setting that up, the resulting situation is the clients' responsibility.
E.g. take the same 8-core Ryzen machine they use to implement their simulated Ising Machine HbSB method & use it to run a standard classical solver as would be done industrially to tackle these kinds of problems outside of academia - perhaps an industrial grade commercial MIP solver (Gurobi) for those problem classes that are known to have reasonable MIP formulations, or a good constraint solver for Sudoku, etc.
Depending on how hard the specific test problem instances are, perhaps a commercial MIP solver would be able to solve some of these problems optimally & instantly using its black box of presolve witchcraft tricks.
If there isn't enough guaranteed recurring work, it might not make sense to have a full time position, particularly in a country where its difficult to lay people off & if employees have additional overhead (pensions, employer funded heathcare or insurance, etc) vs contractors.
But, if there's funding allocated for some key project that's framed as a 6-12 month project, there might be a good business case to hire a contractor. Maybe the funding comes out of the project bucket, not the core funding for legacy product X bucket.
If the contractor is someone who was recently let go & has a good reputation within the company as someone who gets stuff done and is easy to work with, it's probably a no-brainer to re-engage them as a contractor vs rolling the dice on an unknown quantity.
Whoever is managing the budget of their old team gets a win as they were able to reduce headcount to fit in their budget
Whoever is managing the new project gets a win as they find a great contractor for their key project
The former employee returning as a contractor probably gets a win, as they get paid at a better daily rate while the project is rolling, provided they're able to line up more projects or land a new permie job once the project is completed.
If there's an outsourcer involved, they win by taking a cut. The former employee might also win by having the outsourcer involved if the company has some baroque process for engaging contractors with many compliance hoops to jump through -- in extreme cases (think banks, or public companies that need to demonstrate they don't do business with suppliers engaged in slavery, or so on) it could save the worker months of paperwork and tens of thousands in legal expenses to set up their own one-person agency and go through the compliance process to be able to work for their former employer, so they might not be able to win the contract work without piggybacking on an outsourcer who already has the contracts & compliance stuff sorted out.
the bank would go through cycles of "we need to reduce our headcount and outsource everything" and then 4 years later "we need to reduce spend on contractors and retain more knowledge and expertise in house". he'd survived multiple waves of it, switching back and forth between being an employee or a contractor through some external agency, as management trends changed, while essentially doing the same job.
A niche example of this kind of thing is when solving commercial/industrial combinatorial optimisation problems. Maybe the goal is to maximise profit or minimise capex subject to a large number of constraints. Sometimes it is intractable to solve the true problem, but there's some approximation of the problem by relaxing one or more constraints that's much easier to solve. In some of these business contexts its completely OK if the optimiser ran overnight before spitting out a solution, provided it found a 5% better one. In that setting it'd be natural to decouple the internal representation(s) of a black box optimiser from the high-level way you represent the true problem & its solutions elsewhere in the system.
Some of these systems might end up feeling a little like a compiler toolchain - high level descriptions of problems & solutions that get transformed into / recovered from lower level implementation-specific representations.
If your context has high performance needs, e.g. needing to solve the problem 30 times per second in a real-time game or control system, or react as quickly as possible in a low-latency trading system, maybe it could be less of a good tradeoff to introduce avoidable copying of data between a strict correct representation & a relaxed representation. Could write the clean thing first & then profile and see if the overhead of copying is relevant. If the representation of your solution is small, there probably isn't that much overhead in copying it, unless your performance needs are extreme or your hardware is severely limited.
What we were looking for
- people unwilling to admit they'd ever made a mistake -- red flag
- people who could reflect on the situation and say what they'd do differently in the future
- ideally, people who could use their mistake / failure / bad situation as an example of how they then took initiative to improve things by doing blah blah blah
People who were able to give an ideal response had clearly practised for this kind of question & knew how to play this part of the interview game.
Behaviours valued by one type of potential employer may not be valued by another. Small businesses & startups might value folks who take initiative and have a bias for action. In contrast, regulated megacorps might value folks who are great at consulting stakeholders and getting buy in before making changes, and steer clear of people they believe will go off and do stuff unilaterally.
One rule of thumb for handling these kinds of behavioural questions is "STAR" -- situation, task, action, result. Use the prompt for the question as a way to pick an example, then figure out how to frame an answer that shows you doing something to improve the situation. There's a fair chance that your interviewers are trying to mash your response into a STAR format in their own notes, even if they don't hint for you to respond in this way.
It reads as if the change was made to some library code that was depended upon by someone else's program that would "yay, done", which was in turn depended on by some workflow.
It's probably a non-starter to change library code so it hard fails if it detects its being used incorrectly, in situations where it previously ran and did something. That's a severe breaking change in behaviour.
Easing it in by printing a warning message sounds like a reasonable step toward hard failing. But then we get the situation yosefk relates.
allowing an AI agent to get hold of creds that let it execute destructive changes against production -- not a great idea
allowing prod database changes from the machine where the AI agent is running at all -- not a great idea
choosing a backup approach that fails completely if there's an accidental volume wipe API call -- not a great idea
choosing to outsource key dependencies to a vendor, where you want a recovery SLA, without negotiating & paying for a recovery SLA -- you get what you get, and you dont get upset
For anyone wanting to get into the weeds about detecting accounting fraud, the book "Financial Shenanigans" has lots of historical examples of ways company executives have cooked the books to make their public company financial statements appear more appealing to investors than they actually are.
Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:
> For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.
It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.
e.g. https://www.minizinc.org/ offers a high level modelling language that can target a few different solver backends
might be pretty good results to completely ignore writing a custom algorithm and drop in an existing industrial-grade constraint programming solver, model your procgen problem using a high level language, and use the existing solver to find you random solutions (or exhaustively enumerate them). then more time to iterate on changing the problem definition to produce more interesting maps rather than getting bogged down writing a solver.