|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
처리가 제대로 되지 않는 조건 (수평, 수직 혹은 대각선 처럼 세 점이 하나의 기울기를 갖는 경우) 에선 반지름을 0이 되게 처리했기 때문에 예외처리에는 문제가 없다고 생각합니다.
습관적으로 bool 을 리턴하는 코드는 의미없는 예외처리를 강요하게 되는 경우에 해당하죠. 좌표계상에서의 원의 중심 좌표는, 0도 될 수 있고 무엇도 될 수 있습니다만, 반지름은 0이 아니길 기대하죠. 만약 그렇다면 인자의 세 점의 좌표가 하나의 점이었다는걸 의미하니까요. 그렇지 않은 상황에서 반지름이 굉장히 작은 어떤 값을 갖게 될 경우, 이 함수를 이용하는 코드는 리턴값의 bool 을 통과했다 해도 예기치않은 연산결과를 낳을 수 있습니다. 가령, 후에 반지름을 다른 연산의 분모로 이용한다든지 하는 케이스가 예가 되겠죠. 애초에 반지름에 대한 예외처리가 필요하다면, 리턴값과 반지름에 대해 확인하게 만드는 코드 구조보다, 보다 의미 있는 반지름만의 확인에 집중하게 하는 편이, 쓸데없는 예외처리도 줄이고, 코드도 간단하게 만들며, 보다 무결성이 보장되는 코드를 만들도록 도와준다고 생각합니다. 이런 문제야 말로, 논쟁이 의미있는 부분입니다.
효과적인 프로그래밍에 관련된 논문들을 읽어보시면, 무의미한 예외처리나 NULL을 전달하는 파라메터에 유의하라는 경고들이 흔히 등장합니다. 아마도 그 회사에선 그것이 그닥 논외의 대상일런지 모르지만 말이죠. 개발자들 안에선 이미 "생각하고 사용해야 할 메서드들에 대해서는 생각하게 하자"는게 상식으로 통한다고 생각되네요. 그리고 애초에, 잘만드셨네요. 제대로 나왔는지 안나왔는지를 알아야 하니까요 라고 말씀하신 부분과, 예외처리에는 문제가 없습니다. 쓸모없는 논쟁일것 같네요. 란 말씀은 상충되고 계신것 같군요. 전 위의 덧글에서 분명히 예로 들었습니다.
이 함수를 수행한 결과가 반지름이 0가 될때의 가져다 쓰는쪽에서 논리적으로 발생하게 될지 모르는 문제들에 대해서 말이죠. 또한, 크레브님의 말을 빌자면 거의 모든 함수 호출은 bool 을 가져야 한다는건데, void 형 함수는 왜 존재하는 것일까요? 또, bool 타잎의 리턴을 강제하는 코드들에서 결과가 true가 나왔을때의 결과를 100% 신뢰할 수 없다면 그게 의미 있는 행위일까요? 엎어치나 매치나 하는 문제면 왈가왈부의 의미가 없음이 분명하겠지만, 이 코드를 가져다 쓰는 사람들은 예외처리 하나가 줄게 됨이 분명하고, 함수를 implementation 하는 입장에서도 의미없는 true false 를 return 하는것 보다, 최소한 타이핑 몇 번은 줄게 되는 것 같군요. 객체화가 중복과 무의미한 엔트로피의 소거에서 출발한다면, 잘 모듈화된 함수화 역시 무의미한 엔트로피의 소거가 필요한게 아닐까요? 애초에, 결과로 r 이 0 이 되는 경우는 원을 구성할 수 없는 인자가 전달된 경우다. 라고 명시했다면 이런 이야기가 시작 되지도 않았겠죠 : ) 몇 줄 되지도 않는 코드에 주석이 필요한가 라는것도 단순한 아집일지 모르구요. 생각하고픈 사람들은 생각하고, 무시하고픈 사람들은 무시할 수 있는 계기가 되었으면 다행이라고 생각합니다 : ) 앞서 크레브님이 올리신글과 덧글에서,
오류가 있으면 알려달라는 말씀에 제가 생각하는 바를 인터렉션하자는 취지에서 작성된 함수와 덧글들일 뿐이구요, 오래전에 작성한 코드고 굳이 개선할 필요를 못 느껴 써 오고 계신다는 상황은 bool 을 리턴하거나 말거나의 문제보다 보다 심각해 보입니다. 재사용 가능한 Core 함수일수록 고찰이 필요함이 당연한 것이구요. 작업하고 계신파트가 어느정도 성능에 free 한 환경이실런진 모르지만, 아래의 글이 단지, 원의 방정식을 가우스 소거법으로 유도해보았습니다. 정도가 아니라, 사용하고 계시다면, 흠좀무 한 상황이라고 느껴지네요. 이렇게 말하고 나니 뭐 저 코드가 굉장히 잘 만들어진 코드다 라고 말하는 것 같은데,
double 형의 표현범위에 대해 생각하고 연산순서에 대한 튜닝을 한다면 저것보다 4배 더 정확한 코드도 나올 수 있겠죠. 그런 코드를 누가 올려주신다면, 아이고 감사합니다. 할 지경입니다. 저도 이런 함수를 쓰게 되는 날이 올지도 모르고 말이죠. 크레브님이 올려주신 코드에서 누군가가 아주 유용하게 가우스 소거법 부분만 뜯어내서 쓰게 되실지도 모릅니다. 하지만, 핵심인 원의 방정식을 구하는 문제에 있어선 먼 길을 돌아간 코드이기에 성능이건 정확도건 비교할 수 없는 상황임에 분명하고, 빠른 성능과 정확도를 필요로할 많은 연립방정식, 다항식의 계수를 구하거나 회귀분석을 하려는 경우는 아래에 표현된 가우스 소거법보다는 처리 성능이 고려된 Gauss Jordan 이나 Gauss Seidel 의 robust한 형태의 변종 기법들이 사용되겠죠. 원의 방정식을 수백만번 구하는 용도가 아니라면 속도 차이는 크게 이슈가 아니나...
Nibble님이 훨씬 깔끔하게 만드신 코드를 올렸으니.. 다음에 쓸일이 생기면 감사히 잘 쓰겠습니다. 다만 bool 리턴 방식에 대한 얘기는 처음 생각대로 그렇게 의미있는 논의는 아닌것 같네요. 위와 같은 함수를 초보개발자들도 쓸 수 있기 때문에 bool 리턴 방식을 여전히 선호합니다. 예외처리의 용도로 r에 0을 넣었다고 생각하지 못하는 개발자들도 있겠죠 오히려 정상적인 경우에 r이 0에 너무 가까운 값이 나올게 걱정이라면 그 조건을 체크해서 false를 리턴하면 됩니다. 아이러니하게도 저는 크레브님의 방법을 봤을 때 중학교 수준의 산수가 생각나서 작성했던 것이라죠.
상충된다고 한 것은, 여러가지 의미가 있습니다. 위 아래 뿐만아니라 같은 녀석들 안에도 미묘한 부분이 있으니까요. 코드를 주마간산격으로 본다든지, 쓸모가 없는 논쟁같다면서 굳이 토를 달고계신 모습이 말이죠. 아직 개념을 못 잡으신 것 같은데, 비교를 하려면 if (Get3PointCircle(.., r)){ .... if (r > 0) axx = axx / r; else... } 와, Get3PointCircle(..,r); if (r < MIN_THRESHOLD) ... 를 비교하셔야죠. 비단 r이 단독으로 분모로 쓰이는 경우뿐만 아니라, 다른 수식과 함께 쓰일때도 특정값 보다 작으면 오차값이 튀어오를 수 있지 않겠습니까? 그래서 double 연산의 0 처리는 공학에선 범위로 하도록 권장하고 있고 말이죠. 그렇다면 bool 방식은 초보 개발자들이 쓰고, r 방식은 초보자가 못 쓸 수준이란 말입니까? 넌센스네요. 주석까지 달아 놓으신 350줄 보단 이쪽 코드가 분석하고 오류찾기 쉬워보이는데 말이죠. 제가 위에서 "r이 0에 너무 가까운 값이 나올게 걱정이라면 그 조건을 체크해서 false를 리턴하면 됩니다." 라고 썼습니다만
남의 글은 제대로 안읽고 답글을 올리시니 할말이 없군요 제가 올린 코드가 350라인인지는 몰라도 제 코드가 분석하기 쉽고 오류찾기 쉽단 얘기는 한마디도 안했습니다. 왜 상관없는 말씀까지 하시는지 모르겠군요. 다른 모든 사람이 소스코드를 확인하고 쓰는가와 그냥 쓸 수도 있겠다의 관점 차이인데 뭘 그렇게 대단하게 하시는지 모르겠습니다. Nibble님이 쓴 방식이 초보자가 못쓸 수준 아닙니다! 그렇게 쓴 적도 없고요 단지 초보자가 실수 할 수 있는 가능성이 더 있다는 의미지요. 제일 위험한 경우는, bool 값이 false면 처리 안했으니 이 코드가 문제가 없다고 생각한 초보 프로그래머가 산술 연산상의 누적 오류로 황당체험을 했을 때 빠지는 혼란이라고 생각합니다.
또, 어떤 사람은 위의 코드 말미에 if (r < ~~) return false; 를 추가할 수도 있겠죠. 혹은 bool 이 아니라 오류 종류에 따라 친절히 enumeration 해서 에러코드를 리턴해 줄 수도 있겠죠. 문제는, 유효한 오차의 범위란것도 상대적이고, 어떤 경우엔 내가 강제로 cut off 해버렸지만 그걸 써야하는 사용자 케이스도 있고, 어떤 경우엔 내가 safe 처리 했지만, 그 오차때문에 정상 작동을 못하는 경우가 있다는거죠. threshold를 누가 판단해야 하느냐는 사용자측에 있다고 보는겁니다. 자 보세요. 그럼 이렇게 정리가 되죠. 오류냐 아니냐의 결과를 크레브님은 이진화 해서 리턴했습니다. 결국 결과값을 돌보기 위해 사용자는 r값을 care해야합니다. 반대로 제쪽에선 오류냐 아니냐를 r에 집중시켜 double 값으로 돌려준 셈이구요. 여러번 말씀드리게 됩니다만 어차피 결과값을 돌보기 위해선 r을 봐야 하니까요. 사용자에게 전해진 오류에 대한 엔트로피는 간결하게도 하나에 집중되어 있습니다. r은 r대로 둘 다 결과로 주게 되겠지만, 크레브님의 코드를 가져다 쓸 수 있는 사용자나 분야나, 시스템이 한정됨에 비해 제 코드는 확장성을 갖게 된다고 생각합니다. 오류냐 아니냐 판단을 크레브님이 내려버렸다면 크레브님이 사용하는 형태와 다른 사람들의 사용예에서는 오류라고 판단했음에도 값을 처리해야 하거나, 오류가 아니라고 판단했음에도 오류처리를 해야 하는 사태가 벌어질테니까요. 당연하게도 생화학적 분석이나 좀 큰 이미지 안의 많은 spot과 circle을 다루는 처리에 크레브님의 코드는 사용되어선 곤란할테고, 만약 하드웨어 성능으로 커버하려 든다면 사양이 올라가는건 자명한것이구요. 이거 뭐 MS도 아니고. 사실 크레브님은, 포럼안에서 활동도 왕성히 하고 계시고, 영양가 있는 글도 많이 올려주시는 분이라 생각하기 때문에
'부딪힐' 의도는 없었습니다. 좀 욱하는 부분도 있었지만 크레브님 아드님 사진도 눈에 어른거리고 해서 참은 구석도 있었구요. 뭐 어쨌거나, 우리 두 사람이 지금 나눴던 대화의 입장 어느쪽이 어느쪽이건 간에 진보와 보수로 구분해 본다면, 언젠가 다른 사람 앞에서 반대의 역할을 하게 될지도 모르죠. 중요한건, 생각하느냐 귀찮아서 대충 대충 하느냐의 차이 정도랄까요. 앞서 말씀드렸듯, 생각하고픈 사람들은 생각하고, 무시하고픈 사람들은 무시할 수 있는 계기가 되었으면 다행이라고 생각합니다 : ) 위의 함수를 소스 코드 형태가 아닌 dll이나 lib 처럼 바이너리로 제공한다면
헤더에서 void __fastcall Get3PointCircle(const TRealPoint* p, double& cx, double& cy, double& r); 를 본다면 따로 명시적 설명이 없는한 r에 0이 들어있을때 예외라는것을 판단하기 힘듭니다. 또한 명시적 설명이 있다해도 그것을 봐야 알 수 있는것이고요 bool __fastcall Get3PointCircle(const TRealPoint* p, double& cx, double& cy, double& r); 하지만 bool 리턴이 있다면 선언만 봐도 직관적으로 쓰는 사람이 판단 할 수 있다는겁니다. 저는 오히려 이런 점에 더 가중치를 줘야 된다고 생각합니다. 굳이 판단 기준이 애매하다면.. bool __fastcall Get3PointCircle(const TRealPoint* p, double& cx, double& cy, double& r, double dMinR=0.0001); 이렇게 해서 확장성 있게 해놓고 , 엄청 작은 r이 필요한 사람이 확장해서 쓸 수 있게 해도 되겠지요 하지만 그 정도까지의 필요성은 느끼지 못했습니다. 각자 개발 업무 영역이 다르니까 업무 내용에 맞게 함수를 만들면 될겁니다. 저 역시 주석이나 메뉴얼, 도움말 보다는 코드로 모든것을 말해야 한다는 철학을 갖고 있습니다.
하지만 그렇게 다 할 수 없는 부분도 분명히 존재는 하구요. 소스를 오픈하는 코드니 저렇게 했지, 패키징을 했다면 저 역시 그 부분에 대해 다르게 implementation 했을 수 있구요. 결과적으로, 조금은 소모성인 이 댓글 논쟁들로 인해 팁을 가져가는 분들도 있었으면 좋겠군요. 비단, 코딩 스타일이나 철학의 문제 뿐만 아니라, 각 분야에서 완고한 개발자들끼리의 대화방법에서 '이러면 안되는구나' 하는 나쁜 예를 통한 깨달음일지라도 말이죠. 한가지 아쉬운점은, 우리 처럼 통밥굴러가는 개발자들이라면 잘 짠 코드와 잘못된 코드를 척 보면 안다는 거죠. 잘 짠 코드라 생각되면 들여보게 마련이구요. 그럼에도 두 사람 다 서로의 코드를 별로 들여다보고픈 생각이 들지 않았다는 거겠지요 : ) 어차피 길어진 댓글 사족을 하나 더 달아봅니다.
upperThreshold 랑 lowerThreshold 를 인자로 던지지 않은것은, 스택 사용량을 줄이고, 인자를 전달하는 만큼의 cost를 절감하기 위해서였습니다. 성능에 영향을 미치니까요. 어떤 의미에선 인자로 전달되는 스택을 caller가 비우느냐 callee가 비우느냐 하는 문제와 비슷하게 보일런지도 모르겠지만, 적어도 성능에 있어선, 사용자가 r 을 care하는게 낫습니다. upperThresold 나 lowerThresold 둘 중 하나는 don't care일 수도 있고, 둘 다 don't care일 가능성도 있으니까요. 뭐 그런 취지란 겁니다. 정확하고 빠르고 코딩이 간단하면서도 일관성을 갖고 사용자를 설득할 수 있으면 된다는 입장인것이죠. Nibble//제가 쓸건 3점을 지나는 포물선이고, 그 중 한 점은 촛점이어야 합니다.
x좌표를 대입하면 y좌표가 나오는 식이면 좋을 것 같네요.. 아니, 거기서 더 나아가 시작점에서 끝점까지의 좌표를 모두 구하는 형식이 낫겠습니다. 저 밑에 905번인가 곡선그리는 소스를 보면 간격을 지정해주면 그 간격에 맞추어서 좌표를 모두 구해주더군요.. 아무리 공식을 알아도, 이걸 막상 소스로 구현하려니까 답이 안나오네요..ㅡ.ㅡ 원래는 sin, cos을 이용해서 대충 끼워맞춰서 구현했는데, 뭔가 궤적이 어색하더군요... 역시 포물선 공식을 제대로 대입해야겠더라고요.. 음....
위 함수에 한가지 다음과 같이 입력하니 값이 이상하게 나오네요 TDoublePoint p[3]; double cx,cy,r; p[0].x=0; p[0].y=0; p[1].x=0; p[1].y=0; p[2].x=5; p[2].y=5; Get3PointCircle2(p,cx,cy,r); ShowMessage(FloatToStr(r)); //r=5 이구 p[0].x=0; p[0].y=0; p[1].x=1; p[1].y=1; p[2].x=0; p[2].y=0; Get3PointCircle2(p,cx,cy,r); ShowMessage(FloatToStr(r)); //r=1 입니다. 세 점중 2점이 같으면, 그 두점을 지나는 원의 갯수는 무한대이므로.. 이경우에 대한 처리가 필요할것 같습니다. 관련 글 리스트
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
함수 리턴값을 bool로 하는게 사용하기에는 좋을것 같습니다.
결과가 제대로 나왔는지 안나왔는지를 함수를 쓰는 사람이 알아야 하니까요 ^^