Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support negative constants #370

Open
chiphogg opened this issue Dec 23, 2024 · 0 comments
Open

Support negative constants #370

chiphogg opened this issue Dec 23, 2024 · 0 comments
Labels
⬇️ affects: code (interfaces) Affects the way end users will interact with the library 📁 kind: enhancement New feature or request 💪 effort: medium
Milestone

Comments

@chiphogg
Copy link
Contributor

All I really want is negative constants. I've previously argued at length that we probably don't want negative units, and definitely don't want negative magnitudes.

In terms of the perfect conversion policy for Constant, this isn't too difficult. We can factor out the guts of Constant into a ConvertsTo mixin, and then add NegativeConstant, with simple rules for keeping track of the sign when multiplying Constant and NegativeConstant.

But here's the problem. Multiplying by a Constant simply adds a factor of that constant's unit to the number or quantity in question. If that constant is negative, but the unit itself is not, then we lose the sign information. We also create a discrepancy between the constant itself, and its associated unit, which feels bug-prone.

OK, so maybe we should open the door for negative units? Not that we'd encourage them, but supporting them would keep negative constants very simple.

In our unit implementation, we reason in terms of two properties: the dimension and magnitude. Does this mean we need to add a sign property, and keep track of it? That seems like it could work. On the other hand, "sign" and "magnitude" feel like two parts of a pretty coherent whole.

So maybe we should allow negative "magnitudes" after all? Would that be so bad? I think my objection was focused around the name: a "magnitude" is a "positive real number". But a "nonzero real number" also makes sense. It's still closed under products, and most powers. Some powers are not closed (rather famously, $(-1)^{1/2}$), but we can simply return a hard compiler error if this gets attempted. And I guess this answers my objection to the anticipated logarithm use case: we can simply produce a hard compiler error for the logarithm of a negative number, and the remaining use cases are unaffected.

The benefit of starting with Magnitude, of course, is that if we do it correctly and carefully, the downstream functionality should just work. (Or at least, can be made to work in a straightforward way. We'll need to add the ability to reason about the sign of a magnitude, just as we can reason about whether it's an integer or rational. And we'll need to double check everywhere that uses these properties. But this should be doable via incremental steps.)

Finally, I'd like to get enough of a proof of concept done to unblock #369 before evaluating whether to land this. I'm not completely sure all this is worth it until I can see for sure what it unlocks, and what it costs.

@chiphogg chiphogg added 📁 kind: enhancement New feature or request 💪 effort: medium ⬇️ affects: code (interfaces) Affects the way end users will interact with the library labels Dec 23, 2024
@chiphogg chiphogg added this to the On deck milestone Dec 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⬇️ affects: code (interfaces) Affects the way end users will interact with the library 📁 kind: enhancement New feature or request 💪 effort: medium
Projects
None yet
Development

No branches or pull requests

1 participant