블로그 이미지
.
속눈썹맨

공지사항

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

calendar

 이전 다음 2025.2
일 월 화 수 목 금 토
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28
티스토리 가입하기 RSS FEED
지식나누기

getconf -- display POSIX configuration information

2004. 7. 19. 15:23 | Posted by 속눈썹맨
displays the system configuration values for filesystem specific variables.

http://mirrors.ccs.neu.edu/cgi-bin/unixhelp/man-cgi?getconf+1
http://lugli.org.ar/pipermail/linux/1999-June/043528.html
http://www.opengroup.org/onlinepubs/009695399/utilities/getconf.html

$ rpm -qf /usr/bin/getconf
glibc-common-2.3.2-11.9
$
지식나누기

키워드 grouping(categorizing)하기

2004. 7. 16. 11:05 | Posted by 속눈썹맨
1. 글자를 backward로 적어서 sort한다.
예) 교학 -> 대학교, 중학교, 초등학교
     화관 -> 영화관, 메가박스영화관, CGV영화관

2. 숫자, 특수문자를 제외하고 sort의 key를 생성한다.
예) 렉슈 -> 슈렉, 슈렉2 ...
    영화의 속편들 같은 것이 잘 모이게 된다.
지식나누기

단어, 약어 추출하기

2004. 7. 16. 11:01 | Posted by 속눈썹맨
Algorithm

query-query에서 단어 추출하기

단어 자르기
1. query-query pair에서 각 pair의 길이가 한글 2글자 이상인 longest common substring을 찾아서 모은다.
예) (일본, 일본문화)  => 일본
     (일본역사, 미국역사) => 역사
2. 1에서 추출하고 남은 글자만 counting
3. 1, 2에서 각자 모든 단어후보들 중 상위만 취한다.

약어 찾기
1. sequence alignment 기법을 이용. (dynamic programming)
    (bioinformatics등에서 DNA 조각 맞추기 등에 사용)
2. alignment 후 common fragment만 comcatenation한다.
3. 한 string은 blank가 없고 다른 string은 blank가 없이 align되면 약어임.

예) 고려대학교, 고대 동문회
      고려대학교
      고__대____동문회
     => 결과 : (고려대학교, 고대)

약어 찾기2)
query-query가 있을 때 어떤 단어가 한 단어의 substring(order를 보존하면서 fragment를 모은 string)이면 약어일 가능성이 높다."

Query-Query의 장점
1. 유사한 단어 pair가 출현한다.
2. 웹문서를 분석하는 것에 비해 algorithm이 간단하고 data가 짧다.

단점
1. data의 양이 웹문서에 비해 적다.

다른 방법
1. 알바생들에게 모든 경우를 입력하게 만든다.
2. 이미 나와있는 약어, 동의어, 유의어(thesaurus) 사전을 구입한다.
   혹은 사전을 알바생에게 입력하게 한다.
지식나누기

cat, cp, getline, gzip 속도 test

2004. 7. 14. 10:59 | Posted by 속눈썹맨
cat, cp, getline 속도 test
test 환경
$ g++ --version
g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
$ uname -a
Linux search124.sayclub.com 2.4.20-20.9ns1smp #1 SMP Tue Oct 7 14:13:18 KST 2003 i686 i686 i386 GNU/Linux
$ export LANG=C

input file size : 1,286,935,566 = 1.2Gbytes

프로그램 성능 비교
0. cat
1. getline(char*), char*만 쓴 경우
2. getline(string&), string만 쓴경우
3. class inheritance, getline(char*), string을 쓴 경우
4. class inheritance, getline(char*), char*을 쓴 경우
5. class inheritance, getline(string&), string을 쓴 경우
6. cp
7. gzip -c | gzip -dc

t0 test
real 1m15.837s
user 0m0.220s
sys 0m12.450s

t1 test
real 1m38.106s
user 0m7.270s
sys 0m16.990s

t2 test
real 9m20.131s
user 6m18.900s
sys 2m37.820s

t3 test
real 1m40.530s
user 0m12.710s
sys 0m18.010s

t4 test
real 1m40.751s
user 0m8.170s
sys 0m17.540s

t5 test
real 9m29.418s
user 6m29.610s
sys 2m36.500s

t6 test
real 1m33.474s
user 0m0.170s
sys 0m12.730s

t7 test
real 2m28.825s
user 1m26.190s
sys 0m20.480s

결론

본인이 c로 짠 프로그램과 unix의 cp는 성능 차이가 없음.
getline(char*)도 속도는 같음
class inheritance, std::string으로 복사하는 것도 그리 overhead가 되지 않음.

속도가 문제가 되는 곳은 getline(string&)임. std::getline은 I/O 시간이
10배 정도 더 소요되고 있음.
(printf와 cout의 차이 정도 됨.)
지식나누기

내부 정보 검색과 외부 정보 검색의 장단점

2004. 7. 14. 10:46 | Posted by 속눈썹맨
내부 정보 검색과 외부 정보 검색의 장단점

내부정보
1. 원하는 모든 수준의 정보를 쉽게 가져올 수 있다.
(depth가 깊고 coverage는 좁다.)
2. 객관성이 떨어진다.
유저가 아닌 내부의 압력(스폰서, 회사 정책등..)에 의해 중요도가 결정된다.

외부정보
1. depth보다는 낮고 coverage가 크다.
2. 공식적인 제휴가 아닐 경우 template를 만들어서 노가다 해야한다.
(바뀌는 intreface를 쫓아가기 힘들 수 있고 가끔은 불가능하기도 하다.)
3. 충성도를 높히기 힘들 수도 있다.
4. 객관적이다. 내부의 압력이 없고 유저의 취향이 반영된다.
지식나누기

strtok,, strtok_r, strsep - string tokenize(parsing) 함수

2004. 7. 13. 13:01 | Posted by 속눈썹맨
strtok, strtok_r - delimiter가 2개 이상 연속으로 와도 1개로 처리 (empty field가 불가능)
strsep - delimiter가 2개 이상 오면 각각을 따로 처리 (empty field가 가능)

strtok와 strtok_r의 차이 strtok는 내부의 static 변수를 쓰고 strtok_r은 외부에서 입력한 변수에
현재 상태를 저장하므로 reentrant하다. (당연히 thread safe함)

empty field = string size가 0인 field

split 구현
space와 not_space 함수를 적절히 바꾸어 사용하면 됨.

bool space(char c)
{
    return isspace(c);
}

bool not_space(char c)
{
    return !isspace(c);
}

vector<string> split(const std::string& str)
{
    typedef string::const_iterator iter;
    vector<string> ret;
    iter i = str.begin();
    while (i != str.end()) {
        i = find_if(i, str.end(), not_space) ;
        // 다음 단어의 끝을 검색
        iter j = find_if(i, str.end(), space);

        // [i, j)의 문자들을 복사
        if (i != str.end())
            ret.push_back(string(i,j));
        i = j;
    }
    return ret;
}
지식나누기

오픈소스 닷넷 개발툴 "모노 1.0" (Open source .net development tool)

2004. 7. 13. 10:18 | Posted by 속눈썹맨
http://www.zdnet.co.kr/techupdate/lecture/dotnet/0,39024986,39129024,00.htm
지식나누기

전산학에서 말하는 Protection이 안되는 경우

2004. 7. 12. 14:24 | Posted by 속눈썹맨
전산학에서 말하는 Protection이 안되는 경우
1. 모두가 공용 계정을 이용할 때
2. 구분되지 않는 서버명 (단순히 1~n번까지로 되어 있을 때)
3. permission, quota가 없을 때
4. global variable로 범벅일 때.
5. 적절히 안내하지 않고 암묵적인(implicit)한 가정을 했을 때.
6. development와 release 코드, 서버를 분리하지 않았을 때
7. 모든 프로그램이 같은 memory space를 쓸 때
8. 스파게티 코드일 때


해결책
1. account
2. permission, quota
3. MVC 모델
4. namespace
5. local variable
6. 주석
7. cvs release tag
8. dist process
9. virtual memory
10. modular programming
11. Object oriented programming
12. automated test
13. locking
지식나누기

Link popularity 등 검색 알고리즘과 DB의 구조 등..

2004. 7. 11. 22:05 | Posted by 속눈썹맨
어쩌면 검색 알고리즘 같은 곳에서는 Berkeley DB나 SQL DB보다
예전의 구조인 Network DB가 더 유용할 지도 모르겠다.
(단위 operation면에서 이득이 있을 듯..)

32bits architecutre의 한계도 소프트웨어 개발을 복잡하게 만든다.
Vitual Memory가 크다면 쉽게 문제가 해결된다.
OS, compiler에게 많은 문제를 떠 넘길 수 있다.

하드 디스크도 Network drive를 이용한다면 (GFS같은..) 매우 쉽게 해결 가능하다.
지식나누기

term frequency(TF)를 이용한 검색의 문제점

2004. 7. 10. 13:22 | Posted by 속눈썹맨
term만을 이용하는 방식의 문제점
1. web은 self-descriptive하지 않다. 자신이 중요한지, 중요하지 않은 지 한 문서만으로는 판단할 수 없다.
2. abuse가 쉽다. (특정 단어를 많이 넣어버림.)
3. 그래서 altavista가 망했다.
4. term을 이용한 방법은 관련 페이지를 찾는 데에는 유용하다. (word-word, query-query)
5. 하지만 중요도(weight)를 판단하는 데는 활용할 수 없다.

link popularity를 이용하는 방식을 이용하면 누가 중요한지 쉽게 알 수 있다.

관련 논문
A method for calculating term similarity on large document collections
http://www.isri.unlv.edu/publications/isripub/Bein2003a.pdf

티스토리툴바