The plastic coin is the only coin in my wallet I won't accidentally spend. Ironically while the replacement is free in theory that single plastic holds _higher_ value to me than a regular coin it replaced.
That's what's always puzzled me as well. There are keychains with such a "coin" magnetically attached, and I've always thought "if I lose a euro, I've lost a euro. If I lose this token, I'll have to buy a whole other keychain!"
Why would I buy something I really don't want to lose to replace something I kinda don't want to lose?
"On 1 March 2022, the Council of the EU [...] by
which it is prohibited for “operators to broadcast or to enable, facilitate or otherwise
contribute to broadcast, any content by the legal persons, entities or bodies"
https://rm.coe.int/note-rt-sputnik/1680a5dd5d
Interesting, I should benchmark this. I have only used Bunnycdn so far and latency seemed similar to most tile providers like Maptiler and others (but a very limited test). This was using the full planet pmtiles file.
Bunnycdn also makes it easy to prevent downloading the entire file, either in case you care about anyone using it or just want to prevent surprise downloads for those exploring network tab.
Quick benchmark of pmtiles directly in maplibre vs served tiles, both via Bunnycdn and 5 areas sampled using same style.
Total impact on page end to end load time: 39ms longer with cached range requests from pmtiles than cached tiles.
Individual requests are comparable in the 20-35ms range, so the slight extra time seems to be from the additional round trip for range headers (makes sense).
What I haven't understood is why not write a program that serves the pmtiles individually on the server? Might not be as performant (but easily hit 1k RPS) but wouldn't require mounting another filesystem which practically rules out a containerised environment.
It's also similar to load balancing. Least requests vs. best of two.
Benefit being that you never serve the most loaded backend.
I guess the feared failure mode of least requests and LRU is similar. Picking the obvious choice might be the worst choice in certain scenarios (fast failures and cache churning respectively)
I suppose it is. There is a lot to tokenization - pre-tokenization, how to handle digits, the tokenization training approach - that is about adding cleverness. In the long run, the bitter lesson would be to just get rid of it all and learn from more data. Many people would love to do it. But I think for the case of BLT, digits will still be an issue. There is no way an autoregressive entropy model will be able to split numbers sensibly, since it has no idea how many digits are coming. It seems like it will struggle more with arithmetic. Perhaps you could reverse all the digits in a number, then it has a chance. So 12334 becomes 43321, and it gets to start from the ones digit. This has been suggested as an approach for LLM's.
Math operations go right to left in the text, while we write them left to right. So if you see the digits 123... in an autoreressive manner, you don't know really anything, since it could be 12345 or 1234567. If you flipped 12345 as 543..., you know the place value of each. You know that the 5 you encounter first is in the ones place, the 4 is the tens place, etc. It gives the LLM a better chance of learning arithmetic.
so basically reverse notation has the advantage of keeping magnitude of numbers (digits!) relative to each other constant (or at least anchored to the beginning of the number)
doesn't attention help with this? (or, it does help, but not much? or it falls out of autoregressive methods?)
Attention does help, which is why it can learn arithmetic, even with arbitrary tokenization. However, if you put it in a standard form, such as right-to-left groups of 3, you make it an easier problem for the LLM to learn. All the examples it sees are in the same format. Here, the issue is that BLT operates in an autoregressive manner (strictly left to right), which makes it harder to tokenize the digits in a way that is easier for the LLM to learn. Each digit is its own token (Llama style), or flipping the digits might be the best.
> Isn't that the opposite of the bitter lesson - adding more cleverness to the architecture?
The bitter lesson is that general methods and a system that learns trumps trying to manually embed/program human knowledge into the system, so clever architecture is ok and expected.
And my understanding back then was that enforcement of payment was via the honour system. It was even possible to pay for your contacts, likely to make it as low friction as possible especially as paying for something on the internet was still a relatively new thing.
* It includes price differentiation. Grounds that want to save the last penny can do so by handling payments themselves. I guess camping grounds are very price sensitive.
* It grows with size of the value provided
* Grounds can start using the tool without paying anything. Thus low barrier of entry
* It seems unlikely anyone can win over existing customers based on undercutting your price.
* 1% of revenue of a business sector can make up a nice indie business.
Thanks for your feedback and for validating the pricing model! We see it the same way.
Most property management systems charge campground owners several thousand dollars upfront, before they can even try the software. That’s where our approach stands out: we offer a low barrier to entry paired with a modern user experience. Many competitors started over 15 years ago, and you can tell by how outdated their products feel.
Taking just a 1% cut can pay off if it helps capture more market share, this was my thinking too. We’re not quite there yet, as not all of the 250 campgrounds on our platform have adopted online payments. Still, it’s both exciting and a bit terrifying to see some of them already processing over $250,000 in annual bookings through our system.
I’ve had a few sleepless nights, so I wouldn’t necessarily recommend building a marketplace product to everyone. Once real money flows through your platform at that scale, things get intense fast.
reply