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.
A lot of people in this thread point at motivation or mental health issues. The issue is likely not so complicated.
You have forgotten how to focus. We live in a world where we are constantly distracted. This is forced on us. The apps we use compete over our attention, our workplace expects quick replies over Slack, our free time is always accompanied by a smart phone pushing us notifications.
These effects are getting stronger. Technology evolves new attention taking techniques. Our remote work culture expects faster replies as you are, in theory, always at your desk.
You can address this focus deficiency, but it isn't easy. Put your phone always on Do Not Disturb. Use site blocking extensions to limit time wasters (yes, even Hacker News). Stop being so responsive at work.
The first few weeks will hurt. You won't instantly be able to focus, and you will feel less productive due to the lower response time. But after some time, you will be able to do work others cannot. You can complete the big work you are struggling to right now. Relearn how to focus.
example? everything he says seems to be well sourced or cited from other experts in their fields, or if its only few studies and not well researched enough yet he explicitly says so. I keep hearing this claim from ppl but nobody can come up with any examples.
It could be due to aging. As people age, it gets harder for the body to release dopamine in anticipation of getting something we done, especially for things that we are familiar with. As a result, one loses focus because of no trickling joy. "Been there done that" in a way is truly a curse.
My own cure is always finding new things to tackle, and tackle only fundamental problems. Of course, my fundamental problem can be trivial to another smarter engineer. The key is to keep myself excited and therefore focused instead of how deep the problem is.
The downside of this approach, though, is that I may have to switch jobs, and I need to work hard to keep myself healthy to have enough energy.
You could be right, I'm soon to turn 40 so maybe my brain is just slowing down and I can't ask as much of it as I used to. Hopefully a better diet and more exercise can counteract that to some degree.
This makes a lot of sense, thank you. The expectation to always be available on teams, to reply to email quickly is very strong at my workplace. My apple watch means that even if I'm making a cup of tea, or using the restroom I still see when people are trying to contact me, or when one of the systems sends an alert so I'm never truly offline.
https://kafka.apache.org/11/javadoc/org/apache/kafka/clients...