animeshchouhan

fixed it!

we have the wrapper orchestrator + additional specialized tools. so yeah we are better than just wrappers.

haha nice catch but this is about development speed

we are building tool plane integrations around the same. stay tuned!

we are building tool plane integrations around the same. stay tuned!

wait are you the mitxela from youtube fluid simulation pendant video

when LLM calls are the bottleneck, the programming language stops mattering.

the website isn't the product. try copperhead and judge the engineering :)

not quite. copperhead operates on its own hardware IR, compiles verified KiCad files and generates manufacturing outputs.

we're also building a design house around it to close the loop with fabs, handle DFM questions and eventually let you hit "order" and receive fully assembled boards!

not quite. copperhead operates on its own IR, which then compiles to KiCad files.

soon :)

we're developing https://copperbench.org - an open-source benchmark for evaluating ai agents on real, verifiable hardware design tasks.

fair critique but copperhead works as a feedback loop: design, verify, revise and repeat. closer to an engineering control loop than waterfall with an agent on top :)

copperhead isn't just a wrapper around claude or gpt. it combines model intelligence with its own hardware IR, deterministic engines and continuous verification.

Thank you so much for the constructive feedback!

> This presentation seems bizarre...

My thought process was setting the context of how the problem would be solved by pen/paper and implementing a recursive solution if you didn't know binomial theorem beforehand. It is trivial to implement coeff using math.comb so skipped that part.

> Applying computational brute force...

That's the fun part at least for me, modeling problems not meant to be solved programmatically and solving them anyways.

> Finally: the JEE is specific to India...

Yeah true that, should have given a better context

Actually, I am just starting with writing blogs, so trying various avenues. Thanks again for the feedback. Will work on improvements.

Glad you went over my post. It was a great experience watching someone go through it on a live-stream.

Well the formula is mentioned but still I added an explicit section with the formula here: https://animeshchouhan.com/posts/measuring-distance/#approxi...

Thank you for your feedback!

Well, this would depend totally on how the scheduler has been implemented. I will give you an analogy for a simple implementation:

Suppose we receive 10 numbers as inputs. We set up 10 cars around a race track with the numbers as their race numbers and set their speeds to the numbers we received as inputs respectively. Now the judge(scheduler) checks at a fixed small interval which car crossed the line and notes down the order. This list gives us the numbers in a sorted order.

This implementation would be very naive but as I said it totally depends on scheduler internals. Modern deadline schedulers would sort the tasks by their deadline times and that's totally correct. Just pointing this out.

Yes, that is true for any sorting algorithm. We can always achieve better results if we preprocess the data on some parameters. Thanks for your feedback, will try to incorporate this in the later version!

Well, the scheduler will process all tasks parallelly, but this too would have its limits. This technique has many pitfalls and is therefore not meant for any practical use.

Yeah that's why I generalized the dependency on any scheduler. We can use various properties and methods to achieve the same results.

Yeah totally agree, it would need a better scaling function to tackle outliers. The basic scaling was just to give an idea of how this could be improved. We can always devise better scaling methods and negative number handling. Thanks for your feedback, will try to incorporate it!

It's a toy sorting algorithm and isn't meant for production use anyways as it isn't efficient and lacks predictability.