If you set the screen brightness and background color right, you can make a screen look like paper or maybe an e-ink display. Unfortunately, the illusion can break within minutes if clouds are moving in the sky. Also the screen doesn't reflect like paper if viewed at different angles. Nevertheless, I wonder how well it would work to do such a calibration with a sensor.
That's the idea, but what makes it a bit more complicated is that a string can contain a prefix of itself, like "mama" in the article, or in the worst case "aaaaaaa".
Yes, so for example if you were searching for "elephant" and matched "ele", then you could only advance by 2 since the 2nd "e" might be beginning of "elephant", but if you matched "elep" than you could advance by 4 since "ep" is NOT a prefix of "elephant".
But still, it all comes down to how far can you advance at any given match failure position.
One major advantage of FinGPT or Bloomberg's LLM is that the embeddings produced by the model can be used for downstream prediction tasks. GPT-4 does not expose its embeddings so it cannot be used for this.
sorry, noob here trying to make sense of this: you mean you can extract embeddings from the model file or that the embeddings are available in the repo and you can just use those files?
Kind of. You feed the LLM the input text for your prediction, you extract the activations of the final layer of the LLM (so the weights * the input of the previous layers), then use that activation vector, or embedding, as the input for a separate model. This separate model that uses the embedding can be any classifier or regression. A common use case for this is document classification.
To use the 100 door extension some people find helpful:
If Monty always reveals the 98 doors that don't contain goats, then 99% of the time (every time you picked a non-car door), the other door will have the car. If Monty is opening a random set of 98 doors, then 98% of the time Monty will reveal the car, 1% of the time you'll have picked the car on the first guess, and 1% of the time the car is in the other door. When you're in those 2% of cases where no car is revealed, you have a 50/50 shot of being in either of the 1% states where that happens.
There is no randomness in this sentence. The door has a goat, not a car.
Then again, you might read it as an example outcome. But even if the door was chosen randomly, it would not justify the 50%/50% answer.
Independently of that, assuming that the host chooses the door with the car and the goat with 50% probability each is the same mistake that confused so many, you cannot always assume uniform probability only because there are 2 options.
(I wanted to point out the flaws in your thinking because this has also been a confusing problem for me)
This was an interesting discussion when I read about it long ago.
I don't think it's obvious that Marilyn's interpretation is the correct one. Two possible interpretations could be equally valid.
In law we have the "rule of the last antecedent" that says descriptive clauses modify the nearest antecedent noun.
Under this interpretation "which has a goat" modifies the exemplary door "say #3". Same as saying host opens a door, for example door #3 containing a goat. It could have been say door #2 containing a car.
Marilyn's interpretation is that "which has a goat" modifies "host opens another door." Same as saying the door opened by the host always has a goat.
Language is inherently ambiguous. I don't think either interpretation is unreasonable...
I think you are correct about my thinking: at the time, I assumed it was an example outcome and my brain turned off at that point and simply assumed the probs were still 50-50. In some sense I was both intellectually wrong (in my assumption about it being an example) and intellectually lazy (in my failure to work through the implications of my assumption).
Personally the whole thing taught me is one true hallmark of intelligence is the ability to eliminate unnecessary ambiguity and find the "right" answer.
You can create a hotspot and start a HTTP server. Scan a QR code to connect to the hotspot, then a QR code for the file URL. It's easy and works with any device with Wifi access.
For the server, on Android I use "Share via HTTP". On desktop running a lightweight HTTP server is easy too.
Edit:
Apparently that sounded complicated, here is how I can share a file from my phone to any other phone in the same Wifi.
- Click Share -> Share with HTTP.
- The app opens and shows a QR code.
- Other person scans the code. Their browser opens the file and they can do whatever they want with it.
If you have no Wifi:
- Open QR code for hotspot
- Other person scans QR code for hotspot, then for file.
If you still think it is too complicated, surely there is an opportunity create a simpler UI! From a technology perspective it does not have to be complicated.
> here is how I can share a file from my phone to any other phone in the same Wifi.
This will not work on many public and corporate networks. A common place where you’d want to share.
> surely there is an opportunity create a simpler UI!
It’ll still suck compared to Airdrop. Apple has gone to a lot of trouble to make that work as well as it does. Trying to setup something relying on temporary hotspots will be sub par UX. (And a nonstarter for Apple devices - user apps can’t touch the WiFi settings).
It is standard practice to enable this these days in public networks and it is so common that even consumer grade shit router now come with an option to enable.
I am not sure you understand. You click share, then Share via HTTP, the other person scans the QR code, they have the file. Setting up the server is no effort at all.
Only if you are outside without Wifi you have to do another step, setting up a Wifi hotspot, but that is not hard. And in most situations I have been in both devices were in the same network anyways.
Which of the steps that I described required advanced technical knowledge?
Edit: Ah maybe you thought setting up the server is an additional step. It is not. Share via HTTP is the server. It runs directly on your phone. The URL points directly to your device.
None of that is necessary because you are not exposing anything to the internet. We are still talking about local sharing. Android does not have a firewall so there really is nothing to configure. But if you think it cannot be possible, try it for yourself.
All your traffic can now be captured. DNS requests will be logged. Some traffic might be redirected. When will the connection be closed? What if someone shows you a different QR code, and you're not that tech-savvy. For example a phishing webpage which asks for the user's password. Many many many people will still just enter their single-password-for-everything.
What if the QR code is a deeplink to an app.. for example to a conversation on or whatever. Or maybe someone was previously logged in into some account.
It's literally click in the share icon and choose "Share over QR".
The device then will do the "run a server with the file, create the QR Code for access, display it". Your mum has no need to learn how to run it, just how she doesn't need to know anything about how airdrop works to use it.
It's the same difficulty. They used techy terms because we know that's what's happening, but your mom doesn't need to know those terms or anything like that.
The whole thing is quite confusing at first for such a simple tool. The splash screen says "Create amazing mockups" and "Craft beautiful presentations", somehow that translates to "Frames and backgrounds for marketing images".
> the "app gap" was one of the main problems. High-profile apps like YouTube never became available on the platform
There were great native third-party YouTube clients in the official Store on Windows Phone. On the contrary, I missed my Youtube client after I had to switch back to Android (until I found NewPipe).
The app gap was the generic bland comment about windows phone every writer put in their reviews/articles/tests. I didn't feel I was missing many apps with my lumia 640 and I don't think it's what solely derailed the platform but that mantra felt like death by a thousand same cuts.
It was as boring and stupid as reading "yeah that igpu is fine but not for gaming of course unless you restrict yourself to 2d or indie games" is.
The linked article is not about AlphaFold itself, but about researchers verifying AlphaFold's predictions. So the article directly addresses your question. Unfortunately HN only shows the first half of the headline.
> Shoichet agrees that AlphaFold predictions are not universally useful. “There were a lot of models that we didn’t even try because we thought they were so bad,” he says. But he estimates that in about one-third of cases, an AlphaFold structure could jump-start a project. “Compared to actually going out and getting a new structure, you could advance the project by a couple of years and that’s huge,” he says.
Conceptually, collect seems to create a new vector. In that case you would expect that the memory of the old vector is freed. The library tries to be smart and reuses the old vector as an (undocumented?) optimization. So the old memory that is no longer needed is not released.
Whether you call that a leak or not, Rust is known for its predictability. Allocating 200x the memory which a programmer would expect if he doesn't know the implementation details is bad.
