5,849 karma · joined January 22, 2011
No idea. The boring (in a positive sense) answer I'd expect for any backend API server is that encryption in transit is handled by TLS. So I'd expect either the MCP server in question can be configured to support TLS connections & refuse plaintext HTTP connections, or that for a production-like deployment it expects to be deployed behind a reverse proxy that is responsible for terminating TLS.
Market caps are roughly expected future earnings, discounted back to give some net present value. They're expectations about the profitability of businesses, with expected profits accumulated over forecasts decades into the future. Market caps ignore privately held businesses, small businesses, state owned businesses & economic activity, economic output that might be happening at a household level, etc.
GDP is some peculiar measure of a country's economic output, over one year. It doesn't care if the economic activity is profitable or not & it doesn't care if the surplus of the economic activity is extracted by public companies or not. It's not forward-looking & based on expectations.
all that said, ggm has a fair point that individual investors & retirees with share portfolios directly benefit from the profits of companies whose economic activities may not be particularly pro-social & beneficial to the world. it's similar for climate change -- easy to point the finger at the energy producer, the big dirty brown coal plant. harder to point the finger at the demand side of the same equation - much of which is household demand. but both the individual end consumer households and the energy producer & everyone else involved in the value chain benefit out of the trade, even if the trade is net-negative for the world if we were to properly account for the externalities (e.g. polluting the atmosphere with CO_2 pushes the costs to everyone on the planet, current & future generations, not just the folks benefiting from the trade).
On the non fiction side, I'm slowly chipping away at Joe Studwell's book How Asia Works, about East Asian development. In the first section of the book, the author argues that the foundation for successful development was boosting agricultural output -- instead of spending precious foreign currency on food imports, surplus agricultural output can be exported & intensive farming provides a way to soak up and use labour before other industries develop.
Studwell also argues for the importance of land reform in boosting agricultural output -- appropriating land from wealthy landlords & redistributing it to landless peasants & tenants. This happened in both socialist & capitalist societies. There was a huge demand for land reform from landless peasants. I was completely ignorant of this chunk of history & found it fascinating. Agricultural output increases on a per hectare basis when farmers have the incentive to work hard - unlike if they're day labourers or share croppers paying much of their output as rent. Landlords don't have an incentive to increase output as its easier for them to earn money from renting out their land & lending money. Studwell gives examples of small farmer-owned farms being much more productive than colonial plantation style farming. Developmental success stories (Japan, Taiwan, South Korea) were those where governments supported their huge newly created markets of tiny landowner-farmers with subsidised fertiliser inputs, better varieties of crops etc & where peasants & tenants got a seat at the table to influence the land redistribution process. There are also stories of failures where wealthy elites got control of the land reform process & rendered it largely ineffective (the Philippines).
With one of these solver-based approaches, you encode the problem with decision variables in some fashion, state all the constraints & call solve. There's some art & experience in how to encode & model the problem, but the specification of the model & the problem is fairly declarative.
What's great about general purpose solver-based approaches is that its usually faster (in terms of implementation time & effort) to start getting solutions & they're also much more robust to changes in requirements & the problem statement. That's less of a concern in this toy example, where the problem is small, well-defined & unambiguous, but in a real business/industrial application, the problem statement often changes considerably over time.
I agree that the performance & behaviour of a black box solver may be much harder to reason about than something you custom build by hand & know inside out, but if the general purpose black box solver is 'good enough' for the distributions of problem instances it needs to process, then there's no need to custom-build anything. Throw the black box solver at it -- job's done, and you're left with something that's both quite readable (declarative modelling of the problem, particularly if someone documents the formulation - the meaning of all the decision variables, index sets, constraints, objective terms etc) & flexible to future change.
Custom solvers & heuristics can sometimes be much, much more effective in being able to scale and solve industrial-scale problems, but usually at the expense of being much more effort to set up in the first place, and very fragile to changes in requirements -- if you learn something a few weeks into a project that perturbs the problem statement, maybe it wrecks the particular mathematical structure you were relying upon for a custom solver/heuristic, so you need to chuck out all your work & go back to the drawing board.
misc feedback
- dominant strategy seems to be drive to point blank range & fire. needs some playtesting & rework to make it interesting for 2 players.
- how do you bring up help for a reminder of what the controls are once the game is in progress?
- the arrow keys for controlling the turret are unintuitive. i'd expect left & right arrows to change the barrel angle, like in the original scorched earth, but here they change the power level
- the visual trajectory preview doesnt seem useful whenever the moon is involved as by the time you fire, the moon has moved the trajectory is wildly different to whatever the preview showed
But none of this "implementing stuff" is making progress to solving the issue of unclear / changing / vague / missing requirements.
To crudely estimate a fundamental valuation for MongoDB as a discounted sequence of future earnings, we'd need some understanding of the main factors that are driving this change in the net profit margin (over the next 5 years do we expect those factors to persist? to decay? to accelerate?), some modelling assumptions & forecasts for how they'll evolve over the next decade or two, and a discount factor.
Out of curiosity, I bashed together a naive NPV valuation, in complete ignorance of MongoDB's underlying business.
Completely unjustified modelling assumptions: suppose MongoDB can grow revenue at +20% / year for 5 years, then +5% / year for the next 5, then hitting a steady state +2.5% / year revenue growth; MongoDB grows net profit margin by +5% every year until hitting a 25% net profit margin, where it tops out; discount factor of 9.5% (= 5% risk free rate + 4.5% equity risk premium); no change in number of shares outstanding (perhaps optimistic, given they issued a bunch of stock within the last 5 years). Projecting this out 20 years & then using a 20x P/E valuation multiple at year 20 for the terminal value gives us an NPV estimate of the value at about $290 / share.
So if you believe MongoDB's business will do about that well, with your fundamental valuation investor hat on you could consider buying some stock if it were offered at, say, half the current market price or less -- assuming there isn't anything more attractive to invest in.
If you believe MongoDB's revenue growth & improvement in net profit margin will be much stronger over the next decade, maybe you'd be comfortable buying closer to the current market price.
(I don't hold any MongoDB stock & find it hard to stomach investing in growth companies vs companies that are more mature & easier to understand, but I appreciate that to value growth stocks you're not going to have much luck using P/B or P/E ratios)
One way to start could be to ignore performance of the data structure.
The first main job dicts are being used for is the `mem` dict mapping a key (variable name) to some value record.
A data structure that supports Store(K, V) & V = Get(K) could be something like an stack allocated array of (Key, Value) pairs, that you search through using linear search to implement Store & Get. It wouldn't be very fast, but you probably don't have too many items in a typical DSL program. You'd need to implement some kind of stack or so on - or perhaps you could get away with reserving some fixed capacity.
Interesting to see how the author decomposed the problem:
- C raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.c
~~ LLM refactor of the C code ~~>
- SSA-style C raytracer code https://github.com/mTvare6/rayfuck/blob/master/ray_ssa.c
~~ c2dsl.py helper script (compiler) ~~>
- DSL raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.dsl
~~ dsl2bf.py helper script (another compiler) ~~>
BF raytracer https://github.com/mTvare6/rayfuck/blob/master/ray.bf (~22 mb of unreadable nonsense)
The dsl2bf compiler has a bunch of examples of implementing slightly higher level abstractions atop BF primitives. E.g. "go" to move the pointer to a different offset, destructive & non-destructive copies, all the way up to things like division -- BF only natively offers unary addition/subtraction.
If we have a read of the code of the final compiler, dsl2bf.py, the abstractions used in that code are relatively simple: global variables, local variables, lists, dicts, for loops, function definitions & function calls. It is feasible to implement a simple compiler like dsl2bf in BF itself, with sufficient head scratching. Again, quite unpleasant to try it directly in BF, but a next step could be to implement the dsl2bf compiler in the DSL itself - extending it if necessary, then compiling it with itself to produce a dsl2bf compiler implemented in BF.
> It has been discovered that online used bookstores across Japan have been receiving a surge of large orders for books since around August of this year. Interviews with these bookstores reveal reports of "100 books sold per day" and "days where sales have increased fivefold," leading to widespread speculation within the industry that the orders are intended to collect training data for generative AI (artificial intelligence). Further investigation revealed records of over 50 tons of books being exported from Japan to the United States. Is it acceptable for books to be consumed and discarded for AI training?
[...]
> Nippon Television investigated using "Sayari," a tool that analyzes import and export data, and confirmed records that a group company of this major Japanese book distributor exported more than 50 tons of "JAPANESE BOOKS" to the US since last year. Assuming that all the books were heavy hardcovers (calculated at 500 grams), this would amount to the equivalent of 100,000 books.
It's unclear if this is very useful.
The reason it may not be very useful is that one of Deflate's ingredients is a pass that replaces repeated substrings with backreferences to the earlier occurrence in the plaintext input stream.
E.g. suppose we want to find an n=200 byte sequence x that minimises len(gzip(context+prompt+x)).
If there exists any 200 byte sequence y such that prompt+y is a substring of context, then Deflate can encode prompt+y as a backreference to that earlier sequence - it needs to store a match-length & a distance-length, encoded using its Huffman trees. This candidate solution y may not be a global minima to our stated objective function, but if not, it's probably going to be a very good near-optimal approximate solution.
Taking a step back, repeating huge chunks of the input context produces something that's great for minimising compressed output size but doesn't seem particularly helpful as a generative model.
edit:
Yep, I tried it out by running an experiment. Searching for the prompt in the context & then copying the following text as the solution produces solutions that are much better, in the sense of minimising the compressed output length, than beam search, while also being unhelpful as a generative tool.
With the same example as the blog post:
context: first 30,000 bytes of tinyshakespeare.txt
prompt: 'MENENIUS:\n'
Let L(x) denote len(gzip(context+prompt+x)), our objective function
Let's call the proposed search method of searching for the prompt in the input rfind (after python's str.rfind).
Then we have
search method soln soln length feasible? objective value search time (wall clock, s)
------------- ---- ----------- --------- --------------- ---------------------------
emptystring "" 0 no 13,023 0.04s
gzipt beam search see blog post 200 yes 13,051 11.93s
rfind see below 200 yes 13,026 0.04s
Here's the solution 'generated' by rfind copying and pasting from the input context, starting from the rightmost occurrence of "MENENIUS:"
MENENIUS:
O, true-bred!
First Senator:
Your company to the Capitol; where, I know,
Our greatest friends attend us.
TITUS:
COMINIUS:
Noble Marcius!
First Senator:
MARCIUS:
Nay, let them follow:
The Volsces
def find_candidate_solution_from_context(context, prompt, length):
n = len(context)
i = context.rfind(prompt, 0, n-length)
if i < 0:
return b''
i += len(prompt)
return context[i:i+length]
out += find_candidate_solution_from_context(corpus_window, prompt, length)https://www.ams.usda.gov/mnreports/fvdidnop.pdf
Readers may wish to skip ahead to page 4, where onions are discussed.
https://www.morningstar.com/columns/rekenthaler-report/archi...
Be the party robot liability insurer you want to see in the world.
Maybe Americans get higher incomes because US companies structurally sell to larger markets than Australian companies, so - at least for those roles with scale / leverage - the role is more productive & the absolute value that the employee can extract is high, even if the proportion of the overall value extracted by the worker is similar to or lower than the proportion extracted by an Australian worker.
Maybe if Americans had stronger unions, perhaps American workers could benefit from both higher incomes - due to the increased scale & opportunities of the US market - & increased protections relative to Australian workers.
Another thing that is quite different between the US & Australia is that in the US, the public is generally a lot more trusting of business over government. US business interests have a long history of influencing US public opinion- there's examples of stuff like business interest groups creating educational materials & getting them into schools, so kids learn early about the wonders of capitalism & free markets. It's unsurprising that you might not find unions so popular in such an environment. A book that details quite a lot of that history is Kerryn Higgs' book Collision Course: Endless Growth on a Finite Planet [1].
[1] https://direct.mit.edu/books/book/3683/Collision-CourseEndle...
Expressed as fractions of the total US population in 2016:
- about 28.5% of the population was not eligible to vote (due to age or other reasons)
- about 31.6% of the population was eligible to vote but did not vote for either candidate
- about 20.4% of the population voted for Hillary Clinton
- about 19.5% of the population voted for Trump
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.