Not working as expected

Hey all

Having a problem with a what i thought would be simple definition.

My logic is most likely wrong here and there may be a better way of achieving this but this is what i have: Definition = Window Orientation(t) - Example Project file = Window Orientation Example

I am looking to set the facing orientation of all the windows in a project (a lot of projects i get i have to go through this process manually, its quite annoying.) I thought i could simply get the facing orientation of a window I know to be correct, and check it against the list of ALL window orientations, filter out the ones the DO NOT match, and then just Flip them to be correct. It does not seem to be working the way i would expect.

See image below as well as attached definition and an example project file to use it on.

If anyone could explain why it is not working i would appreciate it. (The flip facing node is from clockwork package)

Window facing

Thanks

Just realized i didn’t clarify what is going wrong.

In the above scenario, all windows apart from one are facing internal, so in the watch list after the “equals” node, there should only be one “true” bool but there seem to be a lot more than expected.

Any help/clarification is much appreciated :slight_smile:

Hi Alisder, I made some adjustments to get your script to work. Your main problem was that you were just getting window orientations without taking into account the orientation of the wall hosting them. (dyn file -> Window-Orientationt)window orientation

When comparing floating point geometry, you should really be using the “Vector/Geometry.IsAlmostEqualTo” node to account for the tiny FP variations. Also shouldn’t you first group windows based on their host wall’s orientation? Right now if you flip all the windows in the project, the ones on the opposite wall will be wrong.

Mostafa

Thank you very much. Works as expected now :slight_smile:

Thanks for the clarification both of you. Still learning Dynamo and making daft misjudgments like above xD Seems obvious now i know haha.

Dimitar, do you mind explaining your comment about the node accounting for "tiny FP variations? I’m not sure what this is.

Thanks again for the help guys :slight_smile:

 

Not sure if I’m the best candidate for that, Alisder :slight_smile: Tho here are a few links that will explain the problem much better and in greater detail than I ever could:
http://floating-point-gui.de/formats/fp/

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

Simply put, after a certain decimal point computers need to approximate a number and round it. There’s a couple reasons for that, the main being memory footprint and performance. That, however leads to rounding errors and it’s the reason why you can’t guarantee a fp number’s accuracy after the n-th decimal digit. You can directly observe this in action if you compare the results of the “Equals” node and the “IsAlmostEqualTo” node from your example above:


“Equals” compares the exact numerical values and fails to identify the vector’s similarity even if they’re only infinitesimally different. “IsAlmostEqualTo” measures the difference and then compares that to an accepted tolerance value. If the difference is less than the tolerance, the two vectors are accepted to be equal. You can already find a few more discussions on this topic on the forum: http://dynamobim.org/forums/search/floating+point+numbers/

Dimitar

Thanks very much for the explanation, makes sense now :slight_smile: Still have a lot to learn but getting there!

Appreciate the help from both of you guys on the definition as well.