Ohh, you mean when the CIA supported a coup d'état in Iran? No, sorry, that was 73 years ago. When the USA supported Iraq in attacking Iran including the use of chemical weapons in an 8 year long war? No, that was only 46 years ago. You mean when the Iranian people protested against their government and replaced the monarchy with a Islamic republic?
33M vertices and 1B edges easily fits into memory, if you use 32 bit integers, it will require about 4 GiB of memory. Out of curiosity I just implemented generating a random graph of that size and calculating one page rank iteration on it in the most naive way (20 lines of C#) and it consumed 8.4 GiB of memory and got one iteration done in 4:20 minutes single threaded.
Instead of the CDF I like to use one minus the CDF, the fraction of requests not yet completed at any given time. Then you can make it a log log plot showing the entire tail with details invisible in the CDF because in the CDF the tail is essentially a horizontal line at one.
Interesting that the amount of code remained essentially unchanged. In my experience it is not unusual that refactoring messy code cuts the number of lines in half.
I did not mean it as a metric but as an indicator what was wrong with the code.
- the code is essentially good but all is in one file, you split it up, lines of code stay the same
- the code is essentially good but lacks some structure, for a function that does five things directly, you extract the functionality into five functions and call them from the original function, lines of code goes very slightly up
But once the code is actually bad - code duplication, bad abstractions, inefficient language use, ... - I would generally expect the lines of code to significantly drop. What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code? It is certainly possible but at moment I am having a hard time comming up with a good example.
> What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code?
IMX: the scenarios where people hold higher standards than what you describe :) (i.e. such that "the function does five things" is deemed "actually bad". Of course, that does depend on the refactoring not causing an unacceptable performance hit, which can happen depending on the environment.)
Don't get me wrong, a function doing five things is bad. I consider code not good if you write if(condition) instead of if (condition) or a +b instead of a + b. Not that it is really bad on its own, but it indicates to me that the code was written with little care and I should probably expect bigger issues.
What I really want to get at is the distinction between leaving the actual code untouched and just moving it a bit around - to other functions, other classes, other files - and having to change the code - from deduplicating to completely rewritting it.
I don’t know. LOC to me is indispensable for certain refactoring goals in my opinion.
Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future.
Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this function needs to be refactored into something more robust.
But lines of code is a pretty decent metric of success for “trimming down and cleaning up” style refactoring, to me at least. It’s not everything of course, but it’s definitely an indicator.
A couple of days ago I split a single class which did 5 barely-connected things, where each of the 5 entry points had another 5-10 private helper methods (none of which were shared between entry points), into 5 separate classes which each do one thing - total number of lines went up (because they all have the same boilerplate import statements at the top), but being able to focus on one entry point and it's helpers at a time has made things much easier to work with
LOC can be one measure, but not always the sole or best ones.
Since LLMs are word generators, and have a propensity to generating words, they need to be shaped to understand simplest is best, more isn't more, and less isn't more always.
Trimming down and cleaning up could be formatting, standardization, commenting, or even some basic re-architecting that was overdue.
One of the biggest benefits of llms for refactoring I'm finding is reducing technical debt.
That's LOC in a single file, that's a bit different from total LOC as a metric.
Total LOC is a garbage metric. Things like reducing line count in specific files or components is a big benefit, but those lines are often moved, not dropped.
Yeah, I sorta expected the punchline to be "this 17,000 lines of code became 2,000" but it is still about the same quantity. Kinda interesting. Also interesting that the last change has by far the largest effect (4x reduction in tokens) and that also corresponded to the biggest reduction in single file LOC
Yep, this was a real surprise to me, too. That’s why I included that top line in the figure. It also doesn’t line up with the agent’s predictions when it laid out the refactoring before proceeding.
There’s further work to do to understand exactly what’s going on here.
- allow drawing wires backwards from sink to source
- allow connecting inputs
Also there is a problem with the tests and the simulator that showed up in the SR latch level. Despite having the correct circuit, the tests failed until I swapped the two NOR gates. I can not reproduce it, but I would guess it has something to do with the component placement order, the update order of the simulator, and how the tests are executed. As the NOR feedback loop has no well-defined initial state, it probably settled in a placement order dependent way that made the tests fail. Maybe Q was already 1 and the test looks for a 0 to 1 transition when enabling S?
This reminds me somewhat of OLE, COM, DCOM, ActiveX, ... [1]. You can paste an Excel chart into a Word document and if you update the data in Excel, the chart in Word will update. You can edit the chart in Word using the Excel UI because you are essentially running an Excel instance inside of Word. You can interact with Excel through an API, no need for a human. But it is painful, you can probably imagine the kind of API you need in order to be able to do all the things you can do with the Excel UI.
The idea is amazing, making this work consistently requires effort, and a lot of it. And as only a few applications invested this effort, it only works with a few applications and never really took off outside of Microsoft. I think this used to work with WordPad and maybe even Notepad but it no longer does, you just get an image instead of the chart object in WordPad and nothing at all in Notepad. It is a dying technology.
I had a similar wincing reaction to the expressed idea of wanting to converge output, control, and interaction under a terminal muxer in today's wacky world.
But that's because today's world is forcing us towards overwhelming risk management and compliance systems like NIST 800-53 and friends. If anything, these mechanisms are being drawn, quartered, and spread to the opposite corners of the Earth.
Control via configuration management systems with configuration drift detection etc. Outputs and diagnostics via monitoring, logging, audit, and accountability systems. Authorization systems with extreme least privilege, draconian rules for privileged role assumption. Interaction removed from the entire operations plane, so it only exists in some application domain concepts as a sort of ship in a bottle, which eventually perversely recurses into the same mindset for domains with interesting content and user roles.
Lots of access path restrictions intentionally limiting which usage scenario is available in which combination to which user type from which locale with which client device.
So the idea of flexible and convenient fusion of many different IO and control paths into a portable and remotely attachable terminal UX seems like the complete antithesis..?
They can at least deliver baseline value, because it's all text-based. Do agree that it'll become more complex, when/if they decide to create custom protocols.
Not the author, but this prevents leaking all URLs you are visiting to agolia. Instead of asking Was this URL submitted to Hacker News? you ask Which URLs have been submitted to Hecker News?, store that in a Bloom filter, and then use the Bloom filter to answer the question Was this URL [likely] submitted to Hacker News?
Is the story being submitted a common feature like dupe detection or maybe unsubmitted link detection?
How does the filter know anyways?
If it is provided by the package, one could imagine adversarial scenarios where "high interest" submissions are excluded from the filter(maybe even make a custom one each time that somehow lands them in a collision) so Algolia knows exactly what it wants to know about you.
Probably, I should have read more into both of the projects before asking.
There are 120 monomials of degree at most 7 in three variables. If we restrict the coefficients to the integers from -10 to +10, that makes 21^120 possible polynomials. And we need three of them, that makes 10^476. And we would still miss the specific counterexample because it includes a coefficient of 12 outside of our range. So I would say that you will never find this specific counterexample by chance and whether you could accidentally trip over any counterexample really depends on their density. And we have of course not addressed the question why you would search this specific region of the parameter space, why dimension 3, degree 7 and small integer coefficients? There might be good mathematical reason to look at this region, but it is probably non-trivial to even figure out where to look.
You do exactly the same in a monolith, functionality is broken into modules with a public API and you can switch out the implementation at any time if you want or have to.
reply