http://arxiv.org/abs/1111.3328 논문 요약 Programming/Java 2011. 11. 21. 13:26
양자역학에서 필수적인 파동함수를 해석하는 데에는 두가지 시각이 있다. 첫째는 파동함수가 물리적 실체라는 것이고 두번째는 파동함수 자체가 존재하는것이 아니라 파동함수는 macroscopic하게 관측을 할때 통계적으로 값을 주는 변수에 불과하다는 주장이다. 즉 이 두번째 주장은, 파동함수는 실제 통계적인 추측보다 많은것을 담고 있으므로 뭔가 정보가 더 있다는 시각이다.

이 논문은 두번째 시각이 틀렸다는것을 증명한다. 증명 자체는 간단하다. 먼저, 어떤 물리계의 실제 물리적 실체를 생각해보자. 만약 첫번째 시각이 맞다면, 실제 물리적 실체는 파동함수를 포함할 것이고 따라서 파동함수가 다르다면 물리적 실체도 다를것이다. 하지만 두번째 시각이 맞다면, 물리적 실체가 같지만 우리가 식으로 쓴 파동함수는 다를수가 있다.

예를들어  \(|\phi> = \frac{1}{\sqrt{2}} (|0>+|1>)\) 의 경우 "얘는 그냥 \(|0>, |1>\) basis로 관측했을때 1/2확률로 1이고 1/2의 확률로 0이 나오는 상태이다." 라는 시각이 있다고 하자. 그러면 이런 통계적인 주장은 \(|\phi> = \frac{1}{\sqrt{2}} (|0>-|1>)\)에도 똑같이 적용된다. 즉, 우리가 식으로쓴 파동함수가 다른것이다. 이것은 꼭 이런종류의 주장 뿐만 아니라 더 강한 통계적인 주장(파동함수에 대한 정보를 좀더 많이 담은)에 적용된다.

즉, 실제 물리계는 통계적으로 완벽히 기술되는데 반해 파동함수는 통계적인 추측보다 더 많은것을 담고있기 때문에, 뭔가 정보의 잉여가 생기고 따라서 같은 물리계를 기술할수 있는 다른 파동함수가 존재한다는 것이다. 논문은 classical analogy를 들어 설명하는데 그것도 덧붙인다.

동전을 던지는 두가지 방법이 있다고 가정하자. 만약 이때 동전을 던져서 나오는 결과의 통계적 분포가 실제 물리적인 실체고, 동전의 위치, 운동량 등은 실제 물리적인 실체가 아니라고 가정하자. 두가지 방법 모두 앞면이 나올 가능성이 0이 아니라고 하자. 그러면 동전을 던져 앞면이 나온 경우 이것이 첫번째 방법을 써서 던진건지 두번째 방법을 써서 던진건지 알수가 없다. 따라서 두가지 방법의 결과가 compatible하다.

즉, 어떠한 물리적 실체가 완벽히 통계적이라면, 그 실체의 특정한 시행에 대한 값은 이것도 가능하고 저것도 가능하다는 것이다. 여기까지 왔으면 결론은 쉽다. 이제 양자상태를 준비하자. 동전을 던질때와 마찬가지로 두가지 방법으로 양자상태를 준비하자. 첫번째 방법은 \( |\phi_0> = |0>\)를 준비하고, 두번째 방법은 \(|\phi_1> = |+> = (|0>+|1>)/\sqrt{2}\) 를 준비한다. 실제 물리적인 실체과 완벽히 통계적이라면, 측정 결과가 이 두 방법중 무엇을 썼는지 알수 없을 확률이 있을것이다.  그 확률을 \(q\)라고 하자.

그러면 준비는 끝났다. 이 준비하는 기계를 두개를 놓고 그것을 한곳에서 측정하자. 그러면 일단 측정기계에 도달했을때 상태는 \(|0>\otimes|0>\), \(|0>\otimes|+>\), \(|+>\otimes|0>\), \(|+>\otimes|+>\)  네개중에 하나일것이다. 그리고 \(q^2\)의 확률로 네 상태가 compatible할 것이다.

그런데 다음 basis로 측정하는 경우를 살펴보자.
$$
|\xi_1> = \frac{1}{\sqrt{2}}(|0>\otimes|1> + |1>\otimes |0>),
$$$$
|\xi_2> = \frac{1}{\sqrt{2}}(|0>\otimes|-> + |1>\otimes |+>),
$$$$
|\xi_3> = \frac{1}{\sqrt{2}}(|+>\otimes|1> + |->\otimes |0>),
$$$$
|\xi_4> = \frac{1}{\sqrt{2}}(|+>\otimes|-> + |->\otimes |+>),
$$ 
이때 \(|-> = (|0> - |1>)/\sqrt{2}\)이다. 하지만 이 경우 첫번째 상태\(|0>\otimes|0>\)를 basis의 첫번째 원소로 측정하면 결과는 0이다. 두번째 상태는 두번째 원소로 측정하면 0 이고 세번째와 네번째도 마찬가지이다. 따라서 모순이 발생한다. \(q^2\)의 확률로 우리는 네가지 상태가 모두 물리적 실체와 compatible해야 하는데 측정을 하면 우리는 무슨 state가 맞는지 알 수 있다. 따라서 물리적 실체가 순수히 통계적이고 상태벡터는 그것을 표현하는 수단이지 물리적 실체가 아니라는 주장은 잘못된 것이다.

여기까지가 논문의 앞 2페이지 요약이고 뒤에는 이것을 일반적인 상태에 대해서 일반화 시키는 내용과 실험적 오차를 고려하는 상황이다. 요 아래는 개인적인 comment.

이게 contextuallity와 별로 다른 개념은 아닌것 같은데 아직을 잘 모르겠고, 항상 양자역학이 고전적인 해석이랑 다르다는 데에는 entanglement가 관여하는 것을 봐서 뭔가 entanglement가 정말로 고전적으로 nontrivial한 것인것 같다. 뭔가  이와 관련된 공부를 좀 해봐야 할듯.
저작자표시
,
Django Form 에서 동적으로 필드 수정하기 Programming/Web 2011. 3. 13. 23:51
Django 의 forms.ModelChoiceField 는 보통 ModelForm 에서 ForiegnKey 를 받기 위해 사용된다. 하지만 ForiegnKey 로 사용될 수 있는 객체가 제한적이라면 queryset 인자를 통해 선택할 수 있는 옵션을 제한 할 수 있다. 예를들어, Board 모델과 Category 모델, Article 모델이 존재한다고 해 보자. Article 은 게시판의 글을 나타내며 Board 와 Category 에 속한다. Category 는 각각의 게시판에서 존재하는 분류를 타나내고 Board 에 속한다. 이 경우 Article 을 쓰기 위해 Form 을 만들 경우 ModelForm 을 사용 할 것이다. 하지만, 이러한 경우는 모든 Category 를 선택할수 있게 하면 안된다. 현재 Article이 써지려는 Board와 같은 Board에 속하는 Category 만 선택가능하도록 해야 할 것이다. 이런 경우 동적으로 ModelForm의 category를 오버로딩 해야 한다. 이때 아랴와 같이 하면 된다. 
class ArticleForm(forms.ModelForm):
    def __init__(self, board, *args, **kwargs):
        super(ArticleForm, self).__init__(*args, **kwargs)
        self.fields['category'].queryset = Category.objects.filter(board=board)
        self.fields['category'].empty_label = u"선택안함"
    
    class Meta:
        model = Article
        fields = ('category', ... blah blah ...)

사실 잘 생학해 보면 Category 에 이미 Board 에 대한 정보가 들어가 있으므로 Article 에 딱히 Board 가 필요하지는 않지만 일종의 역정규화를 시킨 것으로 이해하면 된다. 이러한 경우 위와 같이 사용하여 Category 의 선택을 제한 할 수 있다.
저작자표시
,
빠른 웹 개발 프레임워크 : Django vs CakePHP Programming/Web 2011. 2. 18. 01:51

전에 CakePHP에 대한 글을 한번 쓴 적이 있다. 그때는 CakePHP를 가지고 동아리 홈페이지를 만들고 있었는데 느린 속도와 코드의 지저분함때문에 결국에는 별로 계속 코딩을 하고싶은 욕구가 생기지 않았다. 누가 돈주는 것도 아니고 결국 내 자신이 동기부여가 안되면 더이상 진행이 안되기 때문에 좀더 구조가 좋은 다른 프레임워크를 생각해 보았다.

처음에는 PHP계열 프레임워크를 알아보다가 내가 CakePHP가 싫어진 이유도 PHP자체의 문제가 한몫 한다고 생각해 아예 다른 언어 기반의 프레임워크를 찾기 시작했다. CakePHP는 클래스 상속을 통해 많은 기능을 DRY(Don't Repeat Yourself)시켜 주는데 일단 PHP가 PHP5부터 제대로 된 객체지향을 지원하지만 아직 프레임워크가 PHP4기반이라 클래스 내부 구현이 별로 이쁘지가 않다. 게다가 제일 큰 문제점은 DB에 접근하기 전에 reculsive를 설정하여 얼마나 연관된 테이블까지 가져올 것인가를 먼저 정해야하는 것이었다. 이것도 사실 객체지향형 설계를 잘해 lazy evaluation을 하면 되는 것인데 결국은 이걸 잘 못하는 PHP랑 관련되어 생긴 문제였다. 도대체 왜 객체지향형 프레임워크에서 User와 연관된 Group정보에 접근하는데 $this->User->data['Group']['field_name']을 써야 하는가. 게다가 load하기 전에 $this->reculsive = 0 정도는 미리 해 주어야 한다. 이걸 굳이 프로그래머가 생각해서 몇번째 연관된 자료까지 필요하니 $this->reculsive를 얼마로 놓아야지 라고 하는것 너무 세련되지 못하다. user->group->get('field_name')정도가 훨씬 간단하고 보기도 좋지 않은가? PHP의 개발자가 PHP는 프레임워크 없이 쓰는 것이 좋다라고 했는데 그 말이 제일 맞는 것 같다. PHP자체가 웹언어니 굳이 프레임워크 없이도 잘 쓸수 있고, 오히려 그럴때 고민을 덜하게 되는 것 같다. 익숙해 지면 물론 다르겠지만 처음 접하는 사람이 HTTP Header를 controller에서 $this->header를 사용할까 아니면 view에서 PHP 내장 header() 함수를 쓸까 고민하는 것 보다는 낫지 않을까? 물론 코딩량은 많아지겠지만...

이러한 이유때문에 다른 언어 기반인 Ruby On Rails(이하 Rails)나 Django로 바꿀 생각을 한번 해 보고 알아보기 시작했다. 사실 Perl 기반의 Catalyst나 함수형 언어 기반의 프레임워크도 생각 해 보았지만, 구할수 있는 자료가 너무 부족한 탓에 일단 Rails나 Django쪽으로 가닥을 잡았다. 일단 전에 Rails에 관련해서 살짝 본 적도 있고 해서 Rails를 선택할까 하다가도 약간은 생소한 Ruby 의 문법때문에 고민이 되었다. 그래서 일단은 Django에 대해서 한번 알아보기로 하였다. Python은 예전에 한번 본 적도 있고 해서 별 문제 없이 Django책 하나랑 Django 문서파일을 가지고 이것저것 해 보기 시작했다. 근데 생각보다 엄청 휼륭하다! 일단 내가 CakePHP에서 불편하다고 느낀 점은 하나도 발견되지 않았다. Django의 모델이 파이썬 코드 구현인 탓에 기존의 SQL을 Python코드로 옮기긴 해야 하겠지만 그건 아무런 문제가 아니었다. CakePHP처럼 Scaffolding기능이 있는 것도 아니었지만 전혀 상관없다. 그냥 할것은 모델을 만들고 간단하게 뷰 구현하고 템플릿좀 끄적여주면 페이지가 완성된다. 물론 아직 익숙하지 않아서 문서를 많이 찾아보지만, 소스 짜는것 자체가 전보다 훨씬 즐거워졌다. 확실히 CakePHP쓸때와는 다르게 쓸데없는 고민따위는 안해도 된다. 이후 Rails도 어떨까 궁금했는데 이것(https://docs.google.com/View?docid=dcn8282p_1hg4sr9)을 보니 뭐 Django보다 많이 좋을 것 같지는 않다.

하지만 Django도 아무런 문제가 없는건 아니다. 사실 Django의 모델에서 폼을 만드는 것은 사용이 그리 간단하지만은 않다. 예를들어 회원가입페이지는 User모델과 UserProfile모델에다 회원을 추가한다. 하지만 가입하기 위해 보여주는 폼(form)은 모델에서 바로 생성하기가 조금 어렵다. 물론 모델에서 생성 할 수 있지만 내가 원하는 대로 폼의 필드를 만드는 것은 사실 폼을 새로 만드는 것과 별 차이가 안난다. 아직 Django의 모든 기능을 알지는 못해서 그럴 수도 있는데 이부분은 좀 아쉽다.

간단히 요약하면 일단 PHP언어 자체와 프레임워크는 별로 어울리지 않는 것 같다. PHP6이 나오니 어떻게 변할지는 모르겠지만 일단 지금까지는 그렇다. 다른 프레임워크를 아직 많이 알지는 못하지만 Django정도면 웹에 있어서는 정말 좋은 프레임워크임에는 틀림없다. 한번 자신이 Python에 대해서 어느정도 알고있다면 웹프로그래밍을 할때 한번 Django에 도전해 보면 좋을 것 같다.
저작자표시 비영리
,

티스토리툴바