That's true, but that's just one model that has some easier setup in the ecosystem. It's not easy to get a consumer gpu that has 128Gb of vram, so while the Halo chip isn't as performant, the ceiling for running larger models is higher.
> simple chart specs can be reliable, but generated charts are often of low quality due to reliance on system defaults; - complex chart specs with explicit details can produce good-looking charts, but they are verbose and agents can struggle with reliability
N of only a few of us working on an analytics agent, I don't think we've been finding this to be the case. We've been impressed with just how good LLMs (even smaller open weight models) are at using Python and R for visualization. Often any shortcomings go away if we iterate a bit to about ambiguity. Are there any threads of research that could better support this claim or highlight where issues might be?
I no longer keep my dotenv files in plaintext. I use `sops` to keep an encrypted env around and you can use tools like direnv to make them available to your shell while you're working. Obviously the LLM could print any of these secrets, but it's less likely. Additionally I find that at least claude seems to avoid reading the dotenv. And lastly, don't make any local secrets that important. Limited scope, dev accounts, etc.
Yeah, that's cool, but it would be almost completely unnecessary if python just had actual private methods/classes/properties. It's a lot like pydantic, which is completely unnecessary if you had strong typing.
Yes, but:
a) they're a second class citizen, not guaranteed to be used in whatever niche of the python ecosystem you find yourself in and there's already an n+1 problem with multiple type checker written by third parties, rather than having 1st class language support tool that's consistent. You're not going to get it by default, you're usually going to have to do some configuration (and maybe bike shedding) to get it working;
b) they completely negate the idea of python being "easy to read", your code is now littered with `if TYPE_CHECKING:`, `Literal`, `TypeAliasType` and any number of workarounds needed to make your hints work out. Unfortunately the syntax was just not designed with typing in mind, and I think it shows;
c) the idea of "hinting" rather than enforced type checking means you have no guarantees that a type is what you need it to be, you have to do a lot of boundary work to make sure the edges of your code are coercing things to the right type. While I love pydantic and find it to be an excellent library, to me it's the kind of code smell you get in languages without strong typing. Also you're going to get a lot of spurious type errors along this path as well;
I will gladly use python's type hints, it's a whole lot better than nothing (IMHO better than typescript), but in it's current form it will always fall short of a language that was designed with strong typing in mind.
- strong typing
- real concurrency (heaven forbid you want a background task without having to spool up an external message queue and worker)
- immutability
- limitations in error handling (sort of just typing really)
- limitations in nullability (also typing)
- memory layout is usually hidden or abstracted away
- no actual private methods or classes
That's far from a complete list, but maybe you're taking for granted the typical pythonic conventions that many practice. It requires a ton of work to design and architect python systems of any non-trivial size for maintainability and understanding. No language is perfect, but there are plenty of languages that make supporting complex systems easier than python.
I've seen a few suspect benchmarks for recent announcements of LLM releases. I'm sure they made an attempt at an honest benchmark, but until there's an independent assessment and benchmark (preferably multiple) you have to assume that there's bias in anyone's self published benchmarks like this.
I'm guessing it's a fine-tuning of some existing LLM model or API, but this largely seems to be an "agent" and UI that includes some SWE like workflow coding to allow more complex requests to be asked than just an LLM could provide.
There are promising methods developing for Physic's informed neural networks. Mathematical models can be integrated into the architecture of neural networks such that the parameters of the designed mathematical models can be learned. Examples include learning the frequency of a swinging pendulum from video, amongst more advanced ideas.
Do what you want with some of those tips, maybe not necessarily good advice. But if you're searching, try these search queries replacing `%s` with your desired role(s):
Most of those ATS systems are super annoying. I actually give preference to employers using more modern systems that have up to date user experiences, but regardless, it doesn't hurt to scrape and search all the big ATS players.
The paper linked above does directly address the case of multiple experiments occurring in the same context. They address this with hill-climbing over those 180 different variations. The use of a bayesian linear regression takes place of the exploration found with Thompson sampling.
They have some hard comparisons in some of their earlier blog posts on how spacy compares to the other popular open source NLP libraries. In my experience it has been much easier to use and faster than things like Stanford's library or NLTK. In general it's aimed at production or commercial use, whereas the other libraries I typically hear mentioned are aimed at a more academic audience.
Have you used paredit-mode in emacs with a lisp dialect? Getting proficient with this mode can be a lot like what you describe. Paredit let's you navigate and edit the tree structure of lisp code pretty effectively. It's not inherently a modal paradigm, but I used it evil-mode successfully. I'd imagine what you describe could be a refinement on that technique. Lisp lends itself well to this type of editing due to it's lack of syntax. Other languages are more difficult.
Artemis Health | Product/Data/Engineering Roles | Salt Lake City, UT | ONSITE, Full Time | https://artemishealth.com
We build analytics and visualization tools for self-insured companies. We're funded, have had great growth, and we've got several open positions that we're hiring for including:
- Data Pipeline Manager
- Data Quality Analyst
- Data Pipeline Engineer
- ETL Engineer
- Software Engineer in Testing
- Frontend Engineer
Our frontend and API stack is built with Angular, Django, and Django Rest Framework, and some Rust. We're using MySQL and Redshift for the operational and analytics databases respectively.
With our backend and pipeline we use some traditional ETL tooling (Pentaho, Kettle) and have started building out the more complex aspects of our pipeline with the JVM and Kotlin, in addtion to some various python scripts. Again using MySQL and Redshift databases.