Часть Фортуны

От κλῆρος τύχης к Pars Fortunae: техника старше названия «арабская часть»

Жребий Фортуны надёжно засвидетельствован в греко-язычной эллинистической астрологии задолго до средневековой арабской традиции. Доротей Сидонский в Carmen Astrologicum передаёт sect-sensitive расчёт, Птолемей обсуждает Fortune в Tetrabiblos, а Веттий Валент делает эту точку опорой для производных мест и временных техник. Поэтому выражение «арабская часть» описывает важный этап передачи и развития корпуса, но не означает арабское изобретение самого Fortune.

Само словоупотребление показывает историю передачи. Греческое `klēros` означает жребий или доставшуюся долю; в арабо-персидской астрологической литературе семейство таких точек значительно расширилось, а в латинской традиции закрепилось `pars`, «часть». Отсюда современное соседство терминов Lot of Fortune, Part of Fortune, Pars Fortunae и русских «Жребий/Парс/Часть Фортуны».

Источники расходятся уже на базовом уровне формулы. Доротей и большая часть sect-sensitive эллинистической линии меняют направление между светилами ночью. Сохранившийся текст Птолемея, напротив, прямо говорит брать расстояние от Солнца к Луне одинаково и для дневных, и для ночных рождений, чтобы Fortune стала своего рода «лунным гороскопом». Это не современная ошибка калькуляторов, а реальное историческое разветвление.

В поздней традиции Fortune пережила многие другие lots и сохранилась в европейской астрологии, а в конце XX века переводческий проект Project Hindsight и возрождение эллинистических методов вернули широкое внимание к sect reversal, Lot of Spirit, Fortune-derived places и zodiacal releasing. Современная практика поэтому одновременно наследует несколько исторических слоёв, и хороший software обязан назвать свой вариант вместо слова «правильно» без оговорок.

Что это вообще такое: координата, созданная из трёх уже известных точек

Часть Фортуны не имеет массы, орбиты, светимости или собственного движения. Её нельзя запросить как Sun, Moon или Chiron. Сначала карта должна знать Ascendant, Sun longitude и Moon longitude; затем алгоритм комбинирует эти значения по объявленной формуле и получает новую эклиптическую долготу от 0° до 360°.

Это делает Fortune математически точной при точных входах, но не физическим объектом. Слово «точка» здесь означает координату на зодиакальном круге. Точность арифметики также не доказывает исторические астрологические значения этой координаты — вычисление и интерпретация остаются разными слоями.

Формулу легче понять как перенос дуги, а не как сложение символов

Запись `Asc + Moon − Sun` часто выглядит произвольной. Геометрически она означает другое: найдите направленную дугу от Sun к Moon и отложите ту же величину от Ascendant. После переноса endpoint и есть Fortune. Поэтому выражение `Moon − Sun` — не психологическое вычитание Солнца из Луны, а обычная круговая разность долготы.

Эта модель даёт простую контрольную проверку. Для дневной или птолемеевской non-reversed формулы должно выполняться `norm360(Fortune − Asc) = norm360(Moon − Sun)`. Для sect-reversed ночной версии справа стоит `norm360(Sun − Moon)`. Если equality нарушено, ошибка находится уже в арифметике или нормализации, а не в астрологической школе.

Две главные conventions: sect reversal и правило Птолемея

В широко используемой эллинистически ориентированной convention карта сначала классифицируется как дневная или ночная. Для дня берут `F = norm360(A + M − S)`; для ночи порядок светил меняют: `F = norm360(A + S − M)`. Это соответствует инструкции, засвидетельствованной у Доротея и развитой в большой части поздней традиции lots.

Птолемей представляет реальную альтернативу. В Tetrabiblos он говорит измерять от Sun к Moon и днём, и ночью. Современный редактор поэтому не должен прятать разницу под словами «классическая формула». Нужно хранить хотя бы поле `formulaConvention`, иначе одинаковый UI-label Part of Fortune способен обозначать разные градусы.

Почему две ночные формулы могут увести точку далеко: это зеркальная геометрия

Пусть `F1 = A + M − S`, а `F2 = A + S − M`. Тогда `F2 = 2A − F1` по модулю 360°. То есть два результата отражены относительно диаметра Ascendant–Descendant. Они не являются случайно разными числами: это два противоположных направления одной и той же Sun–Moon дуги, отложенные из одной точки A.

Отсюда объясняется пользовательский опыт, когда один сервис показывает Fortune, например, в одном секторе карты, а другой — в совершенно другой части. Разница способна быть большой и не сводится к округлению. Первое, что нужно сравнить, — night formula, а не выбирать результат по тому, какой знак больше «похож на человека».

Пример в абсолютных долготах: один набор входов, две допустимые conventions

Возьмём только математический пример: Ascendant `287°`, Sun `142°`, Moon `18°`. Для фиксированной Sun→Moon формулы получаем `287 + 18 − 142 = 163°`, то есть 13° Virgo. Для обращённой версии получаем `287 + 142 − 18 = 411°`; после `norm360` остаётся `51°`, то есть 21° Taurus.

Проверка показывает структуру. `2 × 287 − 163 = 411`, а `411 mod 360 = 51`. Значит, точки действительно являются зеркальными решениями относительно ASC/DSC. Такой пример полезнее запоминания знаков: он позволяет отладить calculator независимо от интерпретации.

Нормализация 0–360° — часть алгоритма, а не косметика

Складывать `15° Taurus + 8° Pisces − 22° Leo` напрямую по градусам внутри знаков нельзя. Сначала каждая позиция переводится в absolute longitude от 0° Aries: Taurus начинается с 30°, Leo с 120°, Pisces с 330°. Только затем выполняется арифметика.

Результат нормализуется функцией вроде `((x % 360) + 360) % 360`. Это важно и для отрицательных значений, и для сумм больше 360°. Ошибка circular wrap может отправить корректную Fortune в несуществующий отрицательный градус или в число за пределами zodiac.

Если формула обращается по секте, сначала нужно честно решить: Sun над горизонтом или под ним

Sect — не бытовая метка «родился утром/вечером» и не номер календарного часа. Для этой задачи важно геометрическое положение Sun относительно локальной линии горизонта. При sect-sensitive formula именно этот classification bit меняет направление дуги между светилами.

Whole Sign house number сам по себе не заменяет horizon test. Sun может находиться в знаке, который считается одним whole-sign place, но day/night определяется реальным местным горизонтом. Надёжная программа либо вычисляет solar altitude/отношение к ASC–DSC axis, либо явно показывает метод классификации.

Рождение у восхода или заката — самый опасный edge case

В обычной точке времени небольшая ошибка birth time плавно смещает Ascendant и Moon. Рядом с горизонтом появляется ещё один эффект: несколько минут способны перевести Sun из nocturnal в diurnal classification или обратно. В sect-reversed implementation тогда меняется не только вход A, но и сама формула.

Получается настоящая алгоритмическая discontinuity: две близкие версии времени рождения могут дать зеркально разные Fortune. В пограничных картах software должен показывать uncertainty window и критерий горизонта, а не прятать решение за округлённой надписью «день» или «ночь».

Без времени рождения Fortune нельзя восстановить так же уверенно, как медленную планету

Ascendant способен пройти заметную дугу за часы, причём скорость зависит от широты, даты и rising sign. Moon добавляет собственное движение примерно порядка половины градуса в час. Поэтому неизвестные часы входят в формулу дважды: через local horizon и через положение Луны, а в sect-sensitive модели ещё и через выбор ветви day/night.

Полуденный fallback может быть технически удобен для построения приблизительной карты, но Part of Fortune из такого Ascendant остаётся гипотетическим. Если известен временной интервал рождения, корректнее вычислить диапазон возможных Fortune coordinates и отметить возможный sect flip, чем печатать один точный градус.

Место рождения нужно не для «энергии города», а для горизонта и корректного UTC

Sun и Moon в стандартной geocentric натальной карте определяются моментом UTC. Ascendant, напротив, является локальной геометрической точкой и требует latitude/longitude. Поэтому тот же UTC с другим местом даст другой Ascendant и вслед за ним другую Fortune.

Исторический timezone — отдельная задача. Ошибка в часовом поясе сначала сдвигает сам момент, затем Sun/Moon и local sidereal geometry. Для старых дат недостаточно сегодняшнего UTC offset города: нужен offset, действовавший в конкретную дату.

Geocentric и topocentric Moon — ещё одна независимая software convention

Стандартные западные натальные расчёты обычно используют geocentric longitudes светил. Но Swiss Ephemeris позволяет включить `SEFLG_TOPOCTR`, и для Moon разница между геоцентрическим и топоцентрическим положением способна превышать один градус из-за параллакса. Поскольку Moon входит в Fortune со знаком `+` или `−`, это расхождение почти напрямую переносится в итоговый Lot.

Эту настройку нельзя смешивать с house system или sect. Два калькулятора могут одинаково определять day/night и использовать одну formula convention, но всё равно дать различающиеся degrees, если один подставляет topocentric Moon. В актуальном ПУТИ `swe.calc_ut` вызывается с `SEFLG_SPEED` без `SEFLG_TOPOCTR`, поэтому текущие Sun/Moon inputs — geocentric.

Placidus и Whole Sign могут дать разные дома при одном и том же градусе Fortune

Сама формула использует реальный Ascendant degree, Sun и Moon. Выбор Placidus, Regiomontanus или Whole Sign не должен менять эту longitude, если zodiac reference и исходный Ascendant одинаковы. House system вступает в работу после расчёта, когда готовый градус классифицируют по домам.

Поэтому расхождение нужно диагностировать по типу. Если программы показывают разные degrees — ищите formula convention, birth data, zodiac или Ascendant. Если degree совпадает, а house number нет — это уже house-system question. Смешивать эти два класса ошибок особенно легко в мобильных калькуляторах, которые показывают только знак и дом без absolute degree.

Tropical и sidereal сдвигают Fortune вместе со всем согласованным зодиаком

Пусть все три входа переводятся в другой zodiac reference одним и тем же offset `k`: `A' = A − k`, `M' = M − k`, `S' = S − k`. Тогда `F' = A' + M' − S' = F − k`. То есть Part of Fortune сдвигается на тот же ayanamsha, а не получает новую независимую геометрию.

Из-за этого sign label может измениться, тогда как angular relations при согласованном пересчёте сохраняются. Реальная ошибка возникает, если программа смешивает tropical Ascendant с sidereal planets или применяет ayanamsha к результату не тем же способом, что к входам.

Часть Фортуны и Жребий Духа — парная конструкция, но не обязательно оппозиция

В sect-sensitive системе Fortune и Spirit используют одни и те же три точки с обратным порядком светил. Днём Fortune = `A + M − S`, Spirit = `A + S − M`; ночью они меняются ролями. Поэтому две координаты являются зеркальными относительно ASC/DSC, но обычно не стоят ровно в 180° друг от друга.

Оппозиция возникает только при определённых Sun–Moon separations. Называть Spirit «противоположной точкой Fortune» без проверки градусов технически неверно. Их исторические значения тоже различаются: Fortune сильнее связано с телом, обстоятельствами и тем, что выпадает; Spirit — с намерением, действием и деятельностью в ряде эллинистических авторов.

Почему слово «Фортуна» не означает гарантированную удачу, деньги или выигрыш

Греческая `Tyche` и идея жребия ближе к уделу, случаю и тому, что человеку достаётся, чем к современному рекламному слову «везение». Птолемей использует Lot of Fortune в обсуждении material acquisitions; Валент связывает Fortune с телом, физическими делами и обстоятельствами. Это исторически более широкий и менее сахарный диапазон, чем «место, где деньги приходят легко».

Поэтому одна Fortune в II доме не гарантирует богатство, а положение в VIII не является приговором потерь. Традиционное суждение смотрит на знак, ruler, его condition, witnesses и более широкий natal context. Современная позитивная метафора может быть выбрана как школа, но её нельзя выдавать за буквальный перевод древнего термина.

В традиционном чтении важен управитель знака Fortune, а не только подпись «Fortune в Рыбах»

Когда Lot попадает в знак, традиционный workflow сразу спрашивает, какая планета владеет этим знаком и в каком состоянии она находится. Ptolemy в разделе о материальных приобретениях прямо предлагает исследовать lordship знака Fortune и планеты, связанные с ним. Valens также уделяет большое внимание ruler of the Lot.

Это означает, что знак — не готовая трактовка. Например, одинаковый Lot в Pisces может получать очень разный традиционный контекст в зависимости от Jupiter: его места, sect condition, аспектов и других dignity/debility factors выбранной школы.

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

Эллинистические и средневековые техники Fortune создавались в системе семи видимых планет. Поэтому Scorpio относится к Mars, Aquarius к Saturn, Pisces к Jupiter. Если calculator после корректного древнего Lot автоматически назначает Pluto, Uranus или Neptune как единственного ruler, он уже перешёл в современную hybrid convention.

Гибрид допустим как осознанный эксперимент, но должен быть назван. Для воспроизводимого software полезно хранить `rulershipProfile` отдельно от `lotFormulaProfile`: выбор дневной/ночной формулы и выбор modern/traditional rulers — две независимые настройки.

Аспект к Fortune — измеримая дуга; универсального орбиса Fortune не существует

После получения longitude можно вычислить кратчайшее угловое расстояние от Fortune до любой планеты или угла. Геометрически conjunction, square или trine определяются так же, как для других zodiacal points. Но max orb — уже правило школы или программы, а не физическое свойство Lot.

В традиционных текстах часто удобнее говорить, что планета свидетельствует или аспектирует Fortune, потому что Lot сам не является звездой с лучами и не имеет собственной скорости. Современный chart renderer может рисовать линию симметрично; это UI convention, а не доказательство, что древняя doctrine считала все направления эквивалентными.

У Валента Fortune может стать производным «Асцендентом» — но это не второй физический горизонт

Веттий Валент иногда берёт знак Fortune как начало нового набора двенадцати places: сам Lot соответствует первому месту, десятое от него — теме rank, седьмое и четвёртое образуют производные углы. Это одна из причин, почему Fortune в эллинистической практике было гораздо важнее современного маленького значка в таблице.

Такой derived frame не создаёт новый local horizon и не меняет реальный ASC/MC. Это тематическая система отсчёта, построенная от calculated lot. Её нужно отличать и от quadrant houses, и от обычных Whole Sign houses от rising sign.

Zodiacal releasing может начинаться от Fortune, но не является частью её формулы

В позднеэллинистической практике Fortune служит стартовой точкой для временных методов, особенно в корпусе Валента. Zodiacal releasing from Fortune строит последовательность периодов по знакам и planetary period lengths. Это отдельный timing algorithm, которому сначала нужен корректно рассчитанный natal lot.

Glossary не должен превращать определение Fortune в полный учебник zodiacal releasing. Для текущего термина достаточно границы: ошибка formula convention переносится во весь downstream timeline, потому что меняется стартовый знак. Поэтому software должен версионировать исходный Lot вместе с результатами timing technique.

Натальная Fortune не «едет» по карте: moving Fortune — новый расчёт для нового момента

Натальный Lot фиксируется один раз из natal Ascendant, Sun и Moon. Если приложение показывает «транзитную Часть Фортуны», оно обычно заново вычисляет формулу из текущих Sun, Moon и текущего локального Ascendant. Это новый derived point времени `t`, а не физическое перемещение natal Fortune.

Из-за быстро меняющегося Ascendant такой moving lot крайне чувствителен к месту наблюдения и времени; при sect reversal около sunrise/sunset ещё и возможен formula flip. Поэтому пользователь должен видеть, что именно сравнивается: transit planets → natal Fortune или moving Fortune(t) → natal factors. Это разные задачи.

Почему два калькулятора показывают разные Part of Fortune

На практике причины удобно проверять по порядку. Самая крупная — fixed Sun→Moon против sect-reversed night formula. Затем birth time/timezone/location, потому что они меняют Ascendant и иногда day/night branch. Следом tropical/sidereal reference, разные rounding rules и ошибки ручного перевода знаков в absolute longitude.

House system стоит проверять отдельно: он обычно объясняет другой номер дома при том же Fortune degree, а не другой градус. Astrodienst прямо сообщает, что использует разные day/night formulas по умолчанию и позволяет изменить правило в extended chart selection — хороший пример того, как software может честно раскрыть competing convention вместо скрытого выбора.

• Сверить точные birth date, time, timezone и coordinates.
• Сверить tropical/sidereal zodiac.
• Определить, day chart или night chart по локальному горизонту.
• Спросить, обращается ли formula ночью или остаётся Sun→Moon.
• Сравнить absolute Fortune degree до чтения дома.
• Только затем сравнить house system и интерпретацию.

Какой computational contract нужен хорошему Lot of Fortune engine

Надёжный результат должен быть воспроизводим. Для этого мало сохранить `fortuneLongitude`. Нужны input timestamp UTC, latitude/longitude, zodiac reference, Ascendant algorithm, sect classification method, `formulaConvention`, исходные Sun/Moon/Asc longitudes, нормализованный result и house system для house assignment.

Для исторически ориентированного чтения добавляются `rulershipProfile` и aspect/orb policy. Если сервис строит Fortune-derived places или zodiacal releasing, они должны ссылаться на тот же Lot calculation version. Иначе смена одной настройки тихо меняет downstream interpretation, а пользователь не понимает, почему архивный отчёт больше не совпадает с новым.

Production ПУТИ уже имеет исходные координаты, но Fortune пока не рассчитывает

Актуальный `generate-natal/engine/astrology-engine.ts` вычисляет tropical geocentric Sun и Moon через `swe.calc_ut(..., SEFLG_SPEED)`, без `SEFLG_TOPOCTR`; Placidus houses и Ascendant приходят из `swe.houses`. Значит, три базовых операнда для geocentric Fortune технически уже присутствуют в runtime.

Но отдельного `partOfFortune`, `lotOfFortune`, formula branch или sect classifier в production-коде нет. `NatalStructure` не содержит Fortune, natal aspects не включают её, transit engine не использует natal Fortune, Fortune-derived houses и zodiacal releasing также не реализованы. При отсутствии coordinates production может подставить Moscow, при ошибке timezone resolver — UTC+3, а при неизвестном time — `12:00`; для будущего Fortune эти fallback должны считаться uncertainty, а не точными входами.

Будущая реализация ПУТИ потребует отдельного traditional rulership profile

Текущий production `SIGN_RULERS` использует modern rulers: Scorpio → Pluto, Aquarius → Uranus, Pisces → Neptune. Для многих современных функций продукта это допустимая convention, но классическое чтение Lot of Fortune исторически опирается на seven-planet domicile system: Mars, Saturn и Jupiter соответственно.

Поэтому нельзя просто добавить formula и затем передать sign Fortune в существующий ruler lookup, если продукт хочет заявлять традиционный метод. Нужно либо создать отдельную таблицу traditional rulers, либо честно назвать результат modern-hybrid reading. Это реальный software boundary, а не стилистический выбор статьи.

Полуденный fallback ПУТИ нельзя автоматически превращать в точную Часть Фортуны

Если birthTime отсутствует, production natal engine ПУТИ ставит `localHour = 12`. Такой placeholder может быть приемлем для некоторых медленных объектов, но для Fortune он создаёт искусственный Ascendant и может даже назначить неверную sect branch относительно реального рождения.

Поэтому будущая реализация должна либо требовать известное время, либо возвращать uncertainty/range mode. Показывать пользователю точный градус Fortune из полуденного placeholder без маркировки означало бы выдавать системное предположение за измеренный вход.

Что здесь вычисляется объективно, а что остаётся астрологической традицией

При заданных birth data и formula convention арифметика Fortune воспроизводима: можно проверить Ascendant, longitudes Sun/Moon, направленную дугу, modulo 360 и итоговый degree. Исторический факт о том, какие авторы использовали какие формулы, тоже можно исследовать по текстам.

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

Рабочий порядок чтения: сначала версия расчёта, затем контекст

Для практической карты полезно идти в фиксированном порядке: проверить birth data; назвать zodiac reference; определить sect и formula convention; вычислить exact Fortune degree; только после этого установить sign и house. Затем выбрать ruler profile, оценить ruler и relevant witnesses/aspects и, если школа это использует, Fortune-derived places или timing methods.

Такой порядок защищает от самой распространённой логической ошибки: сначала прочитать красивое описание «Fortune в X доме», а потом обнаружить, что другой калькулятор по другой формуле помещает точку на десятки градусов дальше. Интерпретация начинается после воспроизводимого расчёта, а не вместо него.

Главная граница термина

Часть Фортуны — это вычисленный способ перенести отношение двух светил в координатную систему, привязанную к Асценденту. Она может быть важным узлом традиционной карты, но не является планетой, физической силой, автоматически счастливым домом или гарантией материального результата.

Если запомнить одну вещь, пусть это будет directed arc. Тогда становится понятно, зачем нужен Ascendant, почему без времени рождения расчёт слаб, откуда берутся две ночные formulas, почему Ptolemy и sect-reversed lineage дают разные answers и почему качественный software обязан показывать convention рядом с градусом.