Math! Equations! Calculators!

[raykholo]

As we discussed here, we can do expressions and basic math right in TSX, cool! https://discord.com/channels/1233487248129921135/1353415621995397172/1413333949417259098

However, I think it might be cool to build up some global functions that I don't have to paste in myself every time, starting with a function to evaluate ohm's law, and perhaps one for LED brightness. I built my own little LED resistor calculator to help with constant brightness at different voltages, and I'd love to have this kind of "solver" as something that can be called directly in tsci. I realize that I could build that api endpoint externally and call to it, and people should be welcome to do that, but that to me seems slow, prone to failure, and I'd love to see it be native.

https://ray-of-sunshine-led-calculator.onrender.com/calculations

---

That brings us to the more advanced thing that atopile advertises as "maths" and "solving systems of equations".
https://docs.atopile.io/atopile/essentials/1-the-ato-language#units-and-tolerances%2C-assertions-and-maths

I'm not after anything crazy here, and I'll be the first to admit that I've struggled to write the .ato component descriptions required for those math capabilities to even work for me, but I would love to see things like "I want this adjustable buck regulator to output this target voltage, figure out the resistors and other parts I need" and "I want this LED to be this target brightness from whatever voltage is feeding it, figure out the resistor for me" happen.

[seveibar]

One benefit of tscircuit is people can put these types of modules in "userland", so you could publish something like @tsci/raykholo.buck-converter that exports <BuckConverter inputVoltage="5V" outputVoltage="3.3V" />. One reason i like this over explicitly building it into tscircuit is the user can configuring much more- they could dynamically change chips based on the user's parameters, or they could accept tolerances and add capacitors as necessary etc.

[raykholo]

Interesting, that could be very cool and opens up larger doors for the programatic generation of circuits that we've discussed.

I think one very specific point that I want to demonstrate is "tsci supports math and auto-calculating things for you, but it's the wild west of 3rd party userland only implementations with no standardization"

These separate actions occur:

1. Someone creates a component definition for a certain adjustable buck regulator. In this amazing new word of circuits-as-code, they want to add the equations from the datasheet or whatever other logic to calculate the resistor divider for a certain output voltage
   I imagine it would (could?) be part of the schema as shown here? https://docs.tscircuit.com/guides/configuring-chips#specifying-the-manufacturer-part-number-or-supplier-part-numbers
2. Separately, it's possible that someone has written support in their userland for doing calculations for any (or some) buck regulators based on some input variables.
3. Lastly, someone wants to use the component explained in # 1. They would just define their desired output voltage and current as part of "actually using the component in their design", like so:

<BuckReg
name="U1"
inputVoltage<="6v"
outputVoltage= "3.3v"
outputCurrent<="2a"
connections={{
GND: "net.GND",
}}
/>

The explanation is a bit mangled. I think the point that I'm trying to show is that if you don't want to host your own equations in main, that's fine, but there won't be any consistency between each person's own solution and syntax, so each component that has support for this might end up with completely different required syntax and then the building blocks of circuits are no longer interchangeable.
There's some other question about whether # 2 in my explanation actually is needed, or if all the math just ends up in # 1, but the point stands about consistent naming conventions for variables and syntax.