Тут такая потребность появилaсь - нужно посчитать Лунные дни.
Сколько смотрел в функциях, такой не нашёл.
Можно такую функция спрограмировать ?
Был бы очень благодарен :)
Тут такая потребность появилaсь - нужно посчитать Лунные дни.
Сколько смотрел в функциях, такой не нашёл.
Можно такую функция спрограмировать ?
Был бы очень благодарен :)
Эдик
Здравствуйте.
Как я понимаю Вы имеете в виду западные лунные дни?
С этим проблемы
К сожалению технически на платформе VB, что встроен в эксель это сложно (а главное нецелесообразно) реализовать. Дело в том, что в западной традиции лунный день представляет собой количество восходов Луны после новолуния.
т.е. с технической точки зрения алгоритм сначала должен рассчитать момент новолуния, а потом N раз рассчитать восходы Луны.
Так вот все известные алгоритмы для вычисления момента восхода Луны предполагают слишком большое кол-во итераций, а это значит, что такая функция, если её делать на и без того тормозючей платформе VB будет не просто тормозить, она будет дико тормозить
Если Вам нужно вычислить 1 ячейку - можно и подождать секунду.
Но проект прежде всего заточен на статистическую обработку больших массивов данных. Если у Вас база из 100000 карт - ждать результата вычислений Вам придется до второго пришествия.
К тому же на западе лунные дни ни одна вменяемая астрологическая школа не использует, поэтому в Швейцарские эфемериды они и не включены
Они использовались, например, для таких вещей, как расчёт даты пасхи, но ни как не для астрологических прогнозов
Использовать лунные дни в астрологии придумал Пал Палыч Глоба в 90 годах прошлого века
Есть конечно лунные дни из индийской астрологии, но это совсем другое и представляют собой они просто угловое расстояние между Солнцем и Луной.
В перспективе я планирую поместить все дополнительные функции в отдельную dll библиотеку, на VB будут только декларации + будет возможность пакетных вычислений внутри этой dll-ки, вот тогда можно будет и лунные дни реализовать, а пока я нахожу это нецелесообразным.
P.S.
Возможно Вам подойдет функция MoonDayDjotish() - вычисляет лунные сутки по джотишу, которые в большинстве случаев совпадают с западными.
Использовать лунные дни в астрологии придумал Пал Палыч Глоба в 90 годах прошлого века
Вы глубоко заблужддаетесь Глоба ничего не придумывал сам.... А лунными днями учил пользоваться Вронский замечательный человек с большой буквы и все расчеты нужно строить по его системе.
Вы глубоко заблужддаетесь Глоба ничего не придумывал сам.... А лунными днями учил пользоваться Вронский замечательный человек с большой буквы и все расчеты нужно строить по его системе.
Это Вы глубоко заблуждаетесь. Простой сравнительный анализ текстов показывает, что большая часть идей его сиятельства Сергея Алексеевича Вронского как раз таки позаимствованы у Пал Палыча, но ни как ни наоборот. Да и романтическая биография великого и печального графа большей частью является выдумкой
Привет! за проделанную работу по адаптированию функций швейцарских эфемерид под Excel!
В процессе использования обнаружил небольшую неточность: по разному расшифровываются значения переменной Xpos. В одном случае(на первой странице справки): 0 - долгота, 1 широта..; в другом случае (в комментариях в VB): 0 -нет, 1 широта, 2 долгота; в третьем (в перечислениях условий одной из функции в VB): 0-широта, 1-долгота
ВОПРОС: правильно ли я понимаю что для всех функций значение Xpos=0 -это долгота, Xpos=1 -это широта и т.д. (или для разных целей по разному расшифровываются значения Xpos)?
Цитата:
' XPos = Тип возвращаемой координаты
' XPos = 1 = Широта (или X координата, если задано CType = SXYZ | MXYZ | JXYZ )
' XPos = 2 = Долгота (или Y координата)
' XPos = 3 = Расстояние от Земли (в геоцентре) или Солнца (в гелиоцентре) (или Z координата)
' XPos = 4 = Угловая скорость / сек по широте
' XPos = 5 = Угловая скорость / сек по долготе
' XPos = 6 = Угловая скорость / сек по расстоянию
Цитата:
Call swe_calc_ut(JD, pl, iflag, x(0), serr$)
' serr$ = set_strlen(serr$)
Plc = x(0)
If XPos = 1 Or XPos = "Lat" Then Plc = x(1)
If XPos = 2 Or XPos = "Lon" Then Plc = x(2)
If XPos = 3 Or XPos = "Dis" Then Plc = x(3)
If XPos = 4 Or XPos = "SpdLat" Then Plc = x(4)
If XPos = 5 Or XPos = "SpdLon" Then Plc = x(5)
If XPos = 6 Or XPos = "SpdDis" Then Plc = x(6)
If XPos = 7 Or XPos = "Er" Then Plc = serr$
DoEvents
Цитата:
Call swe_fixstar(StarName, JD, iflag, x(0), serr)
If XPos = 0 Or XPos = "Lat" Then stars = x(0)
If XPos = 1 Or XPos = "Lon" Then stars = x(1)
If XPos = 2 Or XPos = "Dis" Then stars = x(2)
If XPos = 3 Or XPos = "SpdLat" Then stars = x(3)
If XPos = 4 Or XPos = "SpdLon" Then stars = x(4)
If XPos = 5 Or XPos = "SpdDis" Then stars = x(5)
If XPos = 6 Or XPos = "Er" Then stars = serr$
Привет! за проделанную работу по адаптированию функций швейцарских эфемерид под Excel!
В процессе использования обнаружил небольшую неточность: по разному расшифровываются значения переменной Xpos. В одном случае(на первой странице справки): 0 - долгота, 1 широта..; в другом случае (в комментариях в VB): 0 -нет, 1 широта, 2 долгота; в третьем (в перечислениях условий одной из функции в VB): 0-широта, 1-долгота
ВОПРОС: правильно ли я понимаю что для всех функций значение Xpos=0 -это долгота, Xpos=1 -это широта и т.д. (или для разных целей по разному расшифровываются значения Xpos)?
Вы знаете, там в документации получается ошибка. По всей видимости я один раз что-то перепутал и скопировал этот отрывок везде, в том числе в документацию и комменты
И главное ни кто не заметил
В общем, пока я не исправил это в документации и комментах, во ВСЕХ функциях в параметр Xpos вводим следующее:
0 - Долгота
1 - Широта
2 - Расстояние планеты до Земли
3 - Скорость по долготе
4 - Скорость по широте
5 - Скорость изменения расстояния от Земли до планеты
Если речь идет о прямоугольных координатах, то:
0 - Х координата
1 - Y координата
2 - Z координата
3 - Скорость X координаты
4 - Скорость Y координаты
5 - Скорость Z координаты
Если речь идет о экваториальных координатах:
0 - Прямое восхождение
1 - Склонение
2 - Расстояние планеты до Земли
3, 4, 5 - соответствующие скорости.
Этот принцип распространяется на все функции.
Меня же в основном интересует долгота планеты, вот я автоматом в этот параметр и пишу ноль, а как там написано у меня в документации не задумываюсь.
А документация то версталась в спешке, причем многие куски текста повторялись, вот я ошибку и размножил
Ок! Я так и думал. (Меня тоже интересует долгота, просто вместо нее у меня выдавалось (указывал 1) какое-то значение с плавающей точкой, и лишь перечитав справку обнаружил что нужно указывать 0 и все получилось :)
Если по формулам SweRU получить долготу Солнца на Юлианский день 2446095.55278, то она составит 310.104390285507, т.е. 10град водолея 6мин 16 сек.
Хотелось бы как минимум определиться с верной долготой Солнца и Юлианским днем на указанную дату, ну а потом конечно же и Ваши идеи о причинах такого обстоятельства.
Возможно вы сразу увидите у меня ошибку из формул расчета юлианского дня (они написаны на C#)кстати они дают одинаковый результат (2446095.54166667).
Код:
if (month <= 2) {month = month + 12; year = year - 1;}
Double jdayValue;
if (gregflg == 0)
{
jdayValue = 365 * year + 1720996.5 + (-2 + Math.Truncate(((Double)year + 4716) / 4) - 1179)
+ Math.Truncate(30.6001 * (month + 1)) + day + (hour + min / 60 + sec / 3600) / 24;
}
else
{
jdayValue = 365 * year + 1720996.5 + (Math.Truncate((Double)year / 400) - Math.Truncate((Double)year / 100) + Math.Truncate((Double)year / 4))
+ Math.Truncate(30.6001 * (month + 1)) + day + (hour + min / 60 + sec / 3600) / 24;
Код:
[DllImport("swedll32.dll", CharSet = CharSet.Unicode, EntryPoint = "_swe_julday@24")]
unsafe public static extern Double swe_julday(int Year, int Month, int Day, Double hour, int gregflg);
А в Швейцарские Эфемериды вшиты все параметры планет: орбиты, экстрисицет, узлы планет, наклон орбиты и т.п.?
Это получается, я так подумал, вытаскиваешь из них данные, посдтавляешь в формулы, а потом - дело за графикой?
Я дилетант... извините...
Несовпадение юлианской даты с ZET на одну единицу объясняется просто округлением.
Несовпадение координаты Солнца на 1 секунду скорей всего объясняется поправками (например, на земной эллипсоид, скорость света и т.д.). К сожалению в вопросе использовать или не использовать эти поправки тут единственно "правильного" ответа нет. Каждый автор программы решает сам включать их или нет.
Так же проверьте, возможно SweRu или в ЗЕТ не видит файлы швейцарских эфемерид, в этом случае все программы, которые работают на ШЭ автоматически переключаются на эфемериды Мошьера, а они менее точны.
***
Так же обращаю внимание, что европейских программах/алгоритмах во временной поправке используются разные стандарты обозначения. Поправки, которые у нас в России обозначаются знаком "+" у них принято обозначать знаком "-".
Т.Е. то, что в программе ЗЕТ обозначается как "+5" часов, в SF и ШЭ обозначается, как "-5", от сюда и путаница
На счет программы Newa, если мне память не изменяет - там используется собственное эфемеридное ядро, так что в этом вопросе она вообще не авторитет.
А в Швейцарские Эфемериды вшиты все параметры планет: орбиты, экстрисицет, узлы планет, наклон орбиты и т.п.?
Ну а то
Цитата:
Сообщение от Единорог
Это получается, я так подумал, вытаскиваешь из них данные, посдтавляешь в формулы, а потом - дело за графикой?
Я дилетант... извините...
Эх, если бы... нет, с ШЭ там все на много сложней...
Если Вам просто нужны формулы и параметры орбит, то советую скачать какую-нить "астрономию с калькулятором" или постоянную часть астрономического ежегодника. Там все это хозяйство есть. Только просто по формулам приемлемо высокой точности не добьешься.
Если Вам просто нужны формулы и параметры орбит, то советую скачать какую-нить "астрономию с калькулятором" или постоянную часть астрономического ежегодника. Там все это хозяйство есть. Только просто по формулам приемлемо высокой точности не добьешься.
Энто мы уже проходили...
Там точность действительно невысока....
А смысл с ними работать?
Если проги уже есть...
Если только свою коммерческую разработать...
И то конкуренты на рынке очень сильны...
прочитал первый пост уяснил)))
повторять мне не надо))
msgbox "OK"
__________________
Последний раз редактировалось Единорог, 05.01.2011 в 20:08.
0. Вопрос расхождения юлианской даты снят (в моей программе не верно она рассчитывается, а в Excel выдает то же что и в Zet:2446095.55138889)
1. Чем может быть вызвано расхождение в долготе (см. мою картинку) (формулы ведь один к одному)?
2. Почему у меня в Zet другие значения долготы отображаются (и не только по Солнцу)? и что означают величины dE и dF (может дело в них)?http://forum.argo-school.ru/attachme...d =1294258743
3. Как проверить видит ли программа (Excel/Zet)швейцарские эфемериды? Правильно ли я понимаю что в файле swedll32.dll только эфемериды Мошьера, а истинно швейцарские в файлах se**_18.se1 (вместо звезд as/mo/pl)?http://forum.argo-school.ru/attachme...d =1294258752
(Когда у меня отсутствовали файлы Se** у меня в параметр serr (переменная для записи ошибки) записывалось что-то тип не найден файл, но отсутствие такой записи думаю еще совсем не есть факт что из них берется информация, а не из Swedll32.dll))
1. Чем может быть вызвано расхождение в долготе (см. мою картинку) (формулы ведь один к одному)?
Вот это интересный вопрос
Если даже используются эфемериды Мошьера вместо ШЭ, такого большого расхождения в 5 минут это дать не может. Скорей всего дело в поправках...
Попробуйте в ЗЕТ зайти в "настройки" -> "общие установки" и поставить галочки "учитывать земной эллипсоид" и "учитывать конечность скорости света".
Ну у меня в ЗЕТ значения те же, что и в эксель (верней почти те же, расхождение в 1,5 угловые секунды это нормально, объясняются флагами (поправками на скорость света/эллипсоид и т.д.) в настройках ШЭ, на использование/не использование которых нет "самых правильных стандартов" см. мой предыдущий пост)...
...что-то не то у Вас с настройками ЗЕТ, 5 угловых минут - это слишком большая ошибка для ШЭ...
Нет, dE/dF тут не причем, dE это разница с эфемеридным временем, оно ни на что не влияет. Что такое dF не помню, но кажется оно тоже ни на что не влияет.
Цитата:
Сообщение от Руслан
3. Как проверить видит ли программа (Excel/Zet)швейцарские эфемериды? Правильно ли я понимаю что в файле swedll32.dll только эфемериды Мошьера, а истинно швейцарские в файлах se**_18.se1 (вместо звезд as/mo/pl)?http://forum.argo-school.ru/attachme...d =1294258752
(Когда у меня отсутствовали файлы Se** у меня в параметр serr (переменная для записи ошибки) записывалось что-то тип не найден файл, но отсутствие такой записи думаю еще совсем не есть факт что из них берется информация, а не из Swedll32.dll))
Для ЗЕТ: "настройки" -> "общие установки" -> "дополнительно" и выберите путь, в котором у Вас находятся файлы ШЭ, а потом кнопку "проверить".
Для SweRu тут процедура по сложней.
Нужно зайти в редактор VB и в процедуре "SweInit()"
Прописать путь, если он отличается от стандартного.
Затем дважды вызовите функцию plс один раз с параметром "MTrop", второй раз с "STrop" если результаты будут отличаться, значит программа использует ШЭ.
Последний раз редактировалось LordWilex, 05.01.2011 в 22:06.
для начала совсем глупые вопросы, которые меня тихонько гложат:
1) Почему расхождение в "5 угловых минут"? у Вас 310.6.09 у меня 310.5.50 - т.е. разница в 19 секунд (либо мы о разном либо я не правильно считаю разницу/ использую понятия)?
2) Правильно ли я понимаю, что от географической точки места координаты планет не зависят, т.е. они для любой точки места постоянны(ну как минимум долгота (другие пока мне без надобности))?
Сделал, что Вы, LordWilex, мне написали:
"учитывать конечность скорости света" флаг стоял (даже не доступен для изменения)
"... а потом кнопку "проверить"."вышли на экран доготы со словом "ОК"
"учитывать земной эллипсоид" поставил флаг (не стоял)
не помогло - в Zet все осталось без изменения (310.5.50). Т.е. по-прежнему для меня открыты вопросы: "Почему Zet дает разные рузультата?" и
"Какое значение из приведенных более верное/точное?"
- у Вас в Zet 310°06'09'',
- у Вас в SweRU 310°06'10'',
- у меня в Zet 310°05'50'',
- у меня в Newa-psy 310°05'49'',
- у меня на сайте vgoroskope 310°06'02''.
Последние два программных продукта создавались под руководством школы СВШ, поэтому считаю нужным и с ними сравниться,
- :) вспомнил еще одно место, откуда можно получить долготу (sweph\bin\swewin32.exe) и вот он: 10 aq 5'49.9099. (для некоторого удобства и убедительности привожу снимки экранов всех программ (на одном снимке время в swewin32.exe указано с ET, на другом с UT)).
кстати, что означает обозначение в swewin32.exe рядом со временем ET/UT (в случае с ЕТ JD совпадает с SweRu, в случае с UT долгота полученная долгота Солнца совпадает с Newa-psy)?
Проверил действие "MTrop"/"STrop" у меня они действительно один и тот же в Excel давали результат, но в своей программе ( из-за которой я все начал сравнивать) я использовал верные файлы (швейцарских эф). У меня в программе почему-то Юлианский день рассчитывается не верно - это моя проблема конечно же (хотя теперь когда полностью это сообщение написал уже сомневаюсь), но есть более важная проблема, с которой хотел поделиться со всеми:Как такое может быть, что по одной и той же юлианской дате 2446095.55138889 и по одной и той же функции, хоть в разных программах (VB и C#), я получаю разный результат? (хочется определить и устранить причину, либо определиться в существенности отклонения)
Подробности проблемы:
1) в обоих случаях используется функция swe_calc_ut библиотеки Swedll32.dll
(plc получает данные после вызова функции swe_calc_ut, прошу LordWilex-а меня поправить если не так)
2) далее приведу полученные значения долготы Солнца для юлианской даты 2446095.55138889
с настройками STrop: (SweRU в Excel / моя прога на С#)
310.1029775674680 / 310.1029775688860 т.е. у меня больше на 0.0000000014183
310° 06' 10.719243'' / 310° 06' 10.719248'' т.е. у меня больше на 0.000005''
с настройками STrop: (SweRU в Excel / моя прога на С#)
310.1029765040040 / 310.1029746208120 т.е. у меня меньше на 0.0000018831919
310° 06' 10.715414'' / 310° 06' 10.708635'' т.е. у меня меньше на 0.006779''
p.s. не смотря на то, что "нет "самых правильных стандартов"" в вопросе хотелось бы разобраться, потому что первопричина проблемы может повлиять еще на что-то, и при этом в следующий раз у нас может не быть возможности сравнить результат с ч-либо и мы не заметим ошибочности полученных данных. Со статистикой тем более шутки плохи - любая даже маленькая ошибка имеет свойство накапливаться и вырастать в одну, но очень большую! на крайний случай я конечно же закрою глаза на расхождения, но очень не хотелось бы прибегать к самому крайнему: бросить заниматься астрологическими программами и сидеть сложа руки в ожидании реализации желаемых функций другими очУмельцами :)
для начала совсем глупые вопросы, которые меня тихонько гложат:
1) Почему расхождение в "5 угловых минут"? у Вас 310.6.09 у меня 310.5.50 - т.е. разница в 19 секунд (либо мы о разном либо я не правильно считаю разницу/ использую понятия)?
Ну я имею в виду сравнение результатов ЗЕТ с теми настройками, которые на моем компьютере
У меня ЗЕТ показывает 310 гр. 6 минут. 9 секунд (настройки стандартные, по умолчанию, я их не менял, только убедился, что ШЭ подключены).
А SweRu показывает: 310 градусов 6 минут 10,66 секунд
Разница всего примерно в полторы секунды, что вполне допустимо.
А то, почему у Вас такие расхождения я не знаю, я ж не ясновидящий
...Проблема или в поправках или у Вас не подключены ШЭ....
Цитата:
Сообщение от Руслан
2) Правильно ли я понимаю, что от географической точки места координаты планет не зависят, т.е. они для любой точки места постоянны(ну как минимум долгота (другие пока мне без надобности))?
Ну это зависит от типа координат, которые Вы используете.
Если геоцентрические/барицентрические (т.е. когда за центр системы принят либо центр земли, либо центр тяжести системы Земля-Луна) то не зависит.
Если топоцентрические (т.е. за центр системы принята точка на поверхности Земли, на которой Вы находитесь) - то конечно же зависит, причем важную роль играет не только широта/долгота, но и высота над уровнем моря.
****
На остальную часть поста отвчу позже, я сейчас в другой теме занят
Последний раз редактировалось LordWilex, 06.01.2011 в 21:12.