I'm not quite following. His argument appears to be: The replication system requires a backwards seek, Postgres does not support that operation, things break when that operation is attempted.
I don't understand why replication would need a backwards seek - are you saying it doesn't and he is mistaken on that?
I took a Udacity class by Norvig [1] and my abilities as a programmer clearly were improved afterward.
His code here demonstrates why. It is both shorter and much easier to understand than anything the LLMs generated. It is not always as efficient as the LLMs (who often skip the third loop by calculating the last factor), but it is definitely the code I would prefer to work with in most situations.
Working extensively in SQL for a while also gives you another perspective of programming. There is just no way you can write this with a for loop in SQL since it does not (generally) have for loops.
WITH all_numbers AS
(
SELECT generate_series as n
FROM generate_series(1, 108) as n
),
divisors AS
(
SELECT *
FROM all_numbers
WHERE 108 % n = 0
),
permutations as
(
SELECT a.n as n1, b.n as n2, c.n as n3
FROM divisors as a
CROSS JOIN divisors as b
CROSS JOIN divisors as c
)
SELECT *
FROM permutations
WHERE n1 * n2 * n3 = 108
AND n1 < n2 And n2 < n3
ORDER BY n1, n2, n3
Single handedly most important class in my career back in the day. It took me 3 months to really grok and generalize the Qpig algorithm, even my professors couldn't explain it.
It's amazing how he never used the words "AI" once in this course despite the fact that it is a straight up AI course.
I revisit the course notes at least once a year and I still walk away with something new every time.
I've recommended his book PAIP despite the AI in the title because you can take it as about the craft of programming (I mean things like style and efficiency, not the bare beginning of being able to code at all) -- using old-fashioned AI as the subject matter. To learn better coding you gotta code something.
Yes, this book is an incredible gem. Hard to believe that one human wrote it. I've been attempting to mine its secrets for a long time. Sometimes it makes me a little
embarassed that I've probably spent more time trying to understand it than he spent researching/writing it but I am appreciative that it exists.
But it's especially great if you want to appreciate PN's code more. He actually offers explanations of choices for his distinctive style of coding here. His 6 rules for good code are particularly good. He says they are for good
lisp but I think they broadly apply to any language:
*Edit:* After reading this book I am often really surprised that this book is not referenced as often or more often than SICP is. Not the time or place for a soapbox rant but SICP is often cited as landmark functional programming text when in fact it is largely advocating OO practices implemented in scheme, whereas PAIP really demonstrates full power FP programming on display (type system independent), and where OO practices such as CLOS are used he is quite explicit about it.
Yes, I know that you can get the Q value via RL with Bellman equation or non-parametric evo learning, but at the time I didn't know that and I'm glad I didn't.
Depending on how you count, this code features either 2 or 4 mutually recursive functions, something that is quite rare in Python (esp outside the context of an FSM) but is a signature of PN code.
I had to learn so much about so many things to untangle it.
Actually most of the LLMs algos are less efficient than the readable human one, even with only two nested loops. Only one of them precalculates the factors which makes the biggest difference (there are log2(N) factors, worst case, for large N and a triple loop over those is better than a double loop over 1..N).
There is also the deleteRecords API specifically for this. It's easier than the retention shrink -> increase dance, as it is a single API call and retention does not kick in immediately. The log segment must roll for retention to apply, either due to size or time.
I've used it at home for several years as well, works great. Due to reasons I've used another level to separate services, management, clients and iot (iot.home.arpa, services.home.arpa...) which I kinda regret today.
Not OP, but I too first thought of a state machine. As soon as I started to write it I realized I was over-solving a day-1 problem. So I switched to brute force
I made use of the fact that "egrep -o [some regex]" will print the first (going left-to-right) match for the regex. So I ran egrep -o, and several other programs, once per line of input. (And to go from right to left, I used "rev" and an egrep on the reversed string.) My computer wept, but it worked.
Sorry all, I misused the word finite state. I meant it more from a combinatorics viewpoint(e.g. we only have X amount of operations per Y interval). You could consider my solution to be brute force code.
Abstractly I do this:
read_file()
lines = read_lines()
sum = 0
while lines:
left = get_first_num_forwards(line)
right = get_first_num_backwards(line)
sum += integer(left+right)
return sum
I define get_first_num() something like this:
get_first_num(line):
lowest_index_pair = None
for key,val in dict.values():
get_index_of_key_if_exists()
if_exists: update_lowest_index_pair()
index,num find_first_instance_num() //just gets the first num that appears
update_lowest_index_pair()
return lowest_index_pair[1]//just returns the number
Basically the idea is very similar to yours. We parse each line 11 times in both direction(10 per the word_vals dict and once more to find the index of the first numerical) which is only 22 parses. Then we grab the minimum index from this list and concat with the opposite side.
I just don't do any replacements at the cost of a longer run time. But I figure the cost of 11 parses was low enough that it wouldnt impact the run time significantly for this exercise.
The key point is that overlaps are not an issue because we check for string comparisons in the methods
His book "The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines" was immensely valuable to me as I moved into datacenter management as a new-grad. RIP.
First: Prophet is not actually "one model", it's closer to a non-parametric approach than just a single model type. This adds a lot of flexibility on the class of problems it can handle. With that said, Prophet is "flexible" not "universal". A time series of entirely random integers selected from range(0,10) will be handled quite poorly, but fortunately nobody cares about modeling this case.
Second: the same reason that only a small handful of possible stats/ML models get used on virtually all problems. Most problems which people solve with stats/ML share a number of common features which makes it appropriate to use the same model on them (the model's "assumptions"). Applications which don't have these features get treated as edge-cases and ignored, or you write a paper introducing a new type of model to handle it. Consider any ARIMA-type time series model. These are used all the time for many different problem spaces, and are going to do reasonably well on "most" "common" stochastic processes you encounter in "nature", because its constructed to resemble many types of natural processes. It's possible (trivial, even) to conceive of a stochastic process which ARIMA can't really handle (any non-stationary process will work), but in practice most things that ARIMA utterly fails for are not very interesting to model or we have models that work better for that case.
These insights are really awesome! It reminds me of the common aphorism in Statistics: 'All models are wrong, but some are useful.'These insights are really like a wake-up call, thank you!
Disclaimer: I haven't looked at the linked library at all, but this is a theoretical discussion which applies to any task of signal prediction.
Out of all possible inputs, there are some that the model works well on and others that it doesn't work well on. The trick is devising an algorithm which works well on the inputs that it will actually encounter in practice.
At the obvious extremes: this library can probably do a great job at predicting linear growth, but there's no way it will ever be better than chance at predicting the output of /dev/random. And in fact, it probably does worse than a constant-zero predictor when applied to a random unbiased input signal.
Except that it's also usually possible to detect such trivially unpredictable signals (obvious way: run the prediction model on all but the last N samples and see how it does at predicting the final N), and fall back to a simpler predictor (like "the next value is always zero" or "the next value is always the same as the previous one") in such cases.
But that algorithm also fails on some class of inputs, like "the signal is perfectly predictable before time T and then becomes random noise". The core insight of the "No Free Lunch" theorem is that when summed across all possible input sequences, no algorithm works any better than another, but the crucial point is that you don't apply signal predictors to all possible inputs.
Another place this pops up is in data compression. Many (arguably all) compressors work by having a prediction or probability distribution over possible next values, plus a compact way of encoding which of those values was picked. Proving that it's impossible to predict all possible input signals correctly is equivalent to proving that it's impossible to compress all possible inputs.
Another way of thinking about this: Imagine that you're the prediction algorithm. You receive the previous N datapoints as input and are asked for a probability distribution over possible next values. In a theoretical sense every possible value is equally likely, so you should output a uniform distribution, but that provides no compression or useful prediction. Your probabilities have to sum to 1, so the only way you can increase the probability assigned to symbol A is to decrease the weight of symbol B by an equal amount. If the next symbol is A then congratulations, you've successfully done your job! But if the next symbol was actually B then you have now done worse (by any reasonable error metric) than the dumb uniform distribution. If your performance is evaluated over all possible inputs, the win and the loss balance out and you've done exactly as well as the uniform prediction would have.
I don't understand why replication would need a backwards seek - are you saying it doesn't and he is mistaken on that?
reply