오늘은 대한입니다.
sun's longitude:300 05 1.83 
· 자유게시판 · 묻고답하기 · 알파문서 · RPMS list
· 사용자문서 · 팁/FAQ모음 · 리눅스Links · 자료실
· 서버정보 · 운영자 · Books/FAQ · FreeBSD
/board/read.php:소스보기  

질문과 답변 게시판입니다.

현재 실시간으로 이곳 서버의 설정파일(몇개)를 보여주고 있습니다.
서버의 설정내용에 관한 질문은 먼저 이곳 서버의 설정내용을 참고하시길 바랍니다.

[*** 쓰기 금지단어 패턴 ***]
글 본문 중간에 업로드할 이미지를 추가하는 방법 : @@이미지이름@@
ex) @@foo.gif@@
2828 번 글의 답장글: Re: Re: Re: Re: class.lunar.php 문의
글쓴이: 인철 글쓴날: 2009년 06월 10일 22:59:48 수(저녁) 조회: 2335
우선 답변에 감사드립니다.

홈페이지를 만들면서 기존에 db로 구축되어 있는 자료를
최대한 부하를 감소해보고자 계산으로 바꿔 처리해볼려
했었는데,

-_-;; 배보다 배꼽이 더 큰격이 되버려서 

다시 기존 db 잘 다듬고 인덱스 설정 잘해서 쓰는걸루
돌아갔습니다.

어쨌건 , 성실하고 친절한 답변에 다시 한번 감사드립니다.

----------------------------------------------------------------------------
저의 상황 및 테스트 결과입니다.
----------------------------------------------------------------------------
음/양력 및 절입시간, 및 공휴일 , 28수 등등 기타 역관련 db
데이터가
약 150메가 가량..

150메가 분량을
현재로선 2038년도까지 이지만 현재 산이님의 소스로도
파일 단 한개로 교체가 가능합니다.

정말로 대단한 성과 이긴 한데 , 성능적으로는 좀 힘드네요.
웹용이라...

db 자료나 산이님 소스나 년도 제한은 있습니다.
계산 능력이 db 자료를 능가하지 않고서는 굳이 성능적인
효율을 감소해야 할 
필요성이 없어져 db 자료 좀더 다듬어 보기로 했습니다.

다시한번 친철한 답변에 감사드리며, 복받으세요
















[산이]님이 남기신 글:

>우선 음양력 변환은 좀더 검토해봐야 할것 같습니다.
>기존 unix_timestamp 기반은 JD 기반으로 바꾸어서 계산해야 하는데
이건 만만치 않은 작업입니다.
>
>그리고 24절기 계산에서
>
>http://gapja.net/test/index.php
>
>은 오류가 좀 있네요. 예를 들어 0년은 2000년으로
표기되네요.
>
>class.calendar.php 의 _mktime(), _date() 함수를 이용해서 바꾸어 놓은
것이 있는데
>
>http://linuxchannel.net/?vhost=phps&php[src]=%2Ffunc%2Fclass.calenda
r.ph
>http://linuxchannel.net/?vhost=phps&php[src]=%2Ffunc%2Fclass.solar.p
h
>
>demo 는
>
>http://linuxchannel.net/gaggle/solar.php
>
>입니다.
>
>음양력 변환은 좀더 시간이 걸릴듯...
>
>그리고 기본적으로 JD 구하는 공식에 약간 문제가 있는듯
합니다.
>
>-4712-01-01 12:00:00 (UTC) == -4712-01-01 21:00:00 (KST)
>
>이 날짜를 대입하면 JD 0.0 이 나와야 하는데 다른 수치가
나오네요
>
>
>[인철]님이 남기신 글:
>
>>kldp 에서 검색하는 유저수준일뿐 활동해본적은
없습니다.
>>
>>취미로 PHP 를 공부하는 수준입니다.
>>php 스쿨에서 포팅하신글을 보게 되었습니다.
>>
>>실은 역학관련 프로그램을 만드는과정에서
 본문서를 접하게 되었습니다.
>>윈도용으로 개인적으로 사용하는 역술프로그램을
 인터넷용으로만들어서

>>같이 사용하고 커뮤니티할수있는
 사이트를 만들어보려고요..

>>
>>기존에는 db로 되어 있는 음양력데이터와
 절기일 데이터를 이용해서
>>db에서 접속해서 가져오는 형태였기에 .. ( db 데이터가
100메가가 넘습니다 -_-)
>>db 자료라 이것저것 여러가지가 포함되어 있는
자료지만,
>>
>>음,양력 변환과 24절입시간만 계산으로 처리가 되면 웬만한건
다 해결되거든요..

>>산이님께서 올리신문서를 바탕으로 하게되면 파일한개로
처리가 가능해져서요..

>>
>>db 데이터와 비교를 해보면 , 절입시간이 약 5~30분가량 차이가
나긴하지만요..

>>지나온년도를
 비교해서 평균적으로 느리거나 , 적게 나오는지
판단해서
>>일반적으로 많이 사용되는 시간을 기준으로 가감해서
출력하면 문제 없다 보여집니다.
>>
>>
>>----------------------------------------------------------------------
>>
>>사실 산이님 소스를 봐도 저역시, 천문학에 문외한이라
설명문서 읽어봐도
>>먼소린지 모르겠습니다.
>>다만, 프로그래밍 언어적 구문이해로 문맥의 흐름을 따라서
가보는정도입니다.

>>
>>소스를 보건데,
>>
>>>위의 2개의 파일은 내부 기본 로직은 unix_timestamp
입니다.
>>>따라서 Unix/Linux 에서는 1901 ~ 2038 까지만 가능합니다(32
bits).
>>
>>제가 첨부한 파일이 unix_timestamp 의 2038 제한을 넘어 가능하게
해주는 lib 입니다.
>>
>>
>>class.solar.php 이부분은 제 게시물의 첨부파일을 이용해서

>>3000년(?)까지의
 계산이 되도록 수정되었습니다.

>>
>>단순히 class.solar.php 에 사용된 명령어 중에
>>date , gmdate , mktime 함수를 
>>adodb_date, adodb_gmdate, adodb_mktime 으로 
>>첨부된 파일의 함수로 대체하는것이 전부입니다.
>>
>>http://gapja.net/test/index.php (2038년도 이후도
출력됩니다.)
>>
>>class.lunar.php 파일역시 수정하여서 음양력 부분만 빼고는
계산이 됩니다
>>음양력 부분은 
>>&_newmoon,&_fullmoon,&tolunar 함수에 지정된 배열값때문에
그런듯보입니다.

>>특정 년도까지만 값이 지정되어 있습니다.
>>(아마도 작성할때 2038 제한때문에 그래놓으신듯)
>>
>>static $unit = 5665; // see above comments
>>static $ffx = array(
>>	19310517=>2640, 19321030=>-840, 19341008=> 840, 19530612=>-600,
>>	19550222=>4020, 19580218=>2700, 19860311=>-540, 19950727=>1140,
>>	20120619=> 780, 20150815=>-540, 20170226=> 480, 20350109=> 540,
>>	);
>>
>>static $unit = 5665; // see above comments
>>static $ffx = array(
>>	19031006=>2000, 19131213=>  120, 19280801=>2100, 19360506=> 400,
>>	19380712=> 300, 19450625=>  600, 19500828=>-700, 19550308=>2700,
>>	19560524=>1900, 19581027=> 3000, 19810617=> 500, 19990501=>-900,
>>	20211021=>-300, 20261125=>-1100, 20280210=> 700, 20320425=> 600,
>>	);
>>
>>
>>static $notminus = array(19651024=>1); // do not minus
>>static $notleap =
array(1965925=>1,1985121=>1,1985220=>1,20331222=>1,2034219=>1);
>>static $dominus = array(1985121=>1,1985220=>1,20331222=>1,2034219=>1);
>>
>>
>>이부분을 입력된 년도를 기준으로 계산하는방식이
 되면 특별히 쥴리어스력으로

>>전체 소스구조가 바뀌지 않아도 가능해보이긴합니다만
 .. 제가 멀 알아야죠 -_-;;
>>
>>해당 함수에 지정되어 있는 배열값의 년도뒤에 날짜인거
같은데 
>>이게 무슨 날짜인지 왜 저 날짜가 되어 있는지
모르겠네요..
>>
>>저부분도 계산으로 처리하는 방식만 되면 무난히 음양력도
2038년 제한을 넘어 가능해질듯 보여집니다.
>>
>>(현재 프로그램의 정확도를 떠나서 기간제한을 넘어
실행가능한 수준의 의미로요..)
>>
>>
>>
>>빠른 답변, 감사드립니다. ^^;
>>
>>
>>ps : 
>>문외한으로서
 답하는거니 어처구니 없어도 이해해주세요..

>>음양력이나 별다른 결과가 동하지 않는
달력으로서는
>>
>>아무런 계산없이 단순 for 방식만으로 무한으로 가능하지 않나
싶은데요??
>>물론 천문적인 계산방식이 아닌 단순 알고리즘
개념으로요.
>>
>>단순히 해당 월이 30일인지 31일인지만 알면 양력달력으로는
 무한이 가능할듯 싶습니다.
>>
>>천년단위로 각1월이 30일인지와 윤년이 몇번째 인지만 배열로
정해놓으면 될듯싶은데요.
>>
>>그리고 그정보를 바탕으로 for 돌리면 양력 달력은 무한
출력이 되지 않을까 
>>
>>가벼운 생각해봅니다 -_-;;
>>
>>
>>
>>[산이]님이 남기신 글:
>>
>>>[인철]님이 남기신 글:
>>>
>>>>-----------------------------------------
>>>>답변자가 기본적으로 참고할 내용입니다.
>>>>- 배포판(옵션)    : 
>>>>- 커널버전(옵션)
  : 
>>>>- 데몬버전(예:apache
 1.3.27) : 
>>>>- 데몬설치유형(RPM/컴파일/기타)
 : 
>>>>-----------------------------------------
>>>>*스팸필터링:한글
 4자(8개 문자) 이상 없으면 스팸페이지로 이동합니다.
>>>>
>>>>
>>>>http://linuxchannel.net/docs/lunar.txt
>>>>글을 읽고 소스도 보았습니다.
>>>>
>>>>32bit 정수 자릿수 문제때문에 mktime 제한 때문에 2038년으로
제한 하신거 같습니다.
>>>>
>>>>첨부한 파일을 include 하고 나서
>>>>
>>>>class.solar.php 
>>>>class.lunar.php 소스내용중 해당 php 명령을 교체하면
>>>>
>>>>제한을 넘어서 가능해집니다.
>>>>
>>>>양력 > 음력 변환에서 입력한 년도가 안되는군요..
>>>>2038 이하의 년도만 음력 변환이 됩니다.
>>>>절기는 2038년 이후도 잘 표시됩니다.
>>>>음력변환부분에
 고정이 된거 같습니다.
>>>>
>>>
>>>위의 2개의 파일은 내부 기본 로직은 unix_timestamp
입니다.
>>>따라서 Unix/Linux 에서는 1901 ~ 2038 까지만 가능합니다(32
bits).
>>>
>>>이것을 확장가능하게 끔 하려면
>>>
>>>http://ftp.linuxchannel.net/devel/php_calendar/class.calendar.php
>>>(이건 달력인데 먼 과거나 먼 미래까지 표시됩니다, 음-양력
변환 없음)
>>>
>>>이것처럼 unix_timestamp 을 완전히 버리고 JD(Julian day)로 그 기본
로직을 바꿔야합니다.
>>>
>>>그런데
>>>음력<->양력
 변환은 원론적인 설명부터 해야하는데...
>>>
>>>우선 태양 - 지구 - 달이라는 천체의 운행(역학)에 기반을
두고 있습니다.
>>>때문에 역학에 대해서 아주 전문적인 지식없이 구현하기가
상당히 어렵습니다.
>>>
>>>또한 정해진 공식도 없고, 정확한 태양 - 지구 - 달의 위치를
계산하기 위해서는 미해군 슈퍼컴퓨터로 계산하고 있다고
합니다. 우리는(한국 천문연구원) 이 data 를 받아서 달력을
만든다고 합니다.
>>>
>>>그리고 또한 천체의 위치계산시 중요한 data 변수가 있는
"delta T"가 바로 그것입니다. 이는 오르지 관측을
통해서만 그 값을 구할 수 있다고 합니다.
>>>
>>>따라서 먼 미래의 음력<->양력 변환은 사실 그 의미가
없습니다. 즉 delta T 때문이죠.
>>>(변환한다고 해도 틀릴 확률이 매우 높음)
>>>
>>>여차여차 해서 제가 만들어 놓은 것은 원리를 깨우쳐가면서
안돌아가는 머리로 겨우 근사식으로 짜놓은 것이고 오차
때문에 날짜 보정해 놓은 것입니다.
>>>
>>>만약
>>>
>>>위의 2개의 class를 unix_timestamp 가 아닌 JD를 기반한 로직으로
수정하면 어찌되었든 음력<->양력 변환은
가능합니다.
>>>
>>>그런데 오차가 상당히 심하기 때문에 별 신뢰성이
없습니다.
>>>
>>>이것을 수정할려고 올초에 작심했다가 그만뒀습니다. 당시
너무 힘들게 코딩했기 때문에 수정하려면 머리털 다 뽑힐까
봐서... :)
>>>
>>>
>>>
>>>>또한 2038을 한계로 잡고 절기 간격을 평균을 정해놓으셔서
괜찮았는데..
>>>>
>>>>3000년이상 넘어가면 기준으로 잡힌 년도와 멀어져서 점점
간격이 벌어지네요..
>>>>
>>>
>>>이건 앞서 얘기했듯이 delta T 또는 근사식때문에 어찌할
방법이 없습니다.
>>>(미해군 슈퍼컴퓨터를 크래킹하지 않고서는 ㅠㅠ)
>>>
>>>
>>>>입력한 년도를 기준으로 - 50년치를 자동으로
절기간격평균을
 재설정해서 처리하면 조금 나아질까요??
>>>>
>>>
>>>획기적인 방법이나 계산식을 누가 만들지 않고서는
힘들겁니다. 천문학 전공한 사람이라면 아마 가능할지도...(전
 천문학 근처도 가보질 않아서 ㅠㅠ)
>>>
>>>JD2000.0 기준이기 때문에 앞뒤 100년 정도가 비교적 맞고 그
범위를 넘어서면 상당히 틀어집니다.
>>>
>>>평균치 계산법은 구글에서 "진짜만세력"
 검색해보면 참고가 될듯합니다.
>>>(아마 소스가 있을 듯)
>>>
>>>
>>>
>>>>문외한이라 생각나는게 별루 없네요..
>>>>
>>>>
>>>>
>>>>어느부분을 수정해야 하는지 알고 싶습니다.
>>>>
>>>>가능하면 첨부 파일을 이용하여 수정된 소스를 바라면 너무
욕심일까요 -_-;;
>>>>
>>>
>>>unix_timestamp -> JD 기반으로 언젠가 고쳐야하는데 ㅠㅠ
>>>...
>>>
>>>첨부한 ADOdb 는 외국사람이 만든것 같은데 맞나요?
>>>이건 음력<->양력 변환은 없네요.
>>>
>>>http://ftp.linuxchannel.net/devel/php_calendar/
>>>이것과 비슷해 보입니다.
>>>
>>>
>>>참고로,
>>>
>>>http://ftp.linuxchannel.net/devel/php_solar/
>>>http://ftp.linuxchannel.net/devel/php_lunar/
>>>http://ftp.linuxchannel.net/devel/php_calendar/
>>>
>>>
>>>php_solar 는 태양의 위치, 절기, 일출 계산, 별자리계산
등등
>>>php_lunar 는 음력<->양력 변환, 일월식, 별자리 등등
>>>php_calendar 는 달력과 날짜 표시(먼 과거, 미래
표시가능)
>>>
>>>그리고 각 소스위 코멘중에서 [demo] 나 [docs] 링크 따라가면
해당 내용을 볼 수 있습니다.
>>>
>>>그런데 혹시 kldp 에 활동하고 계신분인가요?
>>>어떻게 해서 이런것에 관심을 가지게 되었는지 여쭈어보고
싶네요.
>>>
>>>
>>>>읽어봐주셔서
 감사드립니다. 
>>>
>>>======================================== 
>>
>>======================================== 
>
>======================================== 

========================================

 
이전글 : Re: Re: Re: class.lunar.php 문의
다음글 : Re: Re: Re: Re: Re: class.lunar.php 문의  
 from 59.4.44.1
JS(Redhands)Board 0.4 +@

Re: Re: Re: class.lunar.php 문의 Re: Re: Re: Re: Re: class.lunar.php 문의
인쇄용 


apache lighttpd linuxchannel.net 
Copyright 1997-2026. linuxchannel.net. All rights reserved.

Page loading: 0.02(server) + (network) + (browser) seconds