enkimute / ganja.js

:triangular_ruler: Javascript Geometric Algebra Generator for Javascript, c++, c#, rust, python. (with operator overloading and algebraic literals) -
MIT License
1.52k stars 107 forks source link

Length Metric Problem at Observable. #131

Closed jahbini closed 3 years ago

jahbini commented 3 years ago

My notebook has problems: https://observablehq.com/@jahbini/3d-pga-length-quandry

The Length of "seemingly equal" line segments is way off as documented at that notebook.

Clearly, I have shot myself in the foot... Somehow.

Any assistance?

enkimute commented 3 years ago

When using a line to measure the distance between two points, first make sure both points are normalized.

https://observablehq.com/d/3cf610cadae3e02e

btw, you may also like:

https://enkimute.github.io/ganja.js/examples/coffeeshop.html#EOzkYY3hj

Cheers,

jahbini commented 3 years ago

Thanks! Straight forward explanation. Q: do 'all' derived points need normalizing before they behave nicely in the system? Or is Length the only problem? So much to learn.

As for https://enkimute.github.io/ganja.js/examples/coffeeshop.html#EOzkYY3hj -- It is the Pristine Chapel of Sacred Geometry. And you can tell 'em I Said So.

enkimute commented 3 years ago

Well the metric relations often assume normalized elements. (distances and angles) - For incidence (lies on, intersections, ..) it makes no difference. In practice I normalize only when I'm doing explicit metric calculations.

For some applications it may be useful to represent mass or energy using that homogeneous scale - it works out nicely when using e.g. PGA lines to represent forces or momentum lines.

Cheers,

S.

skydog23 commented 3 years ago

Might it make sense to introduce two versions of the metric formulas, one for normalized arguments (it seems the current versions behave this way) and a second more general version that normalizes all arguments? Developers could use the general form for prototyping and then specialize to the normalized-argument form after they get things working and care about speed.

On Fri, Aug 20, 2021 at 12:32 PM Steven De Keninck @.***> wrote:

Well the metric relations often assume normalized elements. (distances and angles) - For incidence (lies on, intersections, ..) it makes no difference. In practice I normalize only when I'm doing explicit metric calculations.

For some applications it may be useful to represent mass or energy using that homogeneous scale - it works out nicely when using e.g. PGA lines to represent forces or momentum lines.

Cheers,

S.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/enkimute/ganja.js/issues/131#issuecomment-902599053, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD7F3I7GJ3QMM3WW3ZHPTBTT5YVK7ANCNFSM5CNKEX4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

jahbini commented 3 years ago

Is there a reason that metric operations (distances and angles) should NOT always coerce their arguments into normalized entities?

Contrarywise, would it be reasonable to add a boolean attribute normalized that can be set on an Elementto indicate that metric operations can check before automatically normalizing?

Either way, the opportunity for errors like mine might go away, making me look better in the eyes of my boss.