Why don't we pick an existing standard and use that?

Why another 15th standard.

So out of all the inference only chips which ones can I buy?

The only report is a smartnic fpga from Alibaba where we take an onnx design and write our own. https://essenceia.github.io/projects/alibaba_cloud_fpga/

On my M2 Pro Mac Mini the ANE only allows 2 gigabytes compared to the Metal GPU which can use the system ram.

Currently playing with https://www.asus.com/motherboards-components/ai-accelerator/... which is a 4bit, 8bit and 16 bit ai inference chip with 8 gigabytes of ram.

The UGen300 has the Hailo-10H chipset.

The ASUS Store price for the ugen300-usb-8g costs $365.00 Canadian dollars.

Why coin sized, you can fit a gps tracker in a grain of rice-size pellet, why not a phone card.

This is why the custom engine over the last 6 years I've contribute to `godot engine` is more widely used and I haven't finished my game.

I reject this theme, I gained but I also lost.

My prompt of asking it match the comment density of the last release of an exemplar project (Let's say sqlite) seems to work.

my prompt (doesn't help):

> Go easy on the comments, only add comments if there's a big gotcha that is not clear from the code itself, or if something in another place is going to cause a side effect. Code should be self-documenting. When in doubt, don't add a comment at all. If you do have to add a comment, make it short and on point. Comments should show history of code changes or functionality, only comment on the current state (or not at all).

Your prompt is so similar to my prompt.

> Go easy on the comments.

> If you do have to add a comment, make it short and on point.

I defined what easy meant numerically.

<claude> Match the comment density of FoundationDB, which is 12 to 14 percent of non-blank lines in `fdbserver`, `fdbclient` and `flow` at 7.3. </claude>

> only add comments if there's a big gotcha that is not clear from the code itself

<claude> Comment why the code does a thing, not what it does. </claude>

> Comments should show history of code changes or functionality, only comment on the current state (or not at all)

I call this the tenseless continuous-present voice.

<claude> Each sentence states what is currently true of the system. </claude>

<claude> This rules out past-tense edit narration, future or imperative planning, and aging temporal qualifiers such as “now” or “previously”. </claude>

<claude> A sentence that states a present truth stays correct as long as the code stays the same, and goes stale visibly the moment the code changes. </claude>

Here's my impressions of your algorithm:

1. read each site

2. rent a 4090 with https://vast.ai to run vllm

3. let llm model invent its own category and tag names freely

4. save 1KB of metadata each

  a. a small local language model that reads each one and writes a name, two or three sentences, a category, and a handful of tags.

5. `code is going up as open source` soon (TM)

Code appears to already be up: https://github.com/alexmorleyfinch/marlin

The technical details are on another page: https://alexmorleyfinch.github.io/marlin/history/v1/article/...

Your impressions seem about right, but there are a few control steps it seems.

don't forget:

6. let llm write a blog post about this conversation

It's an interesting new type of brag. It roughly means: "I want you to know how advanced I am at using LLMs, and how AI-first I am. So here is how little time I spent, to prove that I am using LLMs as much as possible, demonstrating that I am ahead of the curve on this new trend"

I typically interpret it as an excuse, not a selling point.

it was by no means low effort

Isn't 60 hours by definition low effort? Setting an LLMs effort value to high doesn't count

Would you prefer a parquet dump of acm articles to hugging face?

A llm emulating a person is why many of my used sites banned llms due to scraping bandwith costs

Is this about access or accessibility to claude (for example)

I am sure the entirely of human computing knowledge is not that big.

Blender uses the manifold library after years of petitioning

That's why I integrated manifold into godot engine for constructive solid geometry!

https://github.com/godotengine/godot-proposals/issues/9711

Thank you! CSG has made level prototyping more fun and fast in Godot for me.

How does it compare against https://github.com/elalish/manifold in performance and zero corruption?

I spent a lot of time making elalish/manifold work in Godot Engine and it is now a method in Blender too.

https://manifoldcad.org

If it helps, feel free to use the apache2 licensed unit tests that were generated in manifold development https://github.com/elalish/manifold/tree/master/test

The runtime performance is most probably worse than yours. The goal of this project is a minimal specification that a reviewer can trust. See section in readme on performance and how it could be improved while still keeping formal guarantees, but would mean a reviewer having to trust axioms on floating point numbers: https://github.com/schildep/verified-3d-mesh-intersection#pe...

> Why we cannot have manifold output meshes in general

As far as I know manifold is not verified software, but it does promise that manifold inputs become manifold outputs.

I wonder how manifold will break in that condition or would it snap to the nearest manifold.

https://github.com/schildep/verified-3d-mesh-intersection#wh...

The difference is that my Manifold library uses a different definition of what constitutes a manifold mesh: https://github.com/elalish/manifold/wiki/Manifold-Library#ma.... By being a purely topological definition, there is no implicit assumption that vertices with the same coordinates are connected. As such we can still generate a 2-manifold even in the "impossible" cases.

The more important difference though, is that our library can still handle epsilon-valid self-intersecting meshes, rather than just reporting an error. This is critical in practice because meshes are stored, transported, and transformed in floating-point, so even the formally-proven non-self-intersecting results of the library under discussion will not necessarily be valid input for it anymore after a round-trip through a file format or a rotation.

Still, these are details. I think the real contribution here is demonstrating a new approach to formally verifying software even for notoriously difficult problems. I believe that concept is really important, as the general state of software reliability tells me that the state of the art in testing software is desperately lacking. I think formal verification may well be one of the most important aspects of computer science research in the nearish term.

On a readme style note, please spend more time explaining the algorithm and less time bragging on how amazing vibe coding is or how Lean has a zero trust proof.

I presume the new advance is claim that verified-3d-mesh-intersection is verified and not the claim that vibe coding can replace hand proofs or that the claim that lean4 can be correct without trusting llms.