Coercion of geometric elements in Lists does not work as expected

[kortenkamp]

If you have a list of geometric elements, say, points [A,B,C,D], then you cannot rely on coercion to create coordinates of these. In Cinderella, sum([A,B,C,D])/4 would be the center of gravity of those points, as this expression is equivalent to sum([A.xy,B.xy,C.xy,D.xy])/4.

[gagern]

For this specific situation we need a few more evaluateAndVal calls here. But there are likely other source locations affected in a similar manner.

I'm removing the incompatible label since I don't see this as a bug which will introduce an incompatibility. I just started a wiki page describing labels, and I'll likely trigger an email discussion about that as well.

[strobelm]

Probably it's better to adjust General.add/mult to deal with geoOps
since it's called anyway (and for sure used on other occasions).

On 10/08/2016 09:34 PM, Martin von Gagern wrote:

For this specific situation we need a few more |evaluateAndVal| calls
here
https://github.com/CindyJS/CindyJS/blob/v0.8.1/src/js/libcs/Operators.js#L886-L888.
But there are likely other source locations affected in a similar manner.

I'm removing the /incompatible/ label since I don't see this as a bug
which will introduce an incompatibility. I just started a wiki page
describing labels https://github.com/CindyJS/CindyJS/wiki/Labels, and
I'll likely trigger an email discussion about that as well.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#508 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANhz4oIS9IEyIfcGnU2O8gwcWs151raCks5qx_A8gaJpZM4KRqYL.

Michael Strobel, M.Sc.

Technische Universität München -- Zentrum Mathematik
Lehrstuhl für Geometrie und Visualisierung (M10)
Boltzmannstr. 3, 85747 Garching bei München
https://www-m10.ma.tum.de/bin/view/Lehrstuhl/MichaelStrobel

[strobelm]

I just quickly hacked something: strobelm@0979eee

Any concerns about that? What else do we want to add?

[gagern]

Probably it's better to adjust General.add/mult to deal with geoOps since it's called anyway

I'm not convinced this is a good idea. On the one hand I'd prefer to move most of the type conversion out of the functions for our own data structures and into our operator implementations. On the other hand the General module is mostly about delegation based on type. Particularly seeing how that would make min([[A,B,B], [A,A,B]]) work (as it does in Cinderella) while my approach could not make it work.

Any concerns about that?

This doesn't allow for combinations of lists and geometric elements. I think you should have two steps: one turning geo values into list values, considering each argument alone, and another doing the dispatch based on both types together.

What else do we want to add?

• General.min and General.max.
• The type-based dispatch in List.add, which probably should go back to General.add unconditionally in order to allow consistent handling of nested lists.
• I think we should support situations where the first element is a

product is a strange beast in this respect: The product of two points is the scalar product. Add a third point and you scale it by the scalar product of the first two. Add another point and you get the product of the scalar products, and so on. At least in Cinderella. Probably of little practical use, but we should be able to implement this since it's what you get from A*B*C*….