[ziofill]

The battery example makes no sense:

capacity_SOH ≈ 0.913 − 0.352 · tanh( cycle^((temperature/cycle)^0.485) )

I understand this fits the data, but exponents should be dimensionless, what is temperature/cycle?

[gus_massa]

I've seen crazy stuff for heat exchangers and other stuff used in factories.

When the temperature difference is small, everithing is linear and you get nice formulas.

When the difference of temperature is big and you have liquids with convection and turbulence, you only get empirical formulas with weird exponents. The correct method would be to give the constants with the correct units, but it's usual to specify unit to measure the data instead, and just enter the numbers in the formula.

After a short search in Google, I got this example https://www.researchgate.net/figure/Equations-used-to-obtain...

[sade_95]

This is exactly the niche I had in mind, thank you for the concrete example. Where theory works (small deltas, linear regime) nobody needs my tool. Where turbulence starts, engineers already live with empirical correlations and weird exponents since one century, Nusselt-Reynolds style. A GP search is just a systematic way to produce this kind of correlation, with a Pareto front instead of one formula.

And your point about units is the industrial reality: the convention "measure in these units, then use the numbers" is exactly what the tool does internally. A proper dimensional mode stays on my roadmap, but I feel less bad about it now.

[nyrikki]

I am not saying this result is correct, but you don't have unit safety in python at all

In this example temperature would be a magnitude, not a unitful value.

At least in the ISO 8000whatever convention where a value is the product of a unit and a magnitude like most people are use to.

Here is a Terry Tao post with more information[0] on why the convention is there, but as he mentions, in differential geometry and Clifford/Geometric Algebra you do things like add vectors to scalers all the time.

[0] https://terrytao.wordpress.com/2012/12/29/a-mathematical-for...

[ziofill]

Your answer makes no sense either

[nyrikki]

That is because the way you were introduced to the concepts was targeted at didactic convenience and incremental teaching curricula. Pedagogical efficiency is important but care is also needed when mapping concepts that are accepted as a priori in a specific domain to universal beliefs.

Physics uses the properties of unitful objects to help avoid errors, it is a convention and not (by itself) a fundamental truth.

If your world is physically realizable one, the benefits make this choice a no brainier, but it is still a convention with some convenient outcomes.

A unitful quantity is actually a tuple, specifically (value = quantity x unit)

In computer science and programming, assuming a priori that individual scalers are only useful in the context of units, or that they will behave in the same way can cause you real issues.

Be careful with conventions and assumptions, use them where they serve you well and avoid them where they block you from finding useful mechanical means to solve problems.

[sade_95]

Fair point, and nyrikki has it right: the engine never sees units. Everything is normalized to dimensionless magnitudes before the search, so that formula is an empirical fit on pure numbers, not a physical law. I should say that more clearly in the README.

Enforcing dimensional consistency during the search is a known extension (AI Feynman does a version of it) and honestly it's a good roadmap item, a dimensionally sound form would be more trustworthy.