т.е. расстояние до Марса в этот момент равнялось 1,773061382 AE
Ну во первых юлианский календарь и юлианская дата - друг к другу никакого отношения не имеют.
Юлианская дата названа в честь отца астронома, который придумал эту систему измерения времени. А юлианский календарь ввел Юлий Цезарь
Во вторых действительно, юлианский день начинается в полдень.
Вычислить отдельно долготы солнца и луны при помощи функции PLC, подставить их в StartPoint, а потом перевести в проценты
Последний раз редактировалось LordWilex, 02.01.2013 в 16:47.
Подскажите, пожалуйста, куда прописать путь к этим файлам, чтобы они заработали? Я подключал Швейцарские эфемериды по варианту 2. Или путь можно указать только по варианту 1?
По умолчанию в "c:\sweph\", но Вы можете задать любой путь просто подредактировав функцию SweInit()
И еще, я не в курсе что за задачи Вы решаете, но если Вам принципиальна большая точность, то лучше скачать файл DE406.eph от сюда: ftp://ftp.astro.com/pub/swisseph/ephe/jplfiles/ и положить его в c:\sweph\, а при вызове функций использовать букву J вместо S, например, "JTrop" вместо "STrop".
Я пока только собираю данные для оценки влияния факторов космической среды на состояние биологических систем.
Еще один вопрос. Я как-то сразу упустил тот момент, что нужно подключить файлы
sepl_18.se1
semo_18.se1
seas_18.se1
+ рекомендованный Вами DE406.eph
Сейчас я это сделал, но результаты моих расчетов от этого не меняются (в том числе я заменял Strop на Jtrop). Я рассчитывал только расстояния до объектов 0-9 и дома Плацидуса для этих же объектов. Это нормально или у меня какие-то технические проблемы с подключением файлов ШЕ?
И еще я сличил ваши расчеты со своими по приведенному Вами примеру. Получаются разные результаты.
Ваш пример:
1. Вычислим юлианскую дату на 10-08-1980 14:00 по гринвичу.
Тут проблема вот в чем. Формулы exel чувствительны к регистру символов.
Вводить надо не Strop именно STrop т.е. вторая T так же с заглавной буквы.
Если функция не понимает, что вы ей хотите сказать - она автоматически присваивает параметр "def", а у него флаги несколько отличаются.
Если выбрать def (или любое непонятное для функции сочетание символов, например, Strop), то будут использоваться такие флаги:
iflag = SEFLG_SPEED + SEFLG_MOSEPH
А если написать STrop, то будут использоваться такие флаги: iflag = SEFLG_TRUEPOS + SEFLG_SWIEPH
Первый вариант работает быстрей, а второй - точней
Ваша система позволяет проводить расчеты в топоцентрической системе координат? Соответствующей функции я, кажется, не нашел, но я мог во что-то просто пока не вникнуть.
Вопрос конечно интересный.
Среди флагов есть такой SEFLG_TOPOCTR, но как его использовать не понятно
Для того, чтобы сконвертировать координаты в топоцентр - необходимо в функцию как-то подать географические координаты местности, но в функции swe_calc_ut() из Swedll.dll (которую использует функция PLC), просто не предусмотрены параметры для ввода географических координат
Завтра пороюсь в документации, в крайнем случае найду формулы для перевода из геоцентра в топоцентр и напишу функцию.
Но у меня по этому поводу несколько замечаний.
1. Топоцентрические координаты имеет смысл использовать только с JPL эфемеридами (de406 или более свежие, те в которых букву Jнадо при вызове функции PLC добавлять), что касается швейцарских эфемерид и тем более эфемерид Мошьера, то там погрешность явно больше диаметра Земли или сопоставима с ним.
2. Даже если использовать точные JPL эфемериды то в масштабах Солнечной системы разница будет незаметная. Верней разница между топоцентром и геоцентром заметна только для Луны. Хотя как раз Луна вроде бы больше всего и влияет на биологические процессы.
3. С учетом того, что радиус Земли равен 6300км, а сама Земля движется со скоростью 30км/сек, для только чтобы был смысл использовать топоцентр, точность Ваших экспериментальных данных должна быть не меньше 6300/30= 210 секунд. Если погрешность ваших данных - составляет хотя бы половину этой величины - разницы между топоцентром и геоцентром - Вы не заметите Разумеется, речь идет о разницы для Луны - для планет разница между топоцентром и геоцентром в любом случае пренебрежительно мала.
Если появится и такая функция, то ваша утилита будет для меня бесценна. Я смогу получить абсолютно все необходимые для исследования данные. Заранее спасибо!
Откройте exel.
Нажмите ALT+F11, в появившемся окне найдите модуль SweRuXla.xla, а в нем найдите module1 и в самый конец открывшегося окна вставьте содержимое этого файла: plcTopo.txt.
Это в принципе та же функция PLC, только немного подредактированная и называется PlcTopo().
Параметры те же, что и в PLC, только в конце еще такие параметры:
1. GeoLonGr - градус географической долготы
2. GeoLonMin - минута географической долготы
3. GeoLatGr - то же самое, только для широты
4. GeoLonMin - широта минуты
5. GeoAlt - Высота над уровнем моря.
Пример использования:
Широта: 47°12' северной широты
Долгота: 38°54' восточной долготы
Высота: 30 метров над уровнем моря
Дата: 10-08-1980 14:00 GMT, JD=2444462,083
Планета Марс = 4
Предположу, что если с буквой E файл больше, то по моим скромным знаниям английского там Еxtended или Еnhanced данные, то есть с более высокой точностью.
Ну размер файла зависит от интервала времени для которого эфемериды рассчитаны. Если эфемериды покрывают интервал в 100 лет, то и файл будет не такой большой, как для эфемерид, охватывающих интервал в 3000 лет.
А на счет точности, - более старшие версии обычно более точней, потому что свежей - хотя не всегда, тут нужно читать документацию к каждой конкретной эфемериде на сайте NASA.
Например, DE414 (или DE421 уже не помню точно) делалась специально для миссии марсоходов, поэтому координаты Марса она считает очень хорошо, чуть ли не до метров точность доходит, но к сожалению охватывает слишком малый интервал времени.
А вот DE406 такой точностью похвастаться не может, но зато покрывает очень большой интервал времени и для астрологических нужд её более чем достаточно
Последний раз редактировалось LordWilex, 22.01.2013 в 13:33.
Вы года три назад, смотря по сообщениям форума здесь хотели сделать отдельную библиотеку на ассемблере для экселя где все функции были бы запрограммированы, а в экселе только остались бы описания, как я понимаю это может увеличить скорость вычислений в несколько раз.
Оставил.
Вообще-то не только для экселя, а просто библиотеку, типа ШЭ, но менее точную, на аналитических формулах, но зато очень быструю для обработки больших массивов.
Есть несколько задач для которых точность не так важна, но зато для обработки всего этого на обычном железе - нужны недели, если не месяцы, а код на ассемблере мог бы сэкономить время (если не считать того времени, что требуется на его написания )
Начал было, и даже написал 2 функции для работы и юлианскими датами - но, на том работа и зависла, а потом понял, что погорячился.
Во первых, - писать на асме - это большой геморой, не для меня это, особенно с учетом того, что реально круг задач, для которых это действительно нужно не такой уж большой и реально воспользуются этим 3 калеки в 3 задачах, в остальных случаях ШЭ с головой хватит
Во вторых, - простая установка по-больше памяти и SSD диска даст куда больший прирост производительности, чем изобретение велосипеда и переписывание его на ассемблере.
В третьих, - x86 архитектура похоже доживает последние деньки, а производительность процессоров все больше растет. Дык что на если на перспективу делать что-то на ассемблере пустая трата времени.
А если применительно к эксель, - то использовать такую библиотеку выгодно только когда в функцию загоняешь сразу большой массив данных, который в ней обрабатывается и выдает результат в виде такого же массива. Но с учетом времени, которое эксель тратит на заполнение ячеек - разницы с аналогичной функцией, написанной на СИ Вы не заметите. Да и не помещается на листе эксель столько ячеек, чтобы их было на ассемблере обрабатывать заметно выгодней, чем на СИ
Последний раз редактировалось LordWilex, 23.01.2013 в 00:42.
Линейный вид
