Программа AstroZET

Анатолий Зайцев писал(а):А Вы сначала включайте транзит в селекторе, и только затем открывайте окно "Динамика времени".

Сделал как Вы сказали - ВСЁ РАБОТАЕТ КАК ШВЕЙЦАРСКИЕ ЧАСЫ. Видать раньше включал я сначала тип карт и ставил галочку транзит, а потом вызывал меню динамика времени и всё работало.
А тут галочку не ставил, динамику времени вызывал, а потом галочку ставил, ну и соответственно программка не работала. Спасибо за ответы разобрался. Дай Вам Бог ЗДОРОВЬЯ И ДОЛГОЛЕТИЯ.

Обнаружил некорректную работу блока "Циклический Индекс", если выходить за рамки набора Юпитер, Сатурн, Уран, Нептун, Плутон.


На этом скрине к стандартному набору добавлен объект - Церера (находится между орбитами Марса и Юпитера) с периодом обращения 4.5 года.


Здесь место Цереры заняла Эрида, дальний медленный объект с периодом обращения немногим более 561 года (т.е. более чем в 2 раза медленнее Плутона).

Но на графике картина получилась абсолютно идентичной, даже мелкие зазубринки кривой лежат на прежних местах. Очевидно, программа не учитывает реальное движение выбранных объектов и под вопросом правильный ли получается график с другими точками (например, с Лунными Узлами) или это другая разновидность случайного "шума".

У меня (при моих настройках) Эрида ведет себя совершенно иначе.



Чтобы получить график идентичный представленному Yura Garaga, мне пришлось деактивировать "лишние объекты" в каталоге астероидов.
Теперь графики совпадают.

Теперь о некорректно работающем блоке "Поиск Собятия", а именно, о неправильно функционирующей опции "Учет часовой поправки".

В качестве теста возмем такие исходные данные:

опорная карта; 1.01.1960; 12:00; +3; Киев, Украина; 50N26; 30E31; —; ;
фоновые данные; 1.04.1980; 12:00; +3; Киев, Украина; 50N26; 30E31; —; ;



Настройки делаем такие (отмечаем "Расчет временной поправки"):



Получим результат-таблицу:

Натал: 1 января 1960 Пт 12:00 (GMT+3)
Интервал поиска: 1.01.2000 - 1.06.2001
Шаг поиска: 3ч 0м 0с
Критерий поиска: Солнце.[0-5].Луна'

Интервалы реализации (начало - конец):
6.01.2000 0:00 (GMT+3) - 6.01.2000 18:00 (GMT+3)
2.02.2000 9:00 (GMT+3) - 3.02.2000 0:00 (GMT+3)
29.02.2000 15:00 (GMT+3) - 1.03.2000 9:00 (GMT+3)
28.03.2000 0:00 (GMT+3) - 28.03.2000 18:00 (GMT+3)
24.04.2000 6:00 (GMT+3) - 25.04.2000 0:00 (GMT+3)
21.05.2000 15:00 (GMT+3) - 22.05.2000 9:00 (GMT+3)
17.06.2000 21:00 (GMT+3) - 18.06.2000 15:00 (GMT+3)
15.07.2000 3:00 (GMT+3) - 15.07.2000 21:00 (GMT+3)
11.08.2000 9:00 (GMT+3) - 12.08.2000 3:00 (GMT+3)
7.09.2000 15:00 (GMT+3) - 8.09.2000 9:00 (GMT+3)
5.10.2000 0:00 (GMT+3) - 5.10.2000 18:00 (GMT+3)
1.11.2000 9:00 (GMT+3) - 2.11.2000 3:00 (GMT+3)
28.11.2000 15:00 (GMT+3) - 29.11.2000 9:00 (GMT+3)
26.12.2000 0:00 (GMT+3) - 26.12.2000 15:00 (GMT+3)
22.01.2001 6:00 (GMT+3) - 23.01.2001 0:00 (GMT+3)
18.02.2001 12:00 (GMT+3) - 19.02.2001 6:00 (GMT+3)
17.03.2001 18:00 (GMT+3) - 18.03.2001 12:00 (GMT+3)
14.04.2001 3:00 (GMT+3) - 14.04.2001 18:00 (GMT+3)
11.05.2001 12:00 (GMT+3) - 12.05.2001 3:00 (GMT+3)

На протяэении 1.5 года поправка все время одна и таже, она равна GMT+3.

Изменим дату в фоновых данных (которая не должна влиять на наш расчет, но, тем не менее влияет!). Запишем вместо 1.04.1980 дату 01.01.1995, как показано на рисунке ниже. Все остальные опции/настройки мы оставляем прежними.


Наша таблица уже будет такой (теперь везде поправка намертво зафиксировалась как GMT+02):

Натал: 1 января 1960 Пт 12:00 (GMT+3)
Интервал поиска: 1.01.2000 - 1.06.2001
Шаг поиска: 3ч 0м 0с
Критерий поиска: Солнце.[0-5].Луна'

Интервалы реализации (начало - конец):
6.01.2000 0:00 (GMT+2) - 6.01.2000 18:00 (GMT+2)
2.02.2000 6:00 (GMT+2) - 3.02.2000 0:00 (GMT+2)
29.02.2000 15:00 (GMT+2) - 1.03.2000 9:00 (GMT+2)
27.03.2000 21:00 (GMT+2) - 28.03.2000 15:00 (GMT+2)
24.04.2000 6:00 (GMT+2) - 25.04.2000 0:00 (GMT+2)
21.05.2000 15:00 (GMT+2) - 22.05.2000 6:00 (GMT+2)
17.06.2000 21:00 (GMT+2) - 18.06.2000 12:00 (GMT+2)
15.07.2000 3:00 (GMT+2) - 15.07.2000 18:00 (GMT+2)
11.08.2000 9:00 (GMT+2) - 12.08.2000 3:00 (GMT+2)
7.09.2000 15:00 (GMT+2) - 8.09.2000 9:00 (GMT+2)
5.10.2000 0:00 (GMT+2) - 5.10.2000 15:00 (GMT+2)
1.11.2000 6:00 (GMT+2) - 2.11.2000 0:00 (GMT+2)
28.11.2000 15:00 (GMT+2) - 29.11.2000 9:00 (GMT+2)
25.12.2000 21:00 (GMT+2) - 26.12.2000 15:00 (GMT+2)
22.01.2001 3:00 (GMT+2) - 22.01.2001 21:00 (GMT+2)
18.02.2001 9:00 (GMT+2) - 19.02.2001 3:00 (GMT+2)
17.03.2001 18:00 (GMT+2) - 18.03.2001 12:00 (GMT+2)
14.04.2001 3:00 (GMT+2) - 14.04.2001 18:00 (GMT+2)
11.05.2001 9:00 (GMT+2) - 12.05.2001 3:00 (GMT+2)

Из-за этого необъяснимого с точки зрения пользователя прыжка вычислений в 1 час (необъяснимого, потому что формально условия расчета мы не изменяли, ведь по-прежнему выполняется поиск для натальной карты 01.01.1960 12:00 на интервале от 01.01.2000 по 01.06.2001 !), мы получим и "прыжки" начала/конца реализации условия, которые превысят 1 час!

Например, было так:
28.03.2000 0:00 (GMT+3) - 28.03.2000 18:00 (GMT+3)

А стало так:
27.03.2000 21:00 (GMT+2) - 28.03.2000 15:00 (GMT+2)
Результат "уплыл" на 3 часа, перескочив с 28 марта 00:00 на 27 марта 21:00, при том, что часовая поправка шалит "всего" на 1 час.
Естественно, если удастся исправить опцию "Расчет временной поправки", тогда пропадут и такие заметные разночтения.

Рассмотрим примеры:
---- 1 --------------------------------------------------------
Поиск натал-транзитного события по времени фоновой на Киев

Натал: 1 января 1960 Пт 12:00 (GMT+3)
Интервал поиска: 28.02.2000 - 30.03.2000
Шаг поиска: 0ч 10м 0с
Критерий поиска:
Солнце.[0-5].Луна'

Интервалы реализации (начало - конец):
29.02.2000 14:50 (GMT+4) - 1.03.2000 11:00 (GMT+4)
27.03.2000 23:00 (GMT+4) - 28.03.2000 19:10 (GMT+4)

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

Опция "Искать по времени фоновых данных" включена.
Опция "Расчёт временной поправки" в транзитном поиске не учитывается и не применяется.
---------------------------------------------------------------

---- 2 --------------------------------------------------------
Поиск того же события, но с фоновой на Чикаго (поправка -6)

Натал: 1 января 1960 Пт 12:00 (GMT+3)
Интервал поиска: 28.02.2000 - 30.03.2000
Шаг поиска: 0ч 10м 0с
Критерий поиска:
Солнце.[0-5].Луна'

Интервалы реализации (начало - конец):
29.02.2000 4:50 (GMT-6) - 1.03.2000 1:00 (GMT-6)
27.03.2000 13:00 (GMT-6) - 28.03.2000 9:10 (GMT-6)

Видим, что время событий по Гринвичу то же, что и в предыдущем случае, например: 23-4 = 13+6
---------------------------------------------------------------

---- 3 --------------------------------------------------------
Поиск натального события на Киев.
Расчёт временной поправки включён и применяется.

Интервал поиска: 28.02.2000 - 30.04.2000
Шаг поиска: 0ч 10м 0с
Критерий поиска:
Солнце.[0-5].Луна

Интервалы реализации (начало - конец):
5.03.2000 21:20 (GMT+2) - 6.03.2000 17:10 (GMT+2)
4.04.2000 11:50 (GMT+3) - 5.04.2000 6:20 (GMT+3)

Первое новолуние указано по зимнему времени, второе - по летнему.
-----------------------------------------------------------------

В руководстве пользователя - слишком кратко, согласен, доделаю.

Анатолий, а можно по-подробнее, какие еще нужны действия кроме отметки "галочки" напротив опции "Расчет временной поправки", чтобы учитывалась актуальная поправка к GMT?

В окне блока "Поиск События" имеется только эта настройка (она и была активирована):


Также включена поправка в исходных и фоновых данных, однако все это не дает ожидаемого результата:





Натал: 1 января 1960 Пт 12:00 (GMT+3)
Интервал поиска: 28.02.2000 - 30.04.2000
Шаг поиска: 0ч 10м 0с
Критерий поиска: Солнце.[0-5].Луна'

Интервалы реализации (начало - конец):
29.02.2000 12:50 (GMT+2) - 1.03.2000 9:00 (GMT+2)
27.03.2000 21:00 (GMT+2) - 28.03.2000 17:10 (GMT+2)
24.04.2000 5:00 (GMT+2) - 25.04.2000 1:10 (GMT+2)

Автоматический переход между GMT+3 и GMT+2 не осуществляется.

так вроде специально выделено было...

Анатолий Зайцев писал(а):Поправки определяется по заданной фоновой карте, в процессе динамики времени она не перевычисляется.

Анатолий Зайцев писал(а):В руководстве пользователя - слишком кратко, согласен, доделаю.

Может быть в программе сделать корректно работающую функцию "Расчет временной поправки", чтобы не нагружать пользователя советом делать эту операцию в уме?

Александр Филиппов писал(а):так вроде специально выделено было...

Анатолий Зайцев писал(а):Поправки определяется по заданной фоновой карте, в процессе динамики времени она не перевычисляется.

Ну да. Все понятно. И выделено, и не перевычисляется.
Решила понять, как же поступать в таких случаях, и... я растерялась. У меня возникли вопросы. При мелком шаге поиска время события (в GMT) указано верно.
Пользователю надо всего лишь держать в уме, что интервалы события не обязательно указано местное время и необходимо свериться часовую поправку. Кто с арифметикой дружит, тот догадается, как надо вычислить местное время.
А здесь уже не получиться держать в уме только часовую поправку, потому что в первом случае аспект "включился" в 7:00, а в другом в 9:00 по Гринвичу.

"в первом случае аспект "включился" в 7:00, а в другом в 9:00 по Гринвичу."
Разница в пределах заданного шага (3 часа).

Анатолий Зайцев писал(а):"в первом случае аспект "включился" в 7:00, а в другом в 9:00 по Гринвичу."
Разница в пределах заданного шага (3 часа).

Да, по Гринвичу разница 2 часа, по местному уже 3 часа, что тоже не превышает заданного шага.
Да и действие аспекта не превышает этого значения (6 и 9 часов).

Анатолий Владимирович, а можно сделать так, чтобы расчет и выполнялся, и выдавался на печать с учетом летнего/зимнего времени, согласно заданного интервала поиска?

Наверное можно, но пока не знаю как.

Обновлена таблица изменений исчисления времени (upd141214, касается Казахстана).
NB: После обновления таблиц следует перезапустить программу.

Прогнозирование, окно "интерпретация"
Жму "прогноз на период (расширенный)"

Выбираю "транзиты", но... выдаёт всё подряд.

Например:

* Луна прогрессивная в секстиле или трине к Нептуну радикса

А можно как-то сделать, чтобы при запросе транзитов выдавались только транзиты, при запросе дирекций только дирекции, при запросе прогрессий прогрессии?? Прям очень важно.

А вот эта фраза по-моему никогда не меняется: "Для создания этого прогноза используются астрологические методы транзитов и прогрессий" - вне зависимости что использовалось.

Спасибо.

Пришлите на email как вложение файл BLACKBOX из папки ZET 9.

Добавил медленную прогрессию, 1d = тропический год. Рассчитал на 120 лет. Нажал Ctrl+5 и написал "соединен" и вот:

* Соединение Юпитер - Юпитер
(с 1 января 1973; экзакт 4 мая 1973 15 февраля 2027)
Нет текста

* Секстиль Юпитер - Asc
(с 1 января 1973 по 1 декабря 2041)
Нет текста

* Соединение Сатурн - Сатурн
(с 1 января 1973 по 2 июня 2013; экзакт 3 мая 1973)
Нет текста

Сначала 2027 год, а потом дата рождения.

а) Как бы орбы уменьшить.
б) Описаний нету даже при отключенных минорных. Снова библиотеки подключать? При добавлении каждой новой методики снова подключать надо?

а) Как бы орбы уменьшить.
б) Описаний нету даже при отключенных минорных. Снова библиотеки подключать? При добавлении каждой новой методики снова подключать надо?
в) постоянно такое встречаю:
* Луна прогрессивная в соединении с Марсом радикса
(с 21 декабря 2020 по 11 октября 2021; экзакт 17 мая 2021)

Эту Луна соединится с Марсом лет через 200.

Попробуйте сначала разобраться с интерпретаций транзита с минимальным набором планет и аспектов. Без куспидов.

Подскажите пожалуйста. В журнале лунных дней выводит
следующую информацию:
22.12 Пн 1 8:35:51 -1 Новолуние
2 9:20:35 -1 Восход
То есть начало первого лунного дня начинается в 8-35-51. Если я строю карту, то новолуние начинается в 7-35-51. На мое местоположение. Журнал или карта неточно отображает время?