Readit NewsSome vision LLMs can accept PDF inputs directly too, but you need to check that they're going to convert to images and process those rather than attempting and failing to extract the text some other way. I think OpenAI, Anthropic and Gemini all do the images-version of this now, thankfully.
I expect the current LLMs significantly improve upon the previous ways of doing this, e.g. Tesseract, when given an image input? Is there any test you're aware of for model capabilities when it comes to ingesting PDFs?
What prompted this post was trying to rewrite the initial parse logic for my project PdfPig[0]. I had originally ported the Java PDFBox code but felt like it should be 'simple' to rewrite more performantly. The new logic falls back to a brute-force scan of the entire file if a single xref table or stream is missed and just relies on those offsets in the recovery path.
However it is considerably slower than the code before it and it's hard to have confidence in the changes. I'm currently running through a 10,000 file test-set trying to identify edge-cases.
Having said that, I believe there are "streamable" PDF's where there is enough info up front to render the first page (but only the first page).
(But I have been out of the PDF loop for over a decade now so keep that in mind.)
It'll be great if we do, although I don't know of any promising research avenues and I lean towards the hypothesis that the average human metabolism is simply tuned to mild obesity under conditions of widespread food availability.
- these drugs are good and a paradigm shift in the treatment of obesity (and have other benefits)
- we must not lose sight of the need to address a thoroughly sick food industry that necessitate so many people needing to use these. Junk food advertising, lack of subsidies for fresh vegetables, HFCS, food deserts, etc.
Chile is experimenting with banning junk food ads to children and is seeing some early behaviour changes.
The point which people seem to be wilfully missing is that we can have both these drugs and advocate for cracking down on a food system that deliberately poisons everyone in society. Having everyone be on this drug because we shrug and say "free market innit" while big corps continue to feed us crap is not a solution, obviously.
delegate Task<string> GetUserEmail(int userId);
Func<int, Task<string>> getUserEmail
Edit: I completely forgot the main reason which is if using a DI container it can inject the named delegate for you correctly in the constructor. Versus only being able to register a single func shape per container.
I'm not sure I understand your use case where you need to conflate the two. You want to enforce the contract but with arbitrary method names?
I suppose you could wire up something like this but it's a bit convoluted.
interface IFoo {
string F(String s);
}
class Bar {
public string B(String s){
return "";
}
}
// internal class, perhaps in your test framework
class BarContract : Bar, IFoo {
public string F(string s) => B(s);
}I've had this on my blogpost-to-write backlog for a year at this point but in every project I've worked on an interface eventually becomes a holding zone for related but disparate concepts. And so injecting the whole interface it becomes unclear what the dependency actually is.
E.g. you have some service that does data access for users, then someone adds some Salesforce stuff, or a notification call or whatever. Now any class consuming that service could be doing a bunch of different things.
The idea is basically single method interfaces without the overhead of writing the interface. Just being able to pass around free functions but with the superior DevX most C# tools offer.
I guess I want a more functional C# without having to learn F# which I've tried a few times and bounced off.