I guess if you tell codex to build a transpiler from a subset of python to brainfuck, then solve in that subset of python, it would work much better. Would that be cheating?
It would have been fun to see how AI generated voice (like https://www.enginn.tech ) could be integrated as well (and have an estimate of how much time it saves)
I guess it's probably something along the lines of "LaMDA: Language Models for Dialog Applications" (see https://arxiv.org/abs/2201.08239 ). Given that the three first authors are part of the team at Character.ai (see https://beta.character.ai/help)
Although they should not dismiss it at all as it can lead to extremely successful companies. I have Dataiku or UIPath (they did it for years) as good examples. They leveraged their existing customers to test their first product, with success.
That is true up to a certain point (for instance, in my experience, having bounding boxes that are not pixel-perfect acts as a regularizer), but there is also a good chance that you are mislabelling edge cases, situations that happen rarely, and that definitely hurts the performance of the neural network to make a correct prediction on these difficult / uncommon scenarios.
Using simple techniques, they found out that popular open source datasets like VOC or COCO contain up to 20% annotation errors in. By manually correcting those errors, they got an average error reduction of 5% for state-of-the-art computer vision models.
Sure, in terms of expressivity, you can obtain much better results with a CNN. But very often, it is done at the cost of computational efficiency: SIFT descriptors are "easy" to compute.
This paper titled "Backpropagation in the Simply Typed Lambda-calculus with Linear Negation" describes how to generalize the backpropagation algorithm used for computational graphs (like in PyTorch or TF) to the simply-typed lambda calculus augmented with a notion of linear negation.
By relying on conceptual tools originating from Linear Logic, the authors prove the correctness of the transformation and its time efficiency.
We started using Slite http://slite.com/ 6 months ago with great success. We previously used Atlassian Confluence for our internal knowledge database, and it resulted in very static content and poor adoption. Slite is a much better choice: we use it for "static" company knowledge (like onboarding, processes, etc.), but also for most of our dynamic content (meeting notes, document drafting, sales support documentation, etc.).
Many people (including dev) use it on a daily basis, and most people on a weekly basis.
For those who never heard about Tierra. I bumped into it today, and it reminded me of the times I was fascinated by this experiment and was playing with similar ideas. Old school.
Yeah but it's still misleading as we are talking about approximating continuous functions here, not any function. Those examples are not clearly computable, or even just continuous..