You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 9, 2024. It is now read-only.
When using gds_read, I found that the polygons are represented as numpy.ndarray of dtype('O'), i.e. object, not, say float or 'float64'.
For feeding the polygons to programs downstream, sometimes this matters, sometimes not. For example matplotlib and FreeCAD recognize the coordinates as numbers but PyGmsh doesn't.
To demonstrate, take any gds, say tutorial.gds from here, and
gds = GdsLibrary()
gds.read_gds(argv[1])
for layer, v in gds.top_level()[0].get_polygons(True).iteritems():
print(layer, map(lambda p: (p.shape, p.dtype), v))
The workaround is trivial of course, just p.astype(float) (as in Polygon.fillet) or np.asarray(p, dtype=float) if a function is preferred to a method, but I was curious as to why the coordinates weren't numeric in the first place.
The text was updated successfully, but these errors were encountered:
When using
gds_read
, I found that the polygons are represented asnumpy.ndarray
ofdtype('O')
, i.e.object
, not, sayfloat
or 'float64'.For feeding the polygons to programs downstream, sometimes this matters, sometimes not. For example matplotlib and FreeCAD recognize the coordinates as numbers but PyGmsh doesn't.
To demonstrate, take any gds, say tutorial.gds from here, and
The workaround is trivial of course, just
p.astype(float)
(as inPolygon.fillet
) ornp.asarray(p, dtype=float)
if a function is preferred to a method, but I was curious as to why the coordinates weren't numeric in the first place.The text was updated successfully, but these errors were encountered: