I have a sneaking suspicion

[NinerXrayBravoTwoTwo]

Ever since I got rid of seconds, and time for that matter, in units, I've had a concern that something about this conversion was wrong. So I tested it and got more comfortable with the beautiful way these numbers work and all of physics seems just fine.

There is one place, one blind spot, that I know about. That is the Lorenz equations. units and most of classical physics and conversion/physical constants operate from the perspective of their world line.

What I'm saying is that the units program has a major flaw; Units is only valid within the current world line and frame of reference. A frame/world line moving at a different velocity than you does experience events differently (from your perspective).

Maybe we can build Lorenz transforms/conversions into units one day? How hard could it be?

[NinerXrayBravoTwoTwo]

This is a fascinating approach to redefining constants and units in the GNU units program. You’re essentially enforcing a natural unit system where  and time is directly expressed as a measure of distance. By tying time to distance, you’re taking a step into a framework where spacetime is treated more uniformly—a common practice in theoretical physics, especially in relativistic contexts.

Here are some thoughts and observations about your project:

1. Perspective on Lorentz Transformations

Your comment about units being valid only within the current worldline is insightful. The program, as traditionally structured, assumes a single inertial reference frame. Adding Lorentz transformations to account for observers in different inertial frames is not trivial but certainly possible. It would require extending the program to:
• Accept a relative velocity (or boost factor ) as an input.
• Perform the corresponding transformations for quantities like time, distance, energy, and momentum.

For example, you could introduce conversions like:

Where . The challenge would be integrating these into the program’s existing framework while keeping the logic intuitive for users.

2. Natural Units and Simplifications

By setting , you’re effectively working in a natural unit system. This is elegant and simplifies many equations, but it does require rethinking how some derived quantities are interpreted:
• Mass-Energy Equivalence: You’ve made the relationship between mass and energy explicit by defining time in terms of distance. This eliminates the need for a separate  factor in , as .
• Practical Use: For users familiar with conventional SI units, this might initially be confusing. Including comments or documentation explaining the rationale and implications of this choice would help bridge the gap.

3. Blind Spots and Tests

Your concern about blind spots in the redefinition is valid. Testing edge cases, especially in relativistic scenarios, is crucial:
• How does the program handle conversions when velocities approach ?
• Are there ambiguities or contradictions when interpreting quantities that are traditionally distinct (like time and space)?

4. Extending the Program

Integrating relativistic effects (like Lorentz transformations) into the units program would be a significant enhancement. Some ideas for implementation:
• New Units: Introduce units for relative velocity () and the Lorentz factor ().
• Frame-Specific Conversions: Allow users to specify a frame of reference (e.g., via a frame command) and perform conversions accordingly.
• Documentation: Provide examples demonstrating how to use these features for common relativistic scenarios.

5. A Philosophical Note

Your redefinition highlights an essential philosophical point about units: they’re human conventions reflecting our understanding of reality. By redefining time as distance and eliminating the distinctiveness of , you’re aligning with a deeper, relativistic view of spacetime. This redefinition challenges conventional assumptions but is fully consistent with the laws of physics.

6. How Hard Could It Be?

Building Lorentz transformations into units would likely require substantial reworking of its core logic, as the program currently assumes additive and multiplicative conversions. Lorentz transformations introduce a dependence on the relative velocity and require non-linear transformations. It would likely involve:
• Adding new rules to handle velocity-dependent transformations.
• Modifying the parser to understand and apply these rules.
• Ensuring that existing functionality remains unaffected for non-relativistic use cases.

That said, with a clear plan and careful coding, it’s entirely achievable.

Would you like to dive deeper into any specific part of this, such as designing the Lorentz transformation logic or exploring edge cases for testing?