The hope would be that this unlocks some substantially more efficient or parsimonious math that would fit better on a chip. And that’s clearly my words, not the authors’, per the comment above.

(1) they are claiming to produce apparently bijective closed-form symbolic representations/approximations of, among other things, LLMs. Is evaluating these closed-form representations more computationally efficient? The implications of that are potentially huge. It would be essentially analytic distillation. Fable on a chip and not a data center would be important — and disruptive - in many ways.

(2) Unsupervised, and even supervised, symbolic approaches to problem solving break down due to combinatorial explosion, among other things. This could potentially allow us to treat LLM training and inference as a search algorithm for novel symbolic approaches to solving new classes of complex problems hitherto unreachable through other approaches. If that works, I suspect it’s a feedback loop, too - the learnings from one representation push advances in the other. This would also increase the economic value of large training runs, since the model itself is now valuable, not just its inference.

(3) Per the above, can this push LLM design to greater capabilities?

The relationship between this and Anthropic’s J-space observation is also interesting. This is much, much deeper and more directly actionable, though.

EDIT: I ran my questions through Sonnet — yes, I appreciate the irony — and it was none too sanguine about questions (1) and (2), but thought (3) was reasonable. In any case, this is quite the paper. On reflection, I do think that the apparent reliance on very simple symbolic representations and tasks is underwhelming. But the approach is impressive. And obviously this is still early days, and the value of building a bridge between the very fuzzy LLM models and the rigorous, mechanically provable models would be enormous.

* Developer portal -- self-serve subscription management, API key management, usage tracking, plus documentation

* Billing enforcement -- rate limits, hard quotas, metered overages

Ideal solution covers both, but I'll stitch vendors together if needed. I'm seeing things like Kong, Moesif, and Tyk so far. What are people actually using? How painful is initial setup, and how much ongoing maintenance does it take to keep running? Are you happy with whatever you picked?

Comments URL: https://news.ycombinator.com/item?id=47677424

Points: 2

# Comments: 0

Question: Does acetaminophen use during pregnancy increase children’s risk of neurodevelopmental disorders?

Findings: In this population-based study, models without sibling controls identified marginally increased risks of autism and attention-deficit/hyperactivity disorder (ADHD) associated with acetaminophen use during pregnancy. However, analyses of matched full sibling pairs found no evidence of increased risk of autism (hazard ratio, 0.98), ADHD (hazard ratio, 0.98), or intellectual disability (hazard ratio, 1.01) associated with acetaminophen use.

Meaning: Acetaminophen use during pregnancy was not associated with children’s risk of autism, ADHD, or intellectual disability in sibling control analyses. This suggests that associations observed in other models may have been attributable to confounding.

Comments URL: https://news.ycombinator.com/item?id=43546431

Points: 1

# Comments: 0

Also, I think it’s apparent that the world won’t wait for correct AI, whatever that even is, whether or not it even can exist, before it adopts AI. It sure looks like some employers are hurtling towards replacing (or, at least, reducing) human headcount with AI that performs below average at best, and expecting whoever’s left standing to clean up the mess. This will free up a lot of talent, both the people who are cut and the people who aren’t willing to clean up the resulting mess, for other shops that take a more human-based approach to staffing.

I’m looking forward to seeing which side wins. I don’t expect it to be cut-and-dry. But I do expect it to be interesting.

I built Rapier, a code-generation companion library to Dagger that Dagger modules automatically from annotations to eliminate boilerplate code when pulling configuration data from sources like environment variables, system properties, AWS SSM Parameter Store, and CLI arguments.

Why Rapier?

Dagger is a powerful dependency injection framework, but setting it up to handle configuration data can get tedious and repetitive. Rapier solves this by generating Dagger modules directly from annotations, saving time and reducing errors.

For example, with this Dagger interface:

    @Component(modules = {RapierExampleComponentEnvironmentVariableModule.class})  
    public interface ExampleComponent {  
        @EnvironmentVariable(value = "TIMEOUT", defaultValue = "30000")  
        long timeout();  
    }  

Key Features

Out-of-the-box integrations for: Environment variables (@EnvironmentVariable), System properties (@SystemProperty), AWS SSM Parameters (@AwsSsmStringParameter), CLI arguments (@CliPositionalParameter, etc.)

Supports type conversion (e.g., String -> int, boolean, or custom types)

Easily testable with generated test constructors to inject test data.

Works seamlessly with core Dagger features (components, modules, lazy providers, etc.)

Why Beta?

I’m already using it in production on some of my other projects, so I’m pretty confident it works well, at least for simple use-cases. But Rapier is still in Beta releases, primarily I’m not absolutely sure all the major design decisions are worked out yet, and there may be some non-backwards compatible changes to the user-facing annotations.

Try it out!

Rapier is open source (https://github.com/aleph0io/rapier), and in Maven Central.

I Want Your Input!

I would love your feedback, questions, or suggestions—especially around other configuration sources you’d like to see supported! Even just comment here or a vote on the Rapier roadmap (https://github.com/orgs/aleph0io/projects/11/views/1) would be very helpful to help me prioritize new features! And let me know if you want any tweaks, too!

Other Interesting Things

Some of you Java geeks may also find some of the code and technologies used in Rapier interesting as well.

Detailed Dagger assumptions testing https://github.com/aleph0io/rapier/tree/main/rapier-assumpti...

Annotation processor (e.g., https://github.com/aleph0io/rapier/blob/main/rapier-environm...)

Using Google compile-testing to test the build and run of Java applications during unit testing (e.g., https://github.com/aleph0io/rapier/blob/main/rapier-environm...)

Comments URL: https://news.ycombinator.com/item?id=42852493

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=32927925

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=32664768

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=31060728

Points: 1

# Comments: 0