Не соглашусь что x86 отживает свое, усилия Интел на уменьшение энергопотребления оставят ее внеконкуренции на очень долгое время.
Если хотите я могу продолжить писать ваш проект на асме при условии что код хорошо закомментирован, иначе будет мне намного легче начать с нуля. Все таки с моими вычислениями 250тыс ячеек с возможным увеличением в будущем на порядок таких ячеек данная библиотека очень бы пригодилась.
У меня вопрос, почему в вашем скриншоте на первой странице дается значение долготы солнца 138.0711226, у меня же вычисляет эксель по ШЭ 138.0767673?
Ну пока тренд такой, что рынок ПК сокращается бешеными темпами, но даже этом сегменте ARM уже наступает на пятки (думаю все закончится чем-то типа Raspberry Pi). Чтобы нормально с ними конкурировать - Интелу придется полностью перекраивать архитектуру, в которой изначально заложено много мусору, от которого так просто так не избавишься, и который превращает их процессоры в печки, а с учетом тенденции к миниатюризации железа - это будет очень сложно.
С рынком планшетов и прочих миниатюрных устройств - тут вообще все очевидно.
Увы, он у меня не сохранился, верней слишком много воды утекло - вряд ли я его сейчас найду в архивах. Да там и было всего 2 функции для перевода из обычной даты в юлианскую и обратно - это капля в море от того, что нужно
Если возьметесь за такой проект - будет шикарно
Если начинать с нуля - могу посоветовать книгу "Астрономия на персональном компьютере" (если что обращайтесь в личку, могу подсказать где найти и т.д.) к ней прилагается диск с довольно компактными алгоритмами на С++, думаю переписать их на ассемблер будет не так сложно.
Есть еще книга "астрономия с калькулятором" - там даются тоже довольно простые алгоритмы, с точки зрения их реализации на ассемблере.
Хотя все это не так точно будет считать, как ШЭ и JPL эфемериды, но зато быстро.
Ну там просто в первых версиях использовались другие наборы флагов, я не помню уже какие. Типа учет/не учет скорости света, геоцентрические/барицентрические (относительно центра тяжести системы Земля/Луна) координаты и т.д. От сюда и разница
Подскажите, пожалуйста, есть ли в ШЭ штатный способ рассчитать куспиды домов по известной долготе МС и географическим координатам (прогрессия с МС=солнечная дуга в ZET)? А если нет, как корректно это сделать через CHouse, задавая JD?
Увы, штатных средств для вычисления Асц по МС и географическим координатам нет.
Если Вам очень нужно решить эту задачу, то тут только 2 варианта:
1. Либо взять формулы для расчета куспидов домов (они есть, например, в книге Дениса Куталева "Небесные координаты и системы домов"), и решить обратную задачу. Но там, с учетом большого количества формул - получится очень большая и запутанная система уравнений, проще убиться об стенку, чем её решать.
2. Либо написать функцию, которая будет искать время, когда МС было в таком-то градусе. Это на много проще, чем убиться об стенку, но сложней, чем выпить яду
Набросал таблицу для ректификации в меру своего понимания алгоритма, который использован в Альмагест.
Ссылка:
Смысл алгоритма - варьируя время рождения, считаем общее количество аспектов углов карты на даты событий - аспекты прогрессивных планет к углам, аспекты прогрессивных (реальных) углов к планетам, аспекты транзитных планет к углам, аспекты дирекции солнечной дуги углов к натальным планетам, аспекты дирекции солнечной дуги планет к углам.
У кого есть время - пожалуйста, протестируйте, работает оно или нет? Меня смущает тот факт, что при наличии тесных аспектов планет в натальной карте будут генерироваться ложные пики (событие одно, аспектов много). Кроме того, нужно определиться со значимыми аспектами, орбисами, методами прогрессий и дирекций.
Чтобы работать с таблицей, нужно на первой странице внести данные: предположительное время рождения GMT, координаты, события, даты событий, погрешность даты события в днях. Для используемых аспектов - их значение и орбисы (для отключения аспекта используйте орбис = 0).
Погрешность даты события влияет следующим образом. Если за время погрешности прогрессивная или транзитная планета успевает уйти дальше, чем на величину максимального орбиса из таблицы аспектов, то ее аспекты не суммируются. На дирекции орбисы событий не влияют. Я пока использую точные даты событий и погрешность даты 0. Можно поставить погрешность 150 дней, чтобы отключить транзиты, прогр. Луну и прогр. углы.
Проверка, что события достаточно далеко отстоят друг от друга не реализована. Может быть, нужно - чтобы можно было включить близкие по времени события в быстрые методы, но в медленных методах считать их как одно.
Не могу написать функцию прогрессивного АСЦ от МС по солнечной дуге - всю голову над формулой сломал, но АСЦ считается только при МС в диапазоне 0-180, а не 0-360. Подкиньте алгоритм, кто знает, pls...
PS Таблица защищена от редактирования кроме полей дат и событий. Защита без пароля, просто снимите, если нужно.
PPS Дополнительные функции в конце VBA модуля, после родных функций ШЭ. Там все подробно закомментировано.
Я не знаю, что у Вас за алгоритм, но 90% такого рода задач решаются при помощи функции FixY() и StartPoint(), иногда мне кажется, что совместно с арифметическими операторами их комбинация в принципе позволяет решить вообще любую астрономическую задачу
public function GetJDFromMC(МC as double) as double
'Юл. день, в который МС имеет заданную долготу на геогр. долготе
'0
Dim JD as double, MCopt as double
JD = 2450000
MCopt = -1
Do While ((MCopt < MC - 0.1) or (MCopt > MC+0.1))
MCopt = CHouse(JD, "T", "MTrop", 14, 0, 0, 0, 0)
JD = JD + 1/24/60/5
if JD > 2450002 then
JD = -1
exit do
endif
Loop
GetJDFromMC = JD
end function
Просто неизящно и тормозно, если вызывать в циклах.
С Calc не дружу совсем :( Один раз реализовал расчеты мельницы, оказалось проще скомпилить в VS и вытащить результат в csv. :) Там массив не передать в функцию через Range!
Вопрос to all.
Задумал реализовать ректификацию по Айзину, но книга довольно путанная. Здесь есть специалисты на предмет проконсультировать что за чем считать? Потому как метод выглядит хорошо продуманным, но с кучей допущений (типа интервалов, когда рожднние невозможно), а для проверки нет ничего лучше публичного тестирования.
Ректификация по событиям методом "сгущений" в Excell
Переделал программу для ректификации с возможностью считать множественные аспекты к/от углу для одного и того же события за один аспект. Этот подсчет реализован на странице Ректиф2 и Итоги(2). Кроме того, привел в порядок таблицу аспектов и диаграммы.
Таблица включена в режим "Пересчитывать вручную" (вкладка "Формулы" - Параметры вычислений), чтобы не тормозить при вводе данных.
Ввод данных - на первой странице.
На сейчас, с подобранными параметрами, вроде неплохое попадание пиков в известное время рождения. Кому интересно - смотрите!
Попытался прописать критерии для ректификации по Айзину методом исключения интервалов, в которые невозможного рождение. Пока не трогая ректификацию по событиям.
Посмотрите, пожалуйста, все ли я правильно понял? Программно реализовать такую проверку с шагом, скажем, в минуту не слишком сложно, разве что для начала выставить орбис для расходящихся аспектов как для сходящихся.
Итак, критерии:
Используется ряд аспектов, с орбисами, приведенными в таблице (потом уточним, таблица есть в книге).
0; 20; 30; 36; 40; 45; 51,4; 60; 72; 77,2; 80; 90; 100; 102,8; 108; 120; 128,6; 135; 140; 144; 150; 160; 180
Критерии возможности времени рождения
1. Для карты должно быть выполнено условие:
Каждая планета имеет аспект к 0,0 Овна или к планетам, имеющим аспект к 0,0 Овна. Если для какой-либо планеты данное условие не выполнено, то куспид дома, который она сигнифицирует, должен сам иметь прямой аспект к 0,0 Овна (но не к планете, имеющей аспект к 0,0 Овна).
Сигнификаторы: I – Марс, II – Венера, III – Меркурий, IV – Луна, V – Солнце, VI – Меркурий, VII – Венера, VIII – Плутон, IX – Юпитер, X – Сатурн, XI – Уран, XII – Нептун. Прозерпина и двойные управления не рассматриваются.
2. Должно также быть выполнено условие.
Куспид каждого дома должен иметь аспект со своим сигнификатором или с планетой, имеющей аспект к сигнификатору. Таблица сигнификаторов та же, что и в предыдущем критерии. СЛЕДСТВИЕ: Каждый куспид должен иметь хотя бы один аспект к планете.
3. Планеты-управители всех знаков, в которые попадает дом, должны иметь аспекты с сигнификатором этого дома или с планетой, которая делает аспект к сигнификатору дома. Если для какой-либо планеты это условие не выполнено, то куспид дома должен иметь аспект к планете - управителю знака, в который попадает дом (но не к планете, которая делает аспект к управителю).
Используется предположение, что каждым знаком управляет только одна планета, аналогично таблице сигнификаторов в критерии 1. Прозерпина не учитывается.
Здесь есть неясность. Если дом занимает более 2 знаков, значит ли это, что каждая из трех или даже четырех планет – управителей соответствующих знаков участвует в критерии 3?
1.спасибо всем и ТСу в особенности за проделанную работу
2.помогите найти время восхода солнца по известной Lon и JD
пробовал подставлять в swe_rise_trans но все время выдает -1
делал вот так:
swe_rise_trans(JD;0;"Sun";18;1;Lon;800;1 5;C13;D13)
Надо пользоваться функцией parans(JD As Double, Pl, CType, LonH, LonM, LatH, LatM, Alt As Double, rsmi) As Double.В родной функции swe_rise третий параметр - это вектор chr длиной 256, а шестой - ссылка на массив из 3 элементов (широта, долгота и высота).
разобрался ещё вчера
у меня виндовс и оффис уже давно 64бит
специально для ШЭ поставил старый 32битн офис
все заработало только после того как скопировал swedll32.dll в папку C:\Windows\SysWOW64
подскажите пожалуйста ещё как вычислить склонение с помощью ШЭ
В функции PLC вместо STrop использовать SEq (экваториальные координаты), тогда XPos=1 - выдаст склонение, а XPos=2 - прямое восхождение... или наоборот не помню уже, но это можно методом тыка определить
не помню уже, но это можно методом тыка определить 
Линейный вид
