The "fair use" part takes a lot of place in this article.
It talks a lot about what happens if you use more tokens than what you're allowed, but curiously doesn't pip a word about what happens if you use less - for example maybe with a partial rebate on your next billing cycle ?
I think "fair" should mean "fair for all parties involved", currently it's rather a "we don't want to incur any risk" policy, since I don't see how it's fair for my end of the contract.
I'd rather pay for my actual usage at any other provider than pay for min(actual usage, 25$) at Kagi.
It's a good idea, but from the docs it looks like the high level abstractions are wrong.
If my data pipeline is "take this table, filter it, output it", I really don't want to use a "csv file input" or a "excel file output".
I want to say "anything here in the pipeline that I will define that behaves like a table, apply it this transformation", so that I can swap my storage later without touching the pipeline.
Same things for output. Personally I want to say "this goes to a file" at the pipeline level, and the details of the serialization should be changeable instantly.
That being said, can't complain about a free tool, kudos on making it available !
Which does the 100x speedup too and is a "safe" way to adjust memory access to numpy strides.
Whether the output is correct or not is left as an exercise to the author, since the provided benchmark only use np.zeros() it's kind of hard to verify
I wonder why are the example videos this specific clip compilation format.
It feels to me that to navigate that, you essentially have to index 500 10-seconds videos, and that looks a lot easier than retrieving information that is in an actual 1 hour long video, because the later one will have a lot more of easy to mix-up moments. So maybe it hides an inability to answer questions about actual long videos (in the paper, the other example videos cap at 3 minutes length for what I can see).
On the other hand, maybe it's just for results presentation purposes, because it is much more readily "verifiable" for everyone than saying "trust us, in this very long video, there's the correct answer unarguably".
So if someone happens to more about that, I'd be very interested
The planet has never been, is not and probably won't be in any near future in peril. Humanity is. Humans disappearing is the concern of ecology. The planet will adapt just fine with or without us, and species disappearing will be replaced in time by new ones.
Not having children is not effective at perpetuating the human race, and thus not usually considered as an ecological solution.
That being said, you don't have to have children to be an ecologist either, but you certainly should realise that your efforts are directed towards future humans, not towards the planet which does just fine anyway.
Here's a conclusion that you can also take from the same article :
"In the UK, ages 1-59 year olds are dying at almost eight time the rate if they don't have any baby tooth left and don't absurdly love dinosaurs".
The fact that people have to actually write the whole data analysis down is mind boggling, because it's so trivial to understand the reason.
Still, this is the conclusion :
"Thus, the results we see in the actual UK all-cause deaths for fully vaccinated and unvaccinated is not unexpected, and can be fully explained by the Simpson's paradox artifact since the observed ratio of vaccinated:unvaccinated all cause death rates, 1.82x in week 30, is less than the expected background ratio of 2.41x based on their disparate age distributions."
That's not "a lot of hand waving to try and explain it away". They do a very methodical and sensible mathematical analysis of the data at hand, including the initial data point, to explain a very simple thing : people tend to die older overall, and older dying people tend to vaccinate more.
Is focusing on github stars specially meaningful ? Is there any functional difference for the repo between having 6k stars (as of today) and 54k ? I don't think so honestly.
Github stars are just not something useful to monitor closely. I had a look at my starred repos on github, 95% of those I have no idea what it is anymore anyway.
So yeah, github didn't do any extra effort to restore what's imo essentially a vanity metric. Makes sense to me ?
If think the joke is that author himself don't side with the (mostly pointless) debate about pizza and pineapple, so whatever your own opinion, you can see his point.
The sheer difference in placement and style between the "now now" button and the "allow suggestions" button is all one need to know to be certain it's a bad idea to allow that.
You don't need dark patterns to opt in your users to something good for them.
But then someone at the bank has to decide between Visa and Mastercard.
And this persons surely thinks "ok, the conditions are roughly the same, what is going to make sure none of my clients even bother to ask why we chose this".
So the bank picks something they know that for sure their clients won't question, and here you are. Even if a newer provider emerged with better conditions, they probably wouldn't pick it because they don't want to deal with the inevitable questions.
Maybe if you're an e-business, you'll split everything happening on your website by client id, but still want events belonging to a single client to be received in order, for practicality.
>Your new technology claims to be superior to existing lithium-ion
To be fair, it doesn't. The article is explicit that it's only 20% as mass efficient s lithium-ion battery.
On the other hand, it's also true that the vehicle aluminium mass is mostly dead weight, so exploiting it to serve as a battery doesn't seem insane.
Except now, they need to know what to do when something hits it, breaks it, etc... So I'm not convinced this is a good idea for cars (or for anything), but at least, it goes in a direction that actually seems new instead of just doing "same but better". I could actually see that used as a support for solar panels so that they would litterally ship "batteries included".
Well, my initial point wasn't that bandwidth is _bad_, it isn't, but rather that the fact that ISPs got everyone, apparently including lawmakers to focus on it isn't good for our actual usages, where latency and its stability are the primary drivers or perceived performance.
It's no wonder, since bandwidth has ample room for easy improvement, while providing a good and stable ping is actually a bit difficult. But I still find it heavily biased, and a bit sad.
How often does your cloud storage provider allows you to send 1Gbps to them ? For the ones I use (dropbox, mega, google drive), the answer is never where I live. At best, it will be 10% of that, and usually less.
So I don't know if the concept is explained in more details elsewhere, but I think it's clearly an integral part of their communication.