'분류 전체보기'에 해당되는 글 47건

  1. 2018.03.15 BigQuery Demo
  2. 2013.05.24 Google CodeReview
  3. 2012.08.25 인공지능과 시뮬레이션
  4. 2012.08.25 Web Information System
  5. 2012.08.25 Real-time System
  6. 2012.08.25 음식
  7. 2012.08.25 Sigmoid Function
  8. 2012.08.25 Reality Mining
  9. 2012.08.25 Ontology
  10. 2012.08.25 Logarithm (대수)
2018. 3. 15. 16:21

Managing BigQuery Jobs 

@ 3줄요약

1. BQ jobs은 load/stream, query, export(extract), copy 작업을 webUI, CLI(bq), P/G으로 실행할 수 있다. (비동기 task로)

2. 각 jobs에는 다양한 제약사항이 있지만 연락해서 조정할 수 있다. (table load 작업은 제외)

3. Unique JobID로 job을 관리할(run, view job metadata, cancel) 수 있으며 cancel은 eventually한 작업이다.


@ 개요 (비동기, query cache, 월단위 table 설계)

1. BQ jobs은 다음의 작업들을 지원

- load, export(extract), query, copy

- 모든 job은 비동기로 처리, 간단한 작업(list res, get metadata)은 job으로 관리 안됨

2. Interface

- web ui, CLI(bq): 실행시 자동으로 create, schedule, run 됨

- p/g(by REST, client lib): create(POST, job.inserts)하면 BQ가 schedule, run 됨

- query의 cache유무와 자원사용량: web UI에서 확인 가능


3. 필요 permissions 

- https://cloud.google.com/bigquery/docs/access-control#predefined_roles_comparison_matrix

- IAM roles로 적용하는게 편함

- tip: web UI에서 실행해보면 필요 permissions 확인가능

4. Quota

1) Load 

- 하루에 한 table당 1,000개 jobs (failure 포함) => 제한증가 불가

- 하루에 한 project당 50,000개 jobs (failure 포함)

- Row/Cell size: CSV(10MB), JSON(10MB), Avro(16MB)

- 한 table당 columns는 10,000개까지

- 한 파일의 최대크기: CSV/JSON(4G/5T), Avro(file은 미지원, 압축 data block은 DEFLATE와 Snappy codec지원 / 5T, file header 1M)

- 한 job당 최대크기: 15TB(CSV, JSON, Avro 혼합 파일)

- 한 job당 최대 uris 수: 10,000 uris

- 한 job당 최대 파일수: 1,000만개(10million), uris 파일수도 포함

- 한 job 최대 수행시간: 6시간

2) Copy

- 하루에 한 table당 1,000개 jobs (failure 포함)

- 하루에 한 project당 10,000개 jobs (failure 포함)

3) Export(extract)

- 하루에 한 project당 1,000개 jobs, 10TB

- job당 500 wildcard URIs

- ​GCS에만 저장 가능


※ Wildcard URIs

single: ['gs://[YOUR_BUCKET]/file-name-*.json'], ['gs://[YOUR_BUCKET]/path-component-*/file-name.json']

multi: ['gs://my-bucket/file-name-1-*.json', 'gs://my-bucket/file-name-2-*.json', 'gs://my-bucket/file-name-3-*.json']

4) Query

- query 결과는 우선적으로 query cache(이후 세미나)에서 반환됨

- 50 concurrent queries, dryRun/--dry_run(query test)은 limit에 포함안됨

- 6 concurrent queries w/ UDFs(user-defined functions)

- 일별 query size는 무제한, custom quotas(이후 세미나에서 상세)로 설정가능

- 일별 한 table당 1,000 updates

- 한 job 최대 수행시간: 6시간

- 한 query에 1,000개 table 참조가능

- 최대 응답 크기:

 * 128MB(압축된, 압축방식에 따라 포함될수 있는 데이터량은 다양함) 

 * Large query result 옵션(이후 세미나 custom quata)을 지정하면 무제한

 * 최대 row 크기: 100MB, query job 수행시 내부적으로 처리되는 data의 크기 => 대략적인 크기임

 * project당 최대 concurrent slots 2000(on-demand price)

 * slots shard되어 있어서 보통 100GB이하의 query 처리는 문제없음

 * stackdriver monitoring(이후 세미나)으로 slots 사용 확인 가능

 * slots를 늘리고싶으면 연락해서 정액제(flat-rate)로 전환 가능

5. Price

- 저장, streaming insert, query만 과금(GB단위), load/export/copy는 무료, 매월 10GB는 무료

- 저장: 월 $0.02/GB

- 장기저장: 월 $0.01/GB (50% 할인), 90일간 table을 변경하지(추가, 덮어쓰기, 스트리밍) 않으면 적용 => 월단위 table 설계 필요

- 스트리밍: 월 $0.05/GB

- 쿼리: 월 $5/TB, 매월 1TB는 무료, query 결과는 query cache에서 반환됨

- 나머지 모든작업은 무료

@ Job w/ PG (JobID, status.errorResult/errors, timestamp)

1. 실행

- jobs.insert(or REST) w/ job ID로 작업을 실행하고, 실행상태를 주기적으로 확인가능하며, 정상적으로 완료되었는지 확인가능

- client: https://cloud.google.com/bigquery/docs/running-queries#bigquery-query-nodejs

- REST: https://cloud.google.com/bigquery/docs/reference/rest/v2/#Jobs

- job ID를 지정하지 않으면 자동으로 생성

- job resource: https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs#resource-representations


※ demo: https://code.google.com/oauthplayground/

1) https://www.googleapis.com/bigquery/v2/projects/ct-log-197412/jobs

2) https://cloud.google.com/bigquery/docs/reference/rest/v2/jobs/insert#try-it

2. 조회

- jobs.get w/ job ID

- status.state를 확인(job resource에서), DONE => 작업이 현재 수행되고 있지 않음, 성공했다는 의미는 아님

- status.errorResult가 있으면, 작업은 완료했지만 실패

- status.errorResult가 없으면, 작업성공

- 성공이라도, status.errors에 non-fatal errors이 있을 수 있음

3. Job ID 생성하기

- id 구성: [a-z, A-Z], [0-9], [ _ , - ] 1024 chars

- unique in project

- common approach: my_job_{timestamp}

@ Job 관리 (JobID, Job resource, Eventually cancel)

1. 개요

- job의 상태는 pending, running, done(success / failure <= completed w/ fatal-error)

- bigquery.admin: 모든 job 확인가능, bigquery.user / jobUser: 자신의 job만 확인가능

- job을 실행하면 다음 작업들을 할 수 있음

* view job data, list jobs, cancel, rerun

2. view job data

- web ui: job history

- bq show -j {prj_id}:{job_id} => 요약결과: job type, state, start time, duration, owner

- bq show --format=prettyjson -j {prj_id}:{job_id} => job resource

- jobs.get w/ job_id, prj_id => job resource

- https://cloud.google.com/bigquery/docs/managing-jobs#viewing_jobs

3. list jobs

- web ui: job history

- bq ls -j {prj_id} => job lists

- bq ls -j -n {int} {prj_id}, ex) bq ls -j  -n 10 myprj-1234

- jobs.list w/ pro_id

4. cancel a job

- RUNNING / PENDING job만 cancel 할 수 있음

- 모든 type의 job을 cancel 할 수 없음, cancel 할 수 없는 type의 job은 error 반환

- cancel 요청이 되어도 cancel을 보장할 수 없음 => eventually cancel

- web ui: job history

- bq cancel {job_id}: sync, bq --nosync cancel {job_id}

- jobs.cancel w/ job_id, prj_id

5. rerun a job

- web ui: query history => open query => run query

- jobs를 다시 실행 w/ job_id


Posted by yeoshim

댓글을 달아 주세요

2013. 5. 24. 13:07

코드 리뷰는 어떻게 하나요?

후배가 구글에서는 코드 리뷰를 어떻게 하면 좋을지를 물어보는 이메일을 보내 왔습니다. 저도 평소에 꼭 공유하고 싶었던 주제여서 여기에 답글을 남깁니다.

질문은 구글에서 어떻게 하느냐인데, 답글은 구글에 국한된 부분은 아니고 실리콘 밸리 회사들이 주로 어떻게 하는지 설명 드리겠습니다.

--------

선배님께 이렇게 메일을 보내는 이유는 한 가지 여쭤볼게 있어서 입니다.
요즘 회사일을 하든, 친구들과 서비슬 개발을 준비하든, 학교와는 달리 다른사람과 협업해서 코드를 짜야하는 경험을 하고 있습니다.
그래서 동료들 간에 코딩 컨벤션을 정하거나, 코드 리뷰를 할 필요성을 느끼게 되었고, 최고의 팀웍을 위해서 잘하고 싶은데 말처럼 쉽지가 않습니다. 예를 들면 리뷰어가 리뷰를 할 때 리뷰를 받는 사람은 왜 그게 더 좋은지 인지를 못하거나 혹은 쌍방 감정싸움으로 이어지지 않게 하려다 보니 대충대충 넘어간다거나 하더라구요...ㅠㅠ


그래서 질문은 다음과 같습니다.


1. 구글에서는 내부 구성원 사이에 코딩컨벤션을 어떻게 전달하고 공유하나요?
(위키 정리, 내부 스터디, 토론형 학습...등)


구글 코딩 컨벤션은 Java를 제외한 왠만한 언어는 아래 사이트에 공개 되어 었습니다.

https://code.google.com/p/google-styleguide/

그냥 그대로 쓰거나, 필요에 맞게 조금 고쳐 쓰면 될 것 같습니다.

(한가지 특이한 부분은 대부분의 회사들은 4 space indentation을 쓰는데 구글을 2 space indentation을 씁니다. 장단점이 있구요. 개인적으로는 python같이 ending brace가 없는 언어에서 depth가 깊고 block이 길 경우 좀 불편한 것 같습니다.)


2. 코드 리뷰 전체 프로세스가 어떤식으로 진행되나요?
(리뷰신청 -> 주로 언제까지 리뷰 완료 등등, 따로 리뷰 시간을 가지는 지 등)

CL (Change List)이 준비되면 "p4 mail"이나 gerrit 같은 코드 리뷰 시스템으로 리뷰를 신청합니다. 그러면 reviewer에게 이메일로 notification이 가게 되고, reviewer가 리뷰 시스템에 들어 가서 review comment를 작성하게 됩니다.  1차 review를 완료하면 이 사실에 CL 작성자에게 이메일로 notification이 가게 되죠. 이런 식으로 왔다 같다 하면서 CL이 submit 할 수준이 되면 reviewer가 approve를 하고, 그러면 작성자가 submit을 합니다.

가끔 의견차이가 잘 좁혀 지지 않을 때나, 상대방의 말이 잘 이해가 안 될 때 만나서 얘기 하는 경우도 종종 있습니다. 글로 잘 대화가 안되는 경우, 말로 하는 것이 훨씬 효율적이고 빠릅니다. 작성자이던 reviewer이던, 조금 이라고 막힌다는 느낌이 있으면 찾아 가서 직접 얘기하세요. 그게 훨씬 효율적입니다. 단 이 경우에도 반드시 리뷰 시스템에 "만나서 이렇게 합의를 봤고, 결론에 도달한 이유"를 간단히 적어 놓아야 합니다. 그래야 차후에 그 CL을 참조하는 사람이 왜 그렇게 했는지를 알 수 있으니까요.

구체적인 안건에 대한 의견 조율을 위해 offline으로 얘기하는 경우는 많지만, 따로 같이 리뷰 시간을 가지지는 않는 것 같습니다.

리뷰어는 가급적이면 CL을 받으면 최대한 자기일 보다는 리뷰를 먼저 해 주는 것이 좋습니다. CL 작성자의 입장에서는 리뷰를 얼마나 빨리 받는지에 따라 업무 효율이 많이 좌우 되니까요. 이건 CL을 처음으로 받았을 때도 그렇고 업데이트된 CL (보내준 review에 따라 수정한)을 받았을때도 마찬가지 입니다.

보통 일반적인 규칙은 (처음이든 update한 버젼이든 상관 없이) CL을 받으면 24시간안에는 리뷰를 보내준다 입니다. 하지만 이건 hard deadline에 가깝고, 대개는 그날 받은 CL은 그날 리뷰해 주는 것이 좋습니다. (오후 늦게 받은 건 그 다음날 오전에 리뷰 해 줘도 괜찮습니다.)

reviewer가 어뗜 이유로 - 아주 급한 일이 있다던지, CL이 너무 크고 이해하기 어렵다든지 해서 - 24시간안에 리뷰를 못 보내줄 것 같으면, 이메일이나 offline으로 그 사정을 CL작성자에게 얘기를 미리 해 주는 것이 좋습니다. 예를 들어 "이런 저런 사정으로 x일까지 리뷰 해 줄 수 있는데 괜찮겠냐?"고.

반대로 CL작성자가 리뷰를 받고 언제까지 수정 버젼을 보내줄 것인지에 대한 규칙은 없습니다. 이게 늦어지면 대체로 CL 작성자가 손해를 보는 쪽이니까요. 그래도 아주 극단적으로 늦어지는 경우 (1~2주?) reviewer가 문맥(context)를 잊어 버리니까, "늦게 보내서 미안하다" 정도는 적어 주는 것이 좋습니다.


3. 코드 리뷰는 어느 정도까지 하나요?
(테스트 코드 여부, 로직 검토, 변수 네이밍, 공백 등등)


이 질문에 대한 답은 상황에 따라 많이 다릅니다. 예를 들어 이미 대규모로 서비스 되고 있거나 곧 서비스 될 경우, 또는 큰 과제여서 많은 사람들이 공동 작업하는 코드, 중요한 과제여서 코드가 향후 오랫동안 사용될 경우 등에는 code quality가 아주 중요합니다. 따라서 리뷰도 더 깐깐하게 해야 합니다. 또한 주요 로직에 대해서는 unit test가 다 있어야겠죠. 때문에 "이런 저런 테스트를 추가해 주세요"는 상당히 당연한 리뷰 comment 입니다.

반면, 실험적인 코드, 1~2명이 작업하는 코드, 향후 버려질 가능성이 높은 코드는 code quality 보다는 속도가 더 중요할 수 있습니다. 이 경우 리뷰를 너무 깐깐하게 하면 얻는 것보다 비용이 더 많이 들 수도 있습니다. 때문에 약간 리뷰를 느슨하게 하는 것도 괜찮습니다. 극단적인 경우 - 완전히 실험적인 코드 - 는 아예 리뷰를 안하는 경우도 있습니다. 단 이 경우는 repository 나 디렉토리를 완전히 분리하고, 거기에는 리뷰 안 한 코드가 들어있다는 것을 사전에 팀 전체가 공유 해야 합니다. (이런 코드는 리뷰를 하는 코드가 들어 있는 디렉토리에서 불러 써도 안되죠.)

위의 두 가지 경우의 리뷰 모두,  스타일 가이드는 기본적으로 따라야 합니다.  일단 lint 같은 툴로 대부분의 문제는 다 걸러 내고, lint로 안 잡히는 문제는 reviewer가 comment를 줍니다. 단 이 경우 너무 style guide를 바이블처럼 따를 필요도 없고, 그래서도 안됩니다. style guide를 100% 지킬려고 하다 보면 너무 많은 에너지가 들 수 있거든요. 하지만 reviewer는 style guide에 안 맞는 것이 보이면 comment를 달아 주는 것이 맞고, 작성자도 그런 comment는 다 따라 주는 것이 좋습니다. 왜냐 하면 보통 style guide 관련 comment들은 고치는데 별로 시간이 많이 안 걸리니까요.

불필요한 공백(extra whitespace)은 다 없애는게 맞습니다. 안 그러면 나중에 리뷰 시스템에서 diff로 볼 때 바뀌지 않은 라인이 바뀐걸로 나오니까요. editor에서 "저장할 때 extra whitespace 없애는" 옵션을 항상 켜두면 편합니다.

comment를 달 때, 반복적인 문제들에 대해 다 comment를 달 필요는 없고, "이 라인에 이런 문제가 있고 다른 곳에도 반복되니까 모두 고치세요" 라고 하면 됩니다.

변수, 함수 이름은 코드를 이해하는데 중요하죠. 따라서 "지금 이름보다 이 이름이 더 명확할 것 같은데 어떠세요?"라고 충분히 얘기할 수 있습니다. 하지만 현재의 이름도 꽤 괜찮다면 너무 완벽하게 하기 위해서 고쳐 주세요 할 필요는 없습니다. 반면 외부에 공개 되는 API라던지, 외부에 공개 되지는 않지만 내부적으로 아주 많이 쓰일 것 같은 API는 조금이라도 더 좋아질 여지가 있으면 고치는 게 낫습니다.

review를 할 때, 중요한 것 중 하나는 CL의 전체적인 디자인이 괜찮은지를 보는 것입니다. 더 단순한 디자인은 없는지, 이해하기 쉬한 구조인지, 확장성, 유연성은 좋은지, 테스트는 쉬운지 등을 잘 보셔야 합니다. 특히 테스트가 쉬운 구조인지 (Testability)는 특히 중요한 항목입니다. 설령 당장 unit test가 없더라도 중요합니다. 나중에 테스트를 추가할려고 할 때 쉽게 할 수 있어야 하니까요. 그리고 일반적으로 Testability 가 안 좋은 코드는 다른 문제도 많이 가지고 있으니까요.


4. 코드 리뷰를 할 때 어떤 식으로 코멘트를 달아주나요?
("이건 이 방식으로 하시오", "이 라이브러리를 쓰시오", "이 이름이 더 좋아" 등등)


말씀 하신 것과 내용은 동일한데 훨씬 부드럽게 쓰는 경우가 많은 것 같습니다. 예를 들어, 영어로 "Could you ...", "How about ...", "Please ... "이런 표현도 많이 씁니다.

스타일 가이드에 안 맞거나, 더 좋은 라이브러리, 디자인을 제안하는 경우에는 관련 설명이 되어 있는 문서의 링크를 넣어서 왜 그렇게 생각하는 지를 알려주는 것도 좋습니다. (작성자도 알 것 같은 것은 굳이 이렇게 안 해도 됩니다.)


5. 코드 리뷰에 대한 사람들의 인식, 태도, 문화가 어떻나요?
(서로 배운다는 인식을 가진다, 선배 뜻을 따른다... 등)


실제로 코드 리뷰를 통해서 가장 많이 배웁니다. 코드 리뷰를 통해서 나보다 더 나은 엔지니어로 부터 구체적인 코드에 대해서 더 나은 디자인이 어떤 것이고, 또 더 나은 코드는 어떤 것인지 바로 바로 배울 수 있으니까요.

그리고 코드 리뷰를 통해서 code quality가 유지 되어야 내가 쉽게 그 코드 기반에서 작업할 수 있으니까요.



6. 기타 코드 리뷰와 관련해서 노하우 같은 게 있으신가요?

  • 주위에 나 보다 뛰어난 엔지니어가 있으면, 그 분들한테 리뷰를 많이 받으세요. 그러면 실력이 일취월장하게 됩니다.

  • 나와 비슷하거나 나보다 좀 못하는 엔지니어에게 코드 리뷰를 받더라도 보는 관점이 다르기 때문에 항상 배우는 점이 있습니다. 그런 열린 마음이 중요합니다.

  • 리뷰시에는 나만의 스타일을 고집하면 안 됩니다. 스타일 가이드에 있는 것은 잘 따라야지만, 그 이외의 부분에 대해서는 사람마다 다 스타일이 다르기 때문에 스타일에 관한 comment는 하시면 안 됩니다. 내가 할려는 comment가 code quality를 향상 시키려는 것인지, 스타일 문제인지를 잘 생각해 보세요.

  • CL 작성자가 고집이 세서, 분명히 타당한 comment인데도 받아들이지 않는다면, 한두번 얘기해 보고 안 되면 포기 하세요. code quality는 떨어지겠지만, 그게 팀원들끼리 감정 상하는 것보다는 훨씬 낮습니다. 그리고 이런 일이 특정 작성자와 반복되면 직접 만나서 허쉼탄회하게 얘기를 해 보는 것도 괜찮습니다. 단 감정이 상하지 않게 잘 해야 합니다. 그리고 너무 기대를 마세요. 사람은 안 바뀌니까요.

  • 같은 말도 "아" 다르고 "어" 다르듯이, 상호 코멘트를 달 때 예의를 갖추고 해야 합니다. 그리고 상대가 잘한 부분에 대해서는 칭찬하는  comment를 많이 달아 주세요. 예를 들어 "이 CL 정말 대단한데요.", "이 CL 정말 있었으면 좋겠다고 항상 생각해 왔는데 이거 만들어 주셔서 정말 감사합니다.", "이 디자인은 ....해서 정말 훌륭하군요.", "이 테스트는 정말 coverage가 대단 하네요.", "제안해 주신 디자인은 .. 해서 훨씬 낫군요" 등등.

  • 역지사지 - 작성자편: reviewer가 쉽고 빨리 리뷰 할 수 있는 CL을 만들도록 노력하세요. 내 시간이 중요한 만큼 reviewer의 시간도 중요합니다. 한가지 방법은 CL을 가능한 작게 만들는 것입니다. CL 하나에는 하나의 기능만 담으세요. 그래야 리뷰가 쉽고 빨리 리뷰를 할 수 있습니다. 이렇게 하면 나중에 코드 history를 살펴볼때도 편하고 여러 가지로 좋습니다. 또 한 가지 방법은 CL 보내기 전에 자신이 리뷰어가 됐다고 생각하고 리뷰 시스템에서 한 번 훑터보고 보내는 것입니다. 자신의 에디터에서 볼 때 못 보았던 문제를 많이 발견하게 될 겁니다. 반면 가장 안 좋은 자세는 대강 CL을 만들어서 리뷰 보내고, reviewer가 comment를 보내면 그걸 고치면서 CL을 완성하겠다는 자세입니다. 내 시간이 중요한 만큼 reviewer의 시간도 중요합니다. 최대한 완성된 CL을 보내세요.

  • 역지사지 - reviewer편: 리뷰시 해서 안되는 것 중에 하나는 CL의 범위가 아닌것을 이것 저것 고치라고 하는 겁니다. 예를 들어 현재 리뷰하는 CL 이전부터 기존에 갖고 있는 코드의 문제를 이번 CL에서 고치라고 하는 겁니다. 또 다른 해서는 안되는 것은 너무 무리한 것을 강요하는 것입니다. 예를 들어, "현재 CL에서 빠진 unit test가 있는데, 이걸 추가를 하면 좋지만 추가 하는데 너무 노력이 많이 든다"면, 일단 현재 CL에서는 TODO로 남기고 그 다음 CL에서 하는 것도 방법입니다. 작성자가 이렇게 하자고 하는데도, "unit test 추가 안 하면 approve 안해 주겠다" 이런 것은 좋은 태도가 아닙니다. 반면, 비용이 많이 들지만 code quality가 중요한 과제이고, 제안하는 테스트가 중요한 것이라면, 이번 CL에서 하는 것이 맞는 경우도 분명 있습니다. 

  • 인간 관계에서도 첫인상이 중요하듯이 코드 리뷰 역시 첫인상이 중요합니다. 자신의 코드를 처음 리뷰하는 reviewer에게 CL을 보낼 경우 조금 더 신경을 쓰세요. 처음 보내는 CL quality가 낮아서 여러 가지 지적을 받게 되면, 그 reviewer가 작성자에 대해 잘못된 선입관을 가질 수 있고, 이후의 CL들에 대해서도 불필요하게 더 깐깐하게 리뷰할 수도 있습니다.

  • 아직 제품이 시장에서 검증이 안 된 스타트업의 경우, 전략적으로 상당한 기술적 빚 (technical debt)를 안고 가는 것도 괜찮은 방법입니다. 이 경우 code quality는 어느 정도 포기하고, 코드 리뷰에 들어가는 노력을 작게 가져 가는 것도 괜찮은 방법입니다. (린스타트업이란 책을 참고 바랍니다.)




길게 글을 썼는데 적다 보니, 코드 리뷰를 배우는 가장 좋은 방법은, 리뷰를 잘 하는 사람에게 리뷰를 받는 것이라는 생각이 계속 드네요. 주변에 리뷰를 잘 하는 분이 있으면 그 분에게 리뷰를 받으면서 디자인, 코딩 실력도 키우시고, 동시게 리뷰 실력도 키우시기 바랍니다.

학생이라면 방학 때 실리콘 밸리 회사에서 인턴을 하는 것도, 코드 리뷰를 배우는 좋은 방법입니다 (그 밖에도 많은 것들을 배울 수 있지요). 구글 같은 큰 회사는 비행기표, 숙박 제공하고 월급도 상당히 높답니다. 우리 나라 회사라도 코드 리뷰를 제대로 하는 회사나 팀에서 인턴을 하는 것도 괜찮습니다. 코드 리뷰를 제대로 한다면 전반적으로 꽤 괜찮은 기술력을 가지고 있을 거라서 다른 것도 많이 배울 수 있구요.

Posted by yeoshim

댓글을 달아 주세요

 Search Method

  1. Basic Search

    1. Blind Search: Search tree를 만든 후, (모든 경우가 탐색 가능 ==> 너무 많은 시간 소요)

      1. DFS: 깊이 우선으로 탐색 (Local Max에 빠질 가능성)
      2. BFS: 너비 우선으로 탐색 (너무 많은 시간 소요)
    2. Heuristic Search: Search tree에서 경험에 의한 기대치를 반영 ==> 시간 개선을 위해

      1. Hill-Climb(DFS with weight): 각 노드에 경험에 의한 가중치를 부여한 후 우선하여 검색 (local max에 빠질 가능성, 방향전환의 어려움, 평평한 고원 문제)
      2. Beam(BFS with weight): level로 확장한 후 확장된 곳에서 노드의 경험적 가중치를 기반으로 w만큼 선택, 이 과정을 goal를 찾을 때까지 반복
      3. Best First: 어떠한 휴리스틱에 따라서 최근의 모든 경로들을 순서화하여 DFS를 최적화하는 탐색 알고리즘 (???)
  2. Optimal Search

    1. British Museum:
    2. Branch and Bound: branch(노드 확장)한 후 확장된 노드 중 가장 좋은 노드로 bound, goal을 찾을 때까지 이 과정을 반복
    3. Branch and Bound with Underestimates: B&B의 과정을 휴리스틱 가중치를 합산하여 적용
    4. A*: 3번 방법(B&B with U)에 Dynamic Programming Principle를 적용한 방법

#. Dynamic Programming Principle: 노드 탐색시 같은 이름의 노드가 존재하면 효율적인 하나만 확장

(예) S-A-D(8) S-D(4)이면 D까지 가는데 후자가 4만큼의 비용이 절약되므로 전자는 고려하지 않음

 

Rule Based Expert System

1. 개   요

E.S

  |

----------------------------

|                                       |

 Knowledge Base                Inference Engine

|

 -------------------------

|                                    |

    Rule                      Facts, Assertions

 

예) A toy deduction system identifies animals: 사용자와 system이 질의응답을 통해 어떤 동물인지 알아내는 것

  1. Inference Engine

    1. Forward Chaining: Facts, Assertions과 Rule을 이용한 Inference Engine을 기반으로 사실을 찾아내는 방법 (Bottom-Up)

      1. A Toy Deduction System Identifies Animals
        "우유를 주다"  ==> If x가 우유를 준다 then x는 포유동물 이다
        "chews cud(되새김질을 하다)" ==> If x가 표유동물이고 되새김질을 한다 then x는 발굽을 가진 유제동물이다
        "다리가 길다", "목이 길다', "황갈색이다", "얼룩 점이 있다" ==> If x가 발굽을 가진 유제동물이고, 다리와 목이 길고, 황갈색에 얼룰점이 있다. then x는 기린이다
      2. A Toy Reaction System Bags Groceries
    2. Backward Chaining: 사실이 주어지고 그 사실이 되기위한 조건을 찾아가며 검증하는 방법 (Top-Down)
  2. Conflict Resolution Strategies

    1. Rule Ordering: Rule에 우선순위를 두라
    2. Context Ordering: 특정 상황에 맞는 Rules를 그룹화 해라
    3. Specificity Ordering: Superset of the conditions of triggered rule을 이용하라 (???)
    4. Data Ordering: 어떤 우선순위된 list에서 가능한 모든 assertions를 정렬하고 가장 우선순위가 높은 assertions를 이용하라 (???)
    5. Size Ordering: 조건(conditions)의 수가 많은 rule을 사용하라
    6. Recency Ordering: Use the least recently used rule

 

Simulation Methodology

  1. Simulation System Classification

    1. Discrete (time) simulation
    2. Continuous (time) simulation
    3. Discrete event simulation

 

 

이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

Web Information System  (0) 2012.08.25
Real-time System  (0) 2012.08.25
Sigmoid Function  (0) 2012.08.25
Reality Mining  (0) 2012.08.25
Ontology  (0) 2012.08.25
Posted by yeoshim

댓글을 달아 주세요

2012. 8. 25. 21:33

3. Deductive Reasoning Agents

연역적 추론 에이전트???

연역법(deductive method): 이미 증명된 하나 또는 둘 이상의 명제를 전제로 하여 새로운 명재를 결론으로 이끌어내는 것을 연역(deduction)이라 하며, 이러한 연역적 추리의 방법과 절차를 논리적으로 체계화 한 것

 예) 아리스토텔레스의 삼단논법 (간접추리)

      모든 사람은 죽는다.          A -> B (대전제)

      소크라테스는 사람이다.     C -> A (소전제)

      소크라테스는 죽는다.        C -> B (결론)

원문보기

 

3.0  Intorduce

    Symbolic AI

  • AI system 구축을 위한 전통적인 방법
  • 주어진 시스템의 환경과 그에 적합한 행동의 symbolic한 representation(묘사, 표현???), 그리고 이 representation에 대한 syntactically manipulating(언어적 조작???)이 적용된 시스템으로 지능적 행동을 생성하는 방법

 본 책에서는 이러한 전통적 방법을 극치화 하는데 중점을 둠

 symbolic representation => logical formulae

 syntactically manipulating => logical deduction(논리적 연역) / theorem-proving(논리적 명제 증명법???)

 

사무실을 돌아다니며 쓰레기를 줍는 로봇 에이전트가 있다.

이러한 로봇을 구현하기 위한 방법은 여러가지가 있다.

그중 하나의 방법은 작동을 위한 description, 환경의 representation을 에이전트에게 주는것이다.

 

 RALPH는 복도와 큰 블럭들이 있는 환경에서 작동하는 자동로봇 에이전트이다.

Sensory 입력은 비디오 카메라를 통하고,

'interp' subsystem은 이 영상입력을 내부적 representation format으로 변환, based on first-order logic.

 knowledge base라는 historical reasons를 위한 자료구조로 구성.

이 RALPH를 위해서는 다음 두가지의 문제점을 해결해야 함.

  1. The transduction problem: 현실세계를 정확하고 적절하며 유용한 symbolic description으로 변환하는 문제
  2. The representation/reasoning problem: 정보를 symbolic하게 표현하고 이것을 조작하고 추론하여 유용한 결과를 내는 에이전트를 얻는 문제

 

1번문제는 비젼, 음성인식, 학습과 관련된 기술이고, 2번문제는 지식 표현, 자동화 추론, 자동화 계획과 관련된 기술이다.

매우 어렵다. ㅡㅡ;

 

 하지만, theorem-prover(논리적 명제 증명)을 이용한 에이전트는 이러한 문제를 해결하는데 흥미로울 수도 있다.

 우리가 어떤 theory of agency를 가지고 있다고 생각해 보자. 이 theory of agency는 어떤 performance measure의 최적화를 위해 지능적 에이전트가 어떻게 해야하는지 알려준다. 예를 들면, 에이전트의 궁극적 목적을 만족하기 위한 부분적 목표를 어떻게 생성하는지, 이러한 목표를 달성하기 위해 goal-directed하고 reactive한 행동을 어떻게 interleave하는지

즉, 이 theory는 에이전트가 어떻게 행동해야 하는지에 대한 specification이라 볼 수 있다.

이러한 specification을 만족하는 시스템을 implementation하는 전통적인 방법은 궁극적 목적에 도달하기 까지 점차 concrete되어 가는 stage에 따라 specification의 재정의(refining)이 가능해야 한다.

 그러나 theorem-prover을 이용한 에이전트는 이러한 재정의가 발생하지 않는다. 대신, executable specification이란 것이 있다.

 executable specification: 에이전트의 행동을 생성하기 위해 directly executed된 것이다.

 

 3.1 Agents as Theorem Provers

deliberate 라는 logic 기반의 에이전트를 만들어 보자.

이러한 에이전트는 내부적으로 전통적 first-order predicate logic formulae의 db로 구성된다.

예를들면, 다음과 같은 fomulae들이 포함되어 있다.

Open(value221)

Temperature(reactor 4726, 321)

Pressure(tank 776, 28)

이 db는 그 에이전트의 환경정보를 가진다. 에이전트의 db는 인간의 belief와 유사한 역활을 한다.

 

 3.2  Agent-Oriented Programming

 

 3.3 Concurrent MetateM

 

 

 

이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

인공지능과 시뮬레이션  (0) 2012.08.25
Real-time System  (0) 2012.08.25
Sigmoid Function  (0) 2012.08.25
Reality Mining  (0) 2012.08.25
Ontology  (0) 2012.08.25
Posted by yeoshim
TAG LECTURE, NOTE, WIS

댓글을 달아 주세요

2012. 8. 25. 21:32
  1. Real-time system: 논리적인 수행결과 뿐만 아니라 시간적 제약에 의해 시스템의 정확도가 결정되는 시스템
    예) 공장 자동화, 해저탐사, 프로세스 제어, 로봇, 군사 응용, 비젼시스템
  2. 일반 시스템과의 차이점: task들이 한계시간(deadline)이나 시작 가능시간(release time)과 같은 시간 제약을 가지고 있어 이를 만족시켜야 함.
  3. Real-time task / time critical task: 시간적으로 여러가지 제약을 갖는 task

    1. periodic task: 일정한 시간간격을 가지고 task 실행

    2. aperiodic task: task가 일어나는 시간간격이 일정하지 않은 task
  4. Slack time
    time_limit.JPG
  5. Real-time Scheduling

    1. Static scheduling

      1. 시스템에 의해 실행되는 task 집합이 미리 정의되어 있는 경우
      2. 주기적인 hard real-time task집합에 유용
      3. 스케줄링되는 task들의 특징과 수를 스케줄링 전에 알 수 있음
    2. Dynamic scheduling

      1. task의 발생 시간이나 특성을 예측할 수 없는 경우에 유용
      2. task의 발생이 가변적이어서 task의 수는 실행시간에 정해짐
        rtss.jpg
  6. EDF(Earliest-Deadline First) 알고리즘

    1. 임계시간(???)이 가장 근접한 task를 가장 먼저 실행
    2. 대표적인 동적 스케줄링 방식
    3. 다음을 가정

      1. 모든 task들은 선점될 수 있고 나중에 다시 선점된 곳으로부터 계속해서 수행될 수 있다.
      2. 모든 task들은 독립적이어서 다른 task의 시작가능시간(release time)이나 종료시간에 의존하지 않는다.
      3. task의 한계시간(deadline)은 주기와 같다
      4. task 집합의 모든 task는 반드시 주기적일 필요는 없다.

 

숙제 1: Preemptive가 일반적으로 nonpreemptive scheduling보다 좋은 이유

태스크 스케줄링 방법에는 각 태스크를 우선순위없이 일정 간격으로 번갈아 실행하는 Round-Robin 스케줄링 방법이 있고 우선순위 기준 스케줄링(Priority based scheduling) 방법이 있다.
우선순위 기준 스케줄링(Priority based scheduling) 방법에는 선점형 스케줄링(preemptive scheduling)과 비선점형 스케줄링(non preemptive scheduling) 방법으로 나눌 수 있는데
비선점형에서는 높은 우선순위의 태스크가 활성화되어도 낮은 우선순위의 태스크가 끝날 때까지 기다려야 하지만
선점형에서는 어느때든지 높은 우선순위의 태스크가 낮은 우선순위의 태스크 수행을 가로채고(interrupt or switching) 실행된다.
따라서 선점형 커널이 보다 태스크간의 관계를 조절하기가 용이하다.
이러한 점을 이용하면 스케줄링을 시스템의 특성에 따라 유연하게 조정가능하므로 비선점형 보다 더 좋다고 생각한다.

 

 

Non-Preemptive Multitasking (비선점형 멀티태스킹)

 키보드 입력을 허용할 준비가 되어 있을 때처럼 특정 시점에서만 CPU 제어를 다른 응용 프로그램으로 넘길 수 있는 멀티태스킹 환경.

이런 방법으로 많은 계산을 수행하는 한 프로그램에서 시스템을 제어하고 다른 응용 프로그램이 CPU에 대해 제한된 액세스를 가질 수 있게 할 수 있다.

비선점형 멀티태스킹을 "협업 멀티태스킹"이라고도 한다.

이 환경에서 프로그램이 효율적으로 작동할 수 있도록 하기 위해 서로 협력하도록 설계되어야한다.

비선점형 멀티태스킹 운영 체제는 백그라운드로 실행되는 통신 프로그램에 대한 서비스를 보증할 수 없다.

다른 응용 프로그램이 CPU를 불법으로 사용한 경우 CPU가 통신 프로그램에서 수신 데이터를 캡처할 수 있을 만큼 빠르게 인터럽트를 처리할 수 없으므로 데이터를 손실할 수 있다.

선점형 멀티태스킹과 대조적이다.

 

Preemptive Multitasking (선점형 멀티태스킹)

 실행 중인 모든 프로그램과 처리 시간을 공유하는 멀티태스킹 방법.

선점형 멀티태스킹은 실행 중인 프로그램이 CPU에서 되풀이 시간을 얻는 시간 공유 환경을 만든다.

운영 체제에 따라 시간 분할이 모든 프로그램에 대해 동일할 수 있거나 현재 프로그램과 사용자 혼합을 만족하도록 조정할 수 있다.

예를 들면, 포그라운드 로드가 아무리 많아도 백그라운드 프로그램에 더 많은 CPU 시간을 제공할 수 있고 그 반대도 마찬가지이다.

선점형 멀티태스킹은 메인프레임에서 중요하지만 데스크톱 운영 체제에서도 유용하다.

또한 백그라운드로 전송되는 경우 데이터가 손실되지 않는다.

모뎀이나 네트워크 프로그램이 수신 데이터 스트림을 계속 처리해야 하는 시스템 사이클을 OS가 제어할 수 있다.

비선점형 멀티태스킹과 대조적이다.

이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

인공지능과 시뮬레이션  (0) 2012.08.25
Web Information System  (0) 2012.08.25
Sigmoid Function  (0) 2012.08.25
Reality Mining  (0) 2012.08.25
Ontology  (0) 2012.08.25
Posted by yeoshim

댓글을 달아 주세요

2012. 8. 25. 21:23

세계 10대 불량 음식 VS 세계 10대 건강 음식
[세계 10대 불량 음식] - WHO 발표

1. 기름에 튀긴 식품 
- 심혈관 질병을 일으키는 원인이며 발암 물질을 포함하고 있다. 또한 비타민을 파괴하고 단백질을 변질시킨다.

2. 소금에 절인 식품
- 많이 섭취하면 고혈압을 일으키며 신장에 큰 부담을 준다. 그리고 후두암을 일으키며 점막이 쉽게 헐거나 염증을 생기게 한다.

3. 가공류 고기 식품
- 발암물질 중 하나인 아질산염과 방부제를 대량 포함하고 있으며 간에 큰 부담을 준다.

4. 과자류 식품
- 식용 향료와 색소가 대량 포함되어 있어 간 기능에 부담을 준다. 심하면 비타민을 파괴한다.
열량은 높지만 기타 영양 성분 면에서는 부족하다. 저온에서 구운 과자나 전밀 과자는 포함하지 않는다.
 
5. 사이다 콜라류 식품
- 인산, 탄산을 포함한다. 몸 속의 철분, 칼슘 성분을 소변을 통해 밖으로 배출시킨다. 당도는 매우 높지만 정작 흡수한 당을 에너지화 하는 무기질, 비타민 등 영양 성분은 없기 때문에 몸 속의 비타민을 빼앗아 졸음이 오고 입맛이 없어지게 한다. 또한 인체에 유해한 색소도 많이 들어 있다.

6. 편리류 식품
- 염분이 매우 높고 방부제, 향료를 포함하고 있어 간에 손상을 줄 수 있다.
   열량만 있을 뿐 정작 중요한 영양 성분이 없다.

7. 통조림류 식품
- 생선, 육류, 과일류 등을 모두 포함한다. 비타민을 파괴하고 단백질을 변질시킨다.
  이 또한 열량은 매우 높지만 기타 영양 성분이 낮다.

8. 설탕에 절인 과일류 식품
- 설탕이나 소금에 절인 과일도 불량 식품에 속한다. 발암 물질의 대표격인
  아질산염을 포함하고 있다. 염분이 너무 높고, 방부제, 향료를 포함하고 있다.

9. 냉동 간식류 식품
- 아이스크림, 아이스케이크 등 단 냉동 음식을 말한다. 쉽게 비만해질 수 있고 당도도
   너무 높아 식사에 영향을 준다.

10. 숯불구이류 식품
- 불에 구운 닭다리 한 개는 담배 60개비의 독성과 같으며 신장, 간에 부담을 가중한다

 
[세계 10대 건강 음식] - 타임지 2005년 특별판 선정

1.토마토
붉은색을 내는 성분인 리코펜은 강력한 항암성분. 비타민 C도 풍부해 감기와 스트레스에 대한 저항력을 높여준다. 특히 다른 야채나 과일에 비해 칼로리가 낮아 다이어트에도 좋다.

2.시금치
뽀빠이가 시금치를 괜히 먹은 게 아니다. 시금치에는 여자들에게 특히 필요한 칼슘과 철분이 많고 섬유질이 풍부해 포만감을 주는 다이어트 식품이다. 데친 시금치 나물은 한 접시에 겨우 40kcal!

3.견과류
땅콩, 호두, 잣, 아몬드 등에 들어 있는 비타민 E는 콜라겐 생성을 도와 피부를 아름답게 만들어준다. 일주일에 2~3회, 땅콩 20알 이상 먹어야 눈에 띄는 효과가 나타난다. ‘먹는 화장품’인 셈.

4.브로콜리(or 양배추)
슬포라판, 인동 등의 성분이 들어 있어 유방암, 대장암, 위암의 발생을 억?┎磯?. 섬유질과 베타카로틴이 풍부해 식욕을 억제시키는 다이어트 식품이기도 하다.

5.귀리(or 보리)
베타글루칸이라는 수용성 식이섬유가 포만감을 느끼게 하고 몸에 해로운 콜레스테롤을 배출시킨다.
강력한 항암, 항바이러스 효과
** 강력한 항암, 항바이러스 효과 **

6.사스 예방 음식으로 각광받고 있는 마늘.
알리신과 스코르진 등은 강력한 항균물질로 식중독과 바이러스의 침투를 막는다. 또한 혈액순환을 원활하게 해 심장질환을 예방한다.

7.녹차
폴리페놀은 발암물질의 침투를 막고 특유의 떫은 맛은 위장 운동을 활발하게 한다. 녹차를 많이
마시는 아시아 지역에서는 위암 발생률이 현저히 낮다.
  
8.적포도주
자줏빛을 내는 색소에는 항암작용이 있는 것으로 알려졌다. 와인의 떫은 맛을 내는 타닌 성분은
몸에 유익한 콜레스테롤을 활성화시켜 동맥경화를 예방한다.

9.연어(or 고등어)
오메가 3 지방산은 콜레스테롤을 낮추고 관절염을 예방하는 데 탁월한 효과가 있다. 특히 고등어는 오메가 3 지방산(일명 DHA)이 연어의 2배! 이 성분은 기억력과 학습 능력을 높이고 노인성 치매도 예방한다.

10.블루베리(or 가지)
보라색을 내는 안토시안 색소는 심장병을 예방하며 바이러스와 세균을 죽이는 효과가 있다.
가지의 보라색도 같은 효과가 있다

이 글은 스프링노트에서 작성되었습니다.

'yeoshim' 카테고리의 다른 글

김용 총장의 인터뷰와 그후...  (0) 2012.08.25
서울 - 수원 버스정보  (0) 2012.08.23
Posted by yeoshim

댓글을 달아 주세요

2012. 8. 25. 21:22

 이런 면에서 일반적으로 디지털 신경세포가 더 복잡하다고 할 수 있다.

단지 가중 총합이 한계치 이상인가 아닌가에 따라 1 이나 0 을 출력하는 대신,

디지털 신경세포는 입력물들의 가중 총합을 계산하고, 여기에서 한계치를 뺀 다음, 그 값을 곧바로 출력한다.

그러나 디지털 신경세포의 작동 방식은 생물학적 신경세포와 비슷하다.

높은 출력값은 일련의 빠른 펄스에 해당하고, 낮은 출력값은 일련의 느린 펄스에 해당한다.

 

그러나 결국 이런 종류의 신경세포, 이른 바 '지각자 (perceptron)'는 일반화되지 못했다.

출력이 단지 단선적으로 입력에 반응하기 때문에 신경세포가 배울 수 있는 기능은 아주 기초적이고 선형적인 것에 불과하다.

이것은 단지 입력의 변화가 출력의 변화로 이어진다는 것만을 의미한다.

어떤 입력물에 작은 변화를 가하면 출력물에도 그에 따른 작은 변화가 발생할 뿐이다.

출력이 입력에 정비례한다면 그 신경세포는 다소 지루하고 비효과적일 것이다.

 

이 점을 극복하기 위해 오늘날 일반적인 디지털 신경세포에는 한 가지 비결이 추가되었다.

일단 입력물들의 가중 총합을 계산하고 한계치를 빼고 나면, 신경세포는 그 값을 변형시킨다.

이것은 전송 함수나 활성화 함수로 계산되는데, 대개 S 자형 곡선 (sigmoid curve) 이 이용된다.

 

여러분이 수학을 좋아하는지 모르겠지만, 일반적인 함수는 y = 1/(1 + e-x) 이다.

 

나도 그렇지만, 이 함수의 의미가 별로 감동적이지 않다 해도 걱정할 필요는 없다.

 

그것은 단지, 신경세포가 입력에 따라 0 이나 1 의 값을 출력할 때 비선형적 방식을 적용하게 하는 방법일 뿐이다.

그것은 신경세포가 이제 선형적 방식에서 벗어나 훨씬 더 복잡한 것들을 배울 수 있게 되었음을 의미한다.

 

이것이 대표적인 디지털 신경세포이다.

그것은 우리의 컴퓨터 안에 살면서 0 이나 1 로 된 수많은 입력물들을 받는다.

이때 신경세포는 그 입력물들의 가중치와 합을 계산하고 그 값에서 한계치의 값을 뺀다. 그리고 비선형적 S 자형 함수를 이용하여 그 값을 변형시킨 다음 결과를 출력한다.

출력물은 0 이나 1 의 값이다. ............

그리고 입력되는 값들은 다른 신경세포들에게서 전달되는데, 이 신경세포들은 하나의 신경망을 이룬다 ...................... (Peter J. Bentley 2001)

 


무슨 말일까? ㅡㅡ;

이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

Web Information System  (0) 2012.08.25
Real-time System  (0) 2012.08.25
Reality Mining  (0) 2012.08.25
Ontology  (0) 2012.08.25
Logarithm (대수)  (0) 2012.08.25
Posted by yeoshim

댓글을 달아 주세요

2012. 8. 25. 21:21

 

Technology Review caught up with Pentland to ask him about reality mining and its implications.

 

Technology Review: When you talk about reality mining, what do you mean?

Sandy Pentland: The real roots of it go back to early 1990s, when people first started talking about context-aware computing. Just look at a cell phone. It knows where you are, and this is obviously sort of useful. But the generalization is that maybe it can know lots of things about you. Take your Facebook friends as an example. The phone could know which ones you socialize with in person, which ones are your work friends, and which friends you've never seen in your life. That's an interesting distinction, and reality mining can make it automatic. It's about making the "dumb" information-technology infrastructure know something about your social life. All this sort-of Web 2.0 stuff is nice, but you have to type stuff in. Things are never up to date, and unless you consciously know about something, you can't put it in. Reality mining is all about paying attention to patterns in life and using that information to help you do things like set privacy policies, share things with people, notify people when you're near them, and just to help you live your life.

 

TR: What technologies are enabling reality mining now?

SP: Today's cell phones are on us all the time, and they come with hardware that can act as sensors for your environment. For instance, if Bluetooth is turned on, then the phone can see and be seen by other Bluetooth devices. You can start to make a record of the Bluetooth-enabled devices you encounter throughout the day. Then you can figure out, based on the frequency [with which] you encounter other people's Bluetooth phones, what sort of relationship you have with them.

The iPhone also has an accelerometer that could tell if you are sitting and walking. You don't have to explicitly type stuff in; it's just measured. And all phones have built-in microphones that can be used to analyze your tone of voice, how long you talk, how often you interrupt people. These patterns can tell you what roles people play in groups: you can figure out who the leader is and who the followers are. It's folk psychology, and some of the stuff people may already know, but we haven't been able to measure it, at such a large scale, before these phones.

이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

Web Information System  (0) 2012.08.25
Real-time System  (0) 2012.08.25
Sigmoid Function  (0) 2012.08.25
Ontology  (0) 2012.08.25
Logarithm (대수)  (0) 2012.08.25
Posted by yeoshim

댓글을 달아 주세요

2012. 8. 25. 21:21

온톨로지의 어원: 철학의 존재론

존재론: 실재에 대한 정확한 이해를 추구하는 학문이다

실재: 우리의 눈에 보이는 이 세상의 모든 것

존재론 + 실재: 이 세상을 규정하기 위해 세상에 존재하는 실체들에 대한 명확한 이해와 정의를 연구하는 것

 

온톨로지는 이러한 존재론의 기본 철학정보시스템에 적용하여 정보시스템의 대상이 되는 자원의 개념을 명확하게 정의하고 상세하게 기술하여 보다 정확한 정보를 찾을 수 있도록 하는데 목적이 있다.

 

정보를 효과적으로 관리하고 검색하기 위한 지향점

 

Tom Gruber: An ontology is a specification of a conceptualization (온톨로지는 개념화의 명세이다.)

개념화: 무언가를 개념으로 만드는 것 즉, 사물이나 추상적으로 존재하는 관념들을 구체적인 집합으로 만드는 것

이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

Web Information System  (0) 2012.08.25
Real-time System  (0) 2012.08.25
Sigmoid Function  (0) 2012.08.25
Reality Mining  (0) 2012.08.25
Logarithm (대수)  (0) 2012.08.25
Posted by yeoshim

댓글을 달아 주세요

2012. 8. 25. 21:21

로그 (logarithm)

요약
수학용어.
설명
수학용어. 를 1이 아닌 양수, 를 임의의 양수라 할 때 에 대하여 를 성립시키는 실수 는 오직 하나만 존재하는데, 이 를 <를 밑으로 하는 의 로그>라고 하며 =log라 나타낸다. 또 여기서 를 log(즉 )의 <진수(眞數)>라고 한다. 로그(log)는 logarithm의 약칭으로서, 구용어로는 대수(對數)라 하였다. 로그의 기본적인 성질을 간추려보면 다음 다섯 공식과 같다.
>0, ≠1, >0, >0, 는 임의의 실수 일 때,









=log에서 밑 를 정해 놓고, 의 값에 대한 log의 값을 나타낸 표를 <로그표>라 한다. 위의 공식 ⑵ 의 경우는 이 로그표에서 log와 log의 값을 각각 읽어서 합 log+log=log의 값을 계산한다. 이와 같이 로그표를 읽음으로써 로그값을 구할 수 있는데, 반대로 로그값을 알고 그 진수의 값을 구하려면, 로그값을 구하는 경우의 반대 절차에 따라 로그표를 읽으면 된다. 즉 합 log의 값을 로그표를 읽어서 계산했다면, 그 반대 절차로 로그표를 읽어서 log의 진수 의 값을 구할 수 있다. 따라서 진수의 곱셈을 로그표에 의해 로그의 덧셈으로 바꿀 수 있다. 마찬가지로 공식 ⑶ 에 의해 진수의 나눗셈을 로그의 뺄셈으로 바꿀 수 있으며, 공식 ⑷ 에 의해 진수의 거듭제곱 또는 거듭제곱근을 구하는 계산을 각각 로그와 실수의 곱셈 또는 나눗셈으로 바꿀 수 있다. 로그는 이상과 같은 실용적인 필요성에 의해 개발된 것으로 J. 네이피어에 의해 개척되었으며, 또한 그는 처음으로 로그표를 만들어 공표하기도 했다. 이와는 별도로 J. 뷔르기도 1603∼1611년에 걸쳐서 로그표를 만들었으며, 1620년에 이를 간행하였다. 기수법은 보통 십진법에 의하기 때문에, 실용상의 계산에는 10을 밑으로 하는 로그를 사용하는 것이 편리하다. 이와 같은 로그를 <상용(常用)로그(common logarithm)>라 하는데, 초등수학에서는 보통 밑 10을 생략하여 log라 나타낸다. 따라서 공식 ⑴ 에 의해 log10=1로 된다. 1이고 의 정수부분이 +1자리(0)인 수이면 =10′, 1′<10이라 쓸 수 있으므로 log=+log′, 0log′<1로 된다. 또 0<<1이고 의 소숫점 아래 째 자리에서 처음으로 0이 아닌 숫자가 나타나는 소수는, =10′, ′=-, 1′<10이라 쓸 수 있으므로, log=′+log′, 0log′<1로 된다. 위의 (1인 경우) 또는 ′(0<<1인 경우)을 상용로그 log의 <지표>라 하며, log′을 <가수(假數)>라 한다. 이상의 설명에 의거하여 1′<10인 ′에 대한 상용로그표에서 가수(로그의 소수부분)를 구하고, 이것에 의 자리수에 의해 정해지는 정수 또는 ′, 즉 지표를 더함으로써 의 상용로그 log의 값이 구해진다. 상용로그표는 이상과 같은 원리에 의거해서 작성되었으며, 1794년에 G.F. 베가에 의해 완전한 것으로 만들어졌다. 한편, 수학 이론에서는



를 밑으로 하는 로그인 log가 이용된다. 이 로그를 <자연(自然)로그(natural logarithm)>라 하며, 보통 밑 를 생략하여 log라 나타내지만, 드물게 ln라 나타내는 경우도 있다. 자연로그와 상용로그의 상호 관계를 간추리면 다음과 같다.







이 글은 스프링노트에서 작성되었습니다.

'Study' 카테고리의 다른 글

Web Information System  (0) 2012.08.25
Real-time System  (0) 2012.08.25
Sigmoid Function  (0) 2012.08.25
Reality Mining  (0) 2012.08.25
Ontology  (0) 2012.08.25
Posted by yeoshim
TAG log, math, NOTE, Term

댓글을 달아 주세요

이전버튼 1 2 3 4 5 이전버튼