polygon from 2 size tuple points

[joamatab]

Using the python API

how can we get Polygon without having to convert to a klayout polygon?

ideally we can go from np.array without calling kdb.Point

@amccaugh
@sebastian-goeldi

[amccaugh]

This would be nice. Right now creating a basic polygon with N points requires crossing the Python<->C++ interface N times, as you need to call kdb.Point() once per point.

poly1 = kdb.DPolygon(
    [
        kdb.DPoint(-8, -6),
        kdb.DPoint(6, 8),
        kdb.DPoint(7, 17),
        kdb.DPoint(9, 5),
    ]
)

It's not the worst thing in the world, but I suspect it would be much faster (and cleaner-looking) if you were able to pass a whole array of points, once, to the C++ code and allow it to construct the polygon for you. Not sure if this is easy or annoying to do on the C++ side, though.

%timeit [kdb.Point(n,n) for n in range(1000000)]
407 ms ± 14.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

[klayoutmatthias]

Hi @amccaugh

I don't understand the comment about passing an array directly - you are already passing an array and it is already read out in C++. But creation involves creating Point objects.

Supporting numpy datatypes directly means linking against numpy. That's something that I won't do, mainly because of license conflicts, ABI dependencies and general portability.

Allowing size-2 tuples for (x,y) instead of DPoint/Point is an option. From the Python side that brings about a 7x speed improvement being an internal type.

Matthias

[amccaugh]

Yes, I mostly meant skipping the intermediate step of having Python call kdb.Point repeatedly, and instead passing raw coordinate values directly to Polygon:

poly1 = kdb.DPolygon(
    [
        (-8, -6),
        (6, 8),
        (7, 17),
        (9, 5),
    ]
)

where the values could be converted to Points internally, with the benefit that the Point creation process would happen entirely within C++, reducing the number of slow Python calls to klayout. Honestly it's really not that much of a gain of speed though, so it's not clear this is worth the effort. It's good to know about numpy, that would be one area where it would likely be much faster -- in some instances passing an entire numpy array would be substantially faster than breaking the numpy array into a zillion individual kdb.Point calls

[klayoutmatthias]

@amccaugh That's what I meant by size-2 tuples.

Sure, numpy arrays would be much faster, but there is no way I would enter this maintenance nightmare.

Matthias

[sebastian-goeldi]

I think there are two options:

The 2D list (or if much easier to implement 1D list, very easy both in python lists and numpy to flatten it) is a good compromise.

Another option I see for numpy which avoids needlessly going to a python list, is to basically pass it as a bytes object: https://numpy.org/doc/stable/reference/generated/numpy.ndarray.tobytes.html

Basically, you could then just cast it to a vector in c++ (this would of course require dtype=int for Polygon and dtype=float for DPolygon)