›

Can we have a DRegion class and a array DPolygon to Polygon constructor?

BigPandaBigPanda
edited May 15 in Ruby Scripting

Sorry for this discussion, I choose the wrong tag.

Recently, I am working with pya Module, and I find that it has Path, DPath, Box, DBox classes and so on, all of them are appeared in pairs. But it seems that there is no DRegion class. We can see from this dicussion If we want to merge two polygons created by DPolygon constructor, it is not convenient because we need to transfer DPolygon to Polygon. If we want to transfer between them, normally we need to manually do unit conversion. Besides, as @sekigawa said, it seems that there is no constructor to transfer array[] DPolygon to array[] Polygon, which is also not convenient.

If we can have DRegion class, then there is another question, we know float and integer can be converted to each other. Why not combine Box and DBox classes, the other pairs are same. If this is possible, programming could be much easier I think.

Comments

  • tomas2004tomas2004

    Hello,

    Check this: https://www.klayout.de/forum/discussion/2339/region#latest

    Cheers,

    Tomas

  • BigPandaBigPanda

    @tomas2004 hhh, I am glad that we have same thought. As an old saying goes, people always think alike!

    I have checked that discussion. But I do not think that is a good reason for suppporting no DRegion class. Such as we have Polygon and DPolygon, we only need one sentence to tranfer between them rather than several sentences.

    Besides, as I say above, If we have DRegion class, we could make them in pairs. And the next step is that maybe we could combine them into one. And in my mind, I also think DRegion contains Region and DBox contains Box and so on.

  • MatthiasMatthias

    Hi @BigPanda,

    the "D" types are not extensions of the "non-D" types, but different flavors. By convention, the "D" types carry coordinates in micrometer units, while the "non-D" types carry coordinates in integers, as multiples of some database unit.

    "D" types are converted into integer-unit objects when you insert them into the database or pull them from the database using the specific methods. But they are second-class citizens - they are only transformed versions of integer-unit objects.

    Mixing "D" and "non-D" objects creates a risk of unintended rounding. If you do so, make sure you apply a proper scaling, for example using "CplxTrans(dbu)" for converting "non-D" to "D" and the inverse to convert "D" to "non-D".

    The vast majority of the algorithms work on integer-unit objects only. As the "Region" object is essentially a wrapper around polygon algorithms, there is no specific "DRegion". It is possible to implement "DRegion" if you give it some database unit attribute. However, that means a huge number of conversion wrappers around the manifold access methods. In addition, there are also "Texts", "Edges" and "EdgePairs" that deserve to receive the same attention. That creates a huge maintenance effort and currently my priorities are elsewhere.

    In the end, the "non-D" objects are the "real" objects, while the "D" ones are essentially convenience types. My advice is to work with "non-D" objects as far as possible. The come with less side effects, better algorithmic support and are more stable. The "D" objects play a role for user interfaces for example, where input values are more conveniently given in micrometer units.

    Regards,

    Matthias

  • BigPandaBigPanda

    Thank you for your detailed reply. This is definitely a good reason. And I really hope one day in the future, the D type can also be stable enough. :smile:

  • MatthiasMatthias

    You're welcome. But floating-point implementations of the geometry algorithms will not become available.

    Matthias

Sign In or Register to comment.
Powered by Vanilla