Является ли концепция класса Point3, отдельной от класса Vec3, непитонической?

Question

Я пишу несколько трехмерных математических классов для Python. Я хотел бы создать класс Point3, отдельный от Vec3, в следующих отношениях:

Point3 - Point3 = Vec3
Point3 + Vec3 = Point3

В противном случае все операции на Vec3 вы можете выполнять на Point3. Мотивация для этого состоит в том, чтобы отделить математическую концепцию точки от вектора, что, как мы надеемся, приведет к более четкому разделению типов и более простому для понимания API.

Однако, учитывая типизацию Python по утке и общепринятую практику ожидания определенного интерфейса независимо от типа, лучше ли просто использовать Vec3? Это более эффективно?

Answer 1

Кажется излишним.Если вы думаете об этом, точка в декартовом пространстве полностью эквивалентна связанному вектору, который начинается в начале координат.Похоже, вы могли бы делать много работы для себя даром.

Answer 2

Я не думаю, что это особенно нелепо. Нет ничего необычного в том, чтобы различать типы, когда они имеют один и тот же домен, но когда у них есть определенная система отсчета, такая как часовой пояс, поскольку точка представляет собой сумму вектора и источника, разумно кодировать это в некоторых путь.

Answer 3

Да, это плохой дизайн, поскольку сложение или вычитание двух точек не имеет концептуального значения.

Однако можно добавить вектор к точке (получение точки) или добавить два вектора (получениевектор), поэтому звучит так, будто вы просто путаете точки с векторами.

Точка не является вектором, но ее можно реализовать в единицах.В программировании мы моделируем отношения «реализовано в терминах» с использованием композиции - класс Point будет содержать один частный экземпляр Vector и использовать его для обработки логики любых методов, которые он использует.

На самом деле, поскольку Vector уже может делать все то же самое, что может Point (плюс еще), вы можете подумать о том, чтобы даже не удосуживаться провести различие и использовать толькоVector класс, без Point класса вообще.Является ли это хорошей идеей, зависит от того, для чего будет использоваться ваш API.

Answer 4

Я понимаю ваш аргумент. Я тоже всегда боролся с классами за очки. По моему опыту, лучше (хотя я полагаю, возможно, не «более питоническим») выбрать более функциональный подход и написать свой API с точки зрения функций, которые принимают списки / кортежи.

Основное возражение против этого, я думаю, заключается в том, что вам, вероятно, нужен компактный способ написания простых алгебраических операций (суммы и т. Д. ), но для этого я бы предложил использовать numpy. Numpy не только поддерживает поэлементное добавление, но и дает вам эффективность там, где она может понадобиться в будущем, с матричными операциями и т. П.

В то же время, хотя вы говорите, что хотите получить чистый API, различия, которые вы добавляете в API, будут невидимы, кроме как в документации. И действительно, невидимый API не так уж полезен.

Я знаю, что это не то, о чем вы изначально просили, но я подозреваю, что это лучший дизайн в долгосрочной перспективе ( т.е. по мере роста вашей библиотеки, и вы хотите поддерживать более амбициозные преобразования точек, пакетная обработка, и т. д. , и т. д. ).