근데 걍 어디까지가 유사한거고 어디까지가 다른건지가 애매해.. 결국 같은 문제 풀고 같은 답을 내야하는데 차이날수있는게 그렇게 많나? 같은 언어에서. 물론 꼬고 이상하게 짜면 되겠지만 그런짓 할 이유가 없고... 최적화된 코드로 내면 서로 차이나는건 변수명 밖에 없을거같은데 ㄷ
루-트(203.128)2016-10-19 03:58
속이기 위한 많은 방법이 있음, reverse, interleaving, scaling, rotation.
codesafer(codesafer)2016-10-19 03:59
이건 DRM 과, 컨텐츠의 공격 보호 문제랑 같은 맥락임.
codesafer(codesafer)2016-10-19 04:00
그런것들은 시멘틱 상으로도 차이나니깐 괜찮은데 지금 말하는건 과제제출할때 같은 코드
루-트(203.128)2016-10-19 04:01
웅 과제검사용... 난 특허검사용을 생각한것.
codesafer(codesafer)2016-10-19 04:01
과제 검사는 만들기 쉽지 뭐.
codesafer(codesafer)2016-10-19 04:02
몇페이지 전에 셈이콜론이 바이오인포메틱 을 이용한 코드 유사도 검사 있길래 갑자기 궁금해진거
루-트(203.128)2016-10-19 04:02
지금 있는 코드 검사기들은 내가 말한 문제점들때문에 시멘틱이 아니라 걍 패턴매칭인거같아서
루-트(203.128)2016-10-19 04:03
label 들을 사용순서로 네이밍 일반화해서 레벤슈타인 거리를 구하면 됨.
codesafer(codesafer)2016-10-19 04:03
블럭 심볼 정도만 일반화 시켜주면 끝.
codesafer(codesafer)2016-10-19 04:03
난 항상 느끼는거지만 정말 똑똑한듯 ㅠㅠ
codesafer(codesafer)2016-10-19 04:04
지금 생각나는건 걍 원론적으로 접근해서 AG/동적시멘틱등을 최대한 확장시켜주는 중간 처리기(JVM같은거)에 소스를 넣고 돌려보는것. VDL만큼 복잡하게 해서 세세하게 따지면 좀더 의미있게 유사도검사가 가능하지않을까.. 코드에서 패턴을 찾으려는게 아닌
루-트(203.128)2016-10-19 04:05
웅 그럴 필요 없어.
codesafer(codesafer)2016-10-19 04:06
대부분의 숙제는 절차적 문제야. 즉, 흐름 제어가 들어가느냐 마느냐야.
codesafer(codesafer)2016-10-19 04:06
함수든 for 문 블럭이든 다 일단 인라인화해.
codesafer(codesafer)2016-10-19 04:06
그리고 무조건 블럭으로 싸줘.
codesafer(codesafer)2016-10-19 04:07
사용된 label 단어들을 a b c d 이렇게 사용순서로 늘어놓아.
codesafer(codesafer)2016-10-19 04:07
그러면 전체가 스트링 하나가 됨.
codesafer(codesafer)2016-10-19 04:07
for 문 while 문 do while 문은 do while 로 일반화함. switch 는 if else 로 일반화 함.
codesafer(codesafer)2016-10-19 04:07
그런 뒤 흐름 제어문도 동일하게 하나의 토큰을 할당.
codesafer(codesafer)2016-10-19 04:08
그럼 코드가 a { b c d { d + b; a + b } } ... 이런식의 연속문자열이됨.
LCS 말하는거 아님? a b c d e 랑 a d b e c 있을때 공통부분 a b c d e 다 있으면 100% 배낌 이런 식으로
루-트(203.128)2016-10-19 04:41
그건 좀 비효율적. pangram 을 살짝 끼얹어주면 재밌음.
codesafer(codesafer)2016-10-19 04:41
니가 나더러 알고리즘 보잘것 없잖? 처럼 말했지만 보통 사람들이 넘볼 수준은 아니올시다임.
codesafer(codesafer)2016-10-19 04:42
내가 사실 문제점 2를 너무 간추려 말했는데 d라는게 있으면 과제 수준에서는 d' 또는 아예 다른 f 로도 매칭시킬수 있음. 그래서 동적시멘틱을 쓰려고하는거
루-트(203.128)2016-10-19 04:42
효과적으로 일반화시켜야돼. 더 단순하게 생각해용.
codesafer(codesafer)2016-10-19 04:43
카메라 영상이 있다쳐. 니가 움직임 감지 보안카메라를 만들고 싶거든?
codesafer(codesafer)2016-10-19 04:44
조명조건 (일광 이나 인공조명) 하에서 확확 변하는 픽셀들은 뭘까?
codesafer(codesafer)2016-10-19 04:44
반사형 재질임. 거울이나 유리 같은거.
codesafer(codesafer)2016-10-19 04:44
전반사와 난반사가 있으면, 난반사는 일정하게, 전반사는 각도에 따라 제각각이 되는거.
codesafer(codesafer)2016-10-19 04:44
그러면 화면에서 가장 동적인 부분은 시불 이거 거울이나 금속 따위네. 라고 정의할 수 있는거지.
codesafer(codesafer)2016-10-19 04:45
소스코드에서 동적인 부분을 제거하고 가장 정적인 부분 순으로 늘어놓으면 뭔가 답이 보이겠지?
codesafer(codesafer)2016-10-19 04:45
좀 자세히 생각해야함. 두 코드 패턴이 유사한지 따질수 있는 방법이 AG등을 이용한 정적시멘틱이랑 코드트레이스 자나. 실제로 리턴(출력)하는 변수는 뭐고 이런식으로.. 근데 내가 지금 딱히 예시를 직접 내놓으라면 생각이 안나는데 과제 코드 보면 정적시멘틱이나 코드 돌아가는거 보고 심볼 뭐가 쓰이네 이런거 보는걸로는 못잡는 차이도 많음. 그러니 이런 런타임 자체의 시멘틱을 찾는 동적시멘틱들로 처리하자 이게 내 핵심
루-트(203.128)2016-10-19 04:49
니가 지금 이동표적 사격을 하고 있는데,
codesafer(codesafer)2016-10-19 04:51
과제 카피 정도는 위에 언급된 방법론으로 다 커버되고 남아.
codesafer(codesafer)2016-10-19 04:51
codesafer//쓰여졌->쓰였 (이중 피동) [리듬 맞춤법 봇♬]
익명(49.174)2016-10-19 04:51
내 오랜 경험상, 동적 요소가 많이 추가되면 그 프로젝트는 결국 끝이 안나. 정적으로 풀어야됨.
codesafer(codesafer)2016-10-19 04:51
물론 DP 같은걸 동적이라 정의한건 아님 그건 정적이지.
codesafer(codesafer)2016-10-19 04:52
커피 한 잔 타고 5분 뒤 일하러 ㅠㅠ
codesafer(codesafer)2016-10-19 04:54
패턴인식을 생각하는것 같아서 말인데,
codesafer(codesafer)2016-10-19 04:55
특징점 추출로 가는 이유는, 나머지가 동적이기 때문이야. 위에서 말한 반사재질 이야기랑 상통하지.
codesafer(codesafer)2016-10-19 04:55
문제는 동적 요소의 배제에서 출발해야지, 동적 요소의 수용으로 들어가면 절대 안풀림.
codesafer(codesafer)2016-10-19 04:55
니 코드 스트럭쳐에서 동적요소를 넣는다면 정말 딱 한 두곳, 논리상 아주 유연해야하는 관절 부위에 넣어야 하는것.
codesafer(codesafer)2016-10-19 04:56
사람이 지금의 뼈와 연골 구조를 얻게 된건 수 많은 합리적 선택의 과정입니다.
codesafer(codesafer)2016-10-19 04:57
뼈를 잘 만들면 일단 로보트인척 하는거. 그러면 대부분의 일을 시킬 수 있음.
codesafer(codesafer)2016-10-19 04:57
뭐 안드로이드급으로 승화시켜서 ㅅㅅ 를 하고 싶다면 좀 더 고민해야 될 부분이 많아지는데 피부 ( interface ) 를 제외하면 당연하지만 부드러워야 하는 부분은 관절 정도란거.
codesafer(codesafer)2016-10-19 04:59
@codesafer : 위에 언급된 논문과 유사한 접근으로 나무를 희생시킨 사람으로써 말하자면;; 바이오인포메틱스를 이용한건 저 사람들도 편집거리니 그런거 몰라서 그런거 아님. 저쪽은 단순 유사도 검사보다 저런 유전체 fingerprint같은걸 얻어다가 기존에 잘 개발된 바이오인포매틱스툴로 유사한 개체들간의 가계도(?)를 만들어서 성향을 - dc App
troublecoder(troublecoder)2016-10-19 07:23
보려고한거임. 저는 염기서열만으로는 전혀다른데 간단한 코드에서는 유사하게 나오는 문제 혹은 반대 때문에 gcc의 중간 언어인 gimple에다가 단백질서열을 매핑해서 좀 더 정확도를 올림. 어째튼 최종 목표가 단순 편집 거리가 아니라 blas였나?그런걸로 추출된 지문들 넣고 가계도를 얻기 위해서임. - dc App
그게 잘 되면 최적화 신경쓸 필요 없이 알고리즘에만 집중하면 되겠지~
향후 15년 안엔 답없어보임
근데 걍 어디까지가 유사한거고 어디까지가 다른건지가 애매해.. 결국 같은 문제 풀고 같은 답을 내야하는데 차이날수있는게 그렇게 많나? 같은 언어에서. 물론 꼬고 이상하게 짜면 되겠지만 그런짓 할 이유가 없고... 최적화된 코드로 내면 서로 차이나는건 변수명 밖에 없을거같은데 ㄷ
속이기 위한 많은 방법이 있음, reverse, interleaving, scaling, rotation.
이건 DRM 과, 컨텐츠의 공격 보호 문제랑 같은 맥락임.
그런것들은 시멘틱 상으로도 차이나니깐 괜찮은데 지금 말하는건 과제제출할때 같은 코드
웅 과제검사용... 난 특허검사용을 생각한것.
과제 검사는 만들기 쉽지 뭐.
몇페이지 전에 셈이콜론이 바이오인포메틱 을 이용한 코드 유사도 검사 있길래 갑자기 궁금해진거
지금 있는 코드 검사기들은 내가 말한 문제점들때문에 시멘틱이 아니라 걍 패턴매칭인거같아서
label 들을 사용순서로 네이밍 일반화해서 레벤슈타인 거리를 구하면 됨.
블럭 심볼 정도만 일반화 시켜주면 끝.
난 항상 느끼는거지만 정말 똑똑한듯 ㅠㅠ
지금 생각나는건 걍 원론적으로 접근해서 AG/동적시멘틱등을 최대한 확장시켜주는 중간 처리기(JVM같은거)에 소스를 넣고 돌려보는것. VDL만큼 복잡하게 해서 세세하게 따지면 좀더 의미있게 유사도검사가 가능하지않을까.. 코드에서 패턴을 찾으려는게 아닌
웅 그럴 필요 없어.
대부분의 숙제는 절차적 문제야. 즉, 흐름 제어가 들어가느냐 마느냐야.
함수든 for 문 블럭이든 다 일단 인라인화해.
그리고 무조건 블럭으로 싸줘.
사용된 label 단어들을 a b c d 이렇게 사용순서로 늘어놓아.
그러면 전체가 스트링 하나가 됨.
for 문 while 문 do while 문은 do while 로 일반화함. switch 는 if else 로 일반화 함.
그런 뒤 흐름 제어문도 동일하게 하나의 토큰을 할당.
그럼 코드가 a { b c d { d + b; a + b } } ... 이런식의 연속문자열이됨.
http://gall.dcinside.com/board/view/?id=programming&no=640794&page=3
이거랑 비슷한 패턴매칭아님?
두개의 연속문자열, 즉 두개의 스트링을 levenshtein 거리를 구하면,
삽입이 몇갠지 삭제가 몇갠지 수정이 몇갠지 거리값이 딱 나와.
응 비슷한데 저걸 뭐 논문까지 쓰나 암산으로 뚝딱 되는거.
추가를 한다면 생성과 삭제에 대한 표현 정도만 넣으면 거의 완벽.
원래 논문이라는게 거창한게 아니잖음ㅇㅇ
이런 옵션들을, 넣었다 뺐다 하면서 몇 가지의 거리점수를 내면 됨~ 그럼 충분한 판단 기준이 되지.
2002년 당시치고도 좀 뒷북치는 느낌인데 서베이같은거아니였을까
학위논문이나
응용 논문수준인듯. 걍 뭐 유치함.
저기서 내가 말한 DRM 공격에 대한 방어기법에 대해 일반화하면 완전 이거 뭐 논문감이지.
저런 방식들이 문제가 1. 진짜 생각하는게 같아서 변수명빼고 비슷하게 나오는 경우도 잡음 / 2. 과제에 한정해 대다수의 문제가 코드 순서를 섞어버려도 가능한경우가 많음. 이 두가지인데
위에 말한 확장AG/동적시멘틱은 1번은 못해결할거같고 2번은 해결가능해보여서
레벤슈타인 거리 함 돌려보면 감이 올거양. 정말 일반화된 거리가 나옴. 키키.
단순 하향식 파서 하나 만들어서, 비실효성 토큰들 걸러내고 실행순서로 정렬시키면 과제 정돈 그냥 개껌 잡아낼듯.
루-트//아니였->아니었 (아니었 아니에요 아니어도 아니어서는 예외) [리듬 맞춤법 봇♬]
패턴이 a b c d e 인 코드에서 함수 렉심이 f 라고 할때 f에 c d 를 담아서 a b f <param> e 라고 해도 소스를 확장시켜서 인라인화 하면 a b c d e 로 돌아옴
꽤 수작업을 많이 떨어서 코드 늘리고 생 쑈 해봐야 아무 소용없이 탈탈 털림.
그게 저 논문이나 코세가 말하는 부분의 일부분인데 그런건 지금 시중에 많고 난 좀더 원론적으로 접근해보고 싶은것. 딱히 지금 예시를 들라니 못적겠긴한데 과제수준의 코드는 코드 몇개 순서 섞어서 패턴을 잡을 수 없게 해도 풀려질 수준의 문제가 많음
unroll 도 루프로 바꿔버리면 되거든.
저 논문 어디까지 쓰여졌는지 모르겠지만 뭐 내가 생각하는 수준 미만일껄?
쓸데없는 코드를 지우는건 현재도 기본적인 기본적인AG/심볼테이블 연동으로도 하긴해서 사실 나도 지금 이게 얼마나 의미가있을진 모르겠다
그니까 이문제는 간단해, 그냥 단순 두 문자열의 거리 비교거든.
소스 compare 같은건 글자 하나 차이까지 잡아내니까 약간 일반화 하면 된다는거고.
바이오인포메틱스에서 가져온게 아니라 걍 문자열 비교에서 바이오로 간거지. ㅋㅋ
그걸 바이오에서 가져왔다고 하는 컨셉 자체가 그냥 뭐... 아 응... 뭐 잘 모르는 애들이군. 이런 느낌.
레벤슈타인 거리에서 abcde 랑 acdbe는 편집거리 4 아냐?
그런건 못잡지않나?
응 못잡지. 그래서 순서상 동치관계에 놓인건 대수 문자 하나로 정의해야함.
절차적이라니깐. ㅋㅋ 그것만 집중하면 됨.
내가 옵션을 넣었다 뺐다 해서 몇 개의 거리값을 얻어야 한다고 한게 그런 이유.
순서상 동치관계에 놓인다는거의 판별 그런거에서 이제 동적시멘틱이 쓰일수있는거같은데 지금 같은 방법에선 잡아낼수있는 방법이있음?
동적 시멘틱까진 필요없고, 과제 검사 정도에선 최장 동일 문자열로 향하는 부분수열의 배열만 뽑아내면 됨.
응 알아. 마크로젠 이란 회사랑 친함.
맨날 유전자 염기서열 DB 꾸리고 매칭하는 애들임.
일단 지금은 나 하는거 하고 나중에 시간날때 그림으로 그려봐야지
저 최장 동일 문자열로 향하는 부분수열 조합은,
예전에 ㅅㅅㅅ 랑 나랑 장난치면서 만들어 낸 코드를 활용하면 좋아.
http://cafe.daum.net/codeinside/b8FO/24
앙 거기 CTO CFO 다 앎 ㅋㅋ 개발자까지.
CFO 랑 같이 다른 외국계 회사 다녔었걸랑.
LCS 말하는거 아님? a b c d e 랑 a d b e c 있을때 공통부분 a b c d e 다 있으면 100% 배낌 이런 식으로
그건 좀 비효율적. pangram 을 살짝 끼얹어주면 재밌음.
니가 나더러 알고리즘 보잘것 없잖? 처럼 말했지만 보통 사람들이 넘볼 수준은 아니올시다임.
내가 사실 문제점 2를 너무 간추려 말했는데 d라는게 있으면 과제 수준에서는 d' 또는 아예 다른 f 로도 매칭시킬수 있음. 그래서 동적시멘틱을 쓰려고하는거
효과적으로 일반화시켜야돼. 더 단순하게 생각해용.
카메라 영상이 있다쳐. 니가 움직임 감지 보안카메라를 만들고 싶거든?
조명조건 (일광 이나 인공조명) 하에서 확확 변하는 픽셀들은 뭘까?
반사형 재질임. 거울이나 유리 같은거.
전반사와 난반사가 있으면, 난반사는 일정하게, 전반사는 각도에 따라 제각각이 되는거.
그러면 화면에서 가장 동적인 부분은 시불 이거 거울이나 금속 따위네. 라고 정의할 수 있는거지.
소스코드에서 동적인 부분을 제거하고 가장 정적인 부분 순으로 늘어놓으면 뭔가 답이 보이겠지?
좀 자세히 생각해야함. 두 코드 패턴이 유사한지 따질수 있는 방법이 AG등을 이용한 정적시멘틱이랑 코드트레이스 자나. 실제로 리턴(출력)하는 변수는 뭐고 이런식으로.. 근데 내가 지금 딱히 예시를 직접 내놓으라면 생각이 안나는데 과제 코드 보면 정적시멘틱이나 코드 돌아가는거 보고 심볼 뭐가 쓰이네 이런거 보는걸로는 못잡는 차이도 많음. 그러니 이런 런타임 자체의 시멘틱을 찾는 동적시멘틱들로 처리하자 이게 내 핵심
니가 지금 이동표적 사격을 하고 있는데,
과제 카피 정도는 위에 언급된 방법론으로 다 커버되고 남아.
codesafer//쓰여졌->쓰였 (이중 피동) [리듬 맞춤법 봇♬]
내 오랜 경험상, 동적 요소가 많이 추가되면 그 프로젝트는 결국 끝이 안나. 정적으로 풀어야됨.
물론 DP 같은걸 동적이라 정의한건 아님 그건 정적이지.
커피 한 잔 타고 5분 뒤 일하러 ㅠㅠ
패턴인식을 생각하는것 같아서 말인데,
특징점 추출로 가는 이유는, 나머지가 동적이기 때문이야. 위에서 말한 반사재질 이야기랑 상통하지.
문제는 동적 요소의 배제에서 출발해야지, 동적 요소의 수용으로 들어가면 절대 안풀림.
니 코드 스트럭쳐에서 동적요소를 넣는다면 정말 딱 한 두곳, 논리상 아주 유연해야하는 관절 부위에 넣어야 하는것.
사람이 지금의 뼈와 연골 구조를 얻게 된건 수 많은 합리적 선택의 과정입니다.
뼈를 잘 만들면 일단 로보트인척 하는거. 그러면 대부분의 일을 시킬 수 있음.
뭐 안드로이드급으로 승화시켜서 ㅅㅅ 를 하고 싶다면 좀 더 고민해야 될 부분이 많아지는데 피부 ( interface ) 를 제외하면 당연하지만 부드러워야 하는 부분은 관절 정도란거.
@codesafer : 위에 언급된 논문과 유사한 접근으로 나무를 희생시킨 사람으로써 말하자면;; 바이오인포메틱스를 이용한건 저 사람들도 편집거리니 그런거 몰라서 그런거 아님. 저쪽은 단순 유사도 검사보다 저런 유전체 fingerprint같은걸 얻어다가 기존에 잘 개발된 바이오인포매틱스툴로 유사한 개체들간의 가계도(?)를 만들어서 성향을 - dc App
보려고한거임. 저는 염기서열만으로는 전혀다른데 간단한 코드에서는 유사하게 나오는 문제 혹은 반대 때문에 gcc의 중간 언어인 gimple에다가 단백질서열을 매핑해서 좀 더 정확도를 올림. 어째튼 최종 목표가 단순 편집 거리가 아니라 blas였나?그런걸로 추출된 지문들 넣고 가계도를 얻기 위해서임. - dc App