이론에 대해 말하는 방법

나는 이것이 논쟁의 여지가있는 질문 일지 모른다는 것을 알고 있지만, 이것은 물어볼만한 곳인 것 같았다. 그렇지 않은 경우 리디렉션하십시오.

배경은 제가 "실무자"(PhD 학생, CS 이론을 공부하지 않음)이지만 학부 알고리즘과 수학에 대한 합리적인 기초를 가지고 있다는 것입니다. 그럼에도 불구하고, 이론가들과의 토론은 마치 내가 겁에 질 때 나에게 수학 용어를 사용하는 것을 두려워하는 것처럼 매우 표면적입니다. 실제로, 나는 이론에 완전히 익숙하고 관심이 있지만, 그것을 토론하는 데 익숙하지 않기 때문에 아마도 "이론가"로 표시되는 용어를 항상 사용하지는 않을 것입니다. 특히 문제의 이론가가 전문성에 대한 높은 기준을 설정하는 대담한 톤을 가정 한 경우 직접 접근 방식 ( "세부 사항을 알려주십시오")이 항상 효과가있는 것은 아닙니다.

이론가로서, 이런 식으로 사람들을 걸러내는 경우, 실무자가 필터에 의해 "플래그"를 피하는 방법에 대한 권장 사항이 있습니까?

무례한 엘리트 주의자와 일하고있을 수도 있지만, 내 경험상 기술적 인 세부 사항을 설명하기를 꺼리는 것은 내가 이야기하는 사람보다 상황에 따라 다릅니다. 나는 대변인이 Alan Turing 자신이더라도 점심이나 복도에서 증명 / 알고리즘에 대한 기술적 세부 사항을 제공하는 것을 피할 것입니다. 그 이유는 세부 사항이 표기법의 선택과 주장을 부드럽게하기 위해 도입 된 수제 개념에 크게 의존하기 때문입니다. 또한 모든 사람들이 사물을 다르게 이해하고 개념을 설명하는 일반적인 방법이 없기 때문에 나는 항상 대담 자에게 적응해야합니다.

한 가지 예외는 내 대담자가 이런 종류의 문제에 대해 나와 긴밀히 협력 한 경우, 우리는 몇 가지 화이트 보드 세션 후에 (또는 긴급 마감일 전에) 함께 성장하기 때문에 우리가 이해하는이 일반적인 횡설수설을 사용할 수 있다는 것을 알고 있습니다. .

또 다른 예외는 세부 사항없이 증거의 조잡한 전체 체계를 제공 한 후 대담자가 프레젠테이션을 단순화하기 위해 의도적으로 그에게서 숨겨져 있던 증거의 특정 부분을 보았 음을 보여주는 정확한 질문을합니다. 이 경우 판도라 상자를 자연스럽게 열고 계층별로 증명의 중심으로 함께 들어가고 보통 화이트 보드로 끝나게됩니다. 그리고이 문제.

이미 너무 긴 이야기에는 몇 가지 도덕이 있습니다.

• 이론적 인 컴퓨터 과학 분야에서 활발히 활동하고 있지 않기 때문에 자신을 감가 상각하지 마십시오 . 대부분의 사람들은 자신이 자신의 작업에 대해 호기심을 보인다면 정확한 배경에 신경 쓰지 않을 것입니다.
• 사람들이 증거 / 개념에 대해 애매 모호 할 경우, 이해를 나타내는 정확한 질문 을하여 대화가 안내자가 먼저 증거의 어느 부분을 개발하도록 선택할 수 있도록하여 대화를 인도하십시오 . 이동에 대한 관련 의견을 제공 할 수 없기 때문에 (이것은 모든 사람에게 "이론가"에게도 발생할 수 있기 때문에) 이것은 매우 어렵고 예측할 수없는 일이지만,이를 관리하면 매우 밝은 토론으로 이어질 수 있습니다.
• "이론가들"조차도 증거를 명확하게 설명하기 전에 머리에 증거의 세부 사항을 다시로드 할 시간이 필요합니다. 약속을 명시 적으로 당신이 당신의 대담을위한 시간을 허용 X.이의 기술적 인 세부 사항에 관심이 있는지 물어 당신이 준비하고, 토론을 완화합니다. 토론하는 동안 화이트 보드 나 종이를 가지고 있어야 세부 사항을 실제로 볼 수 있습니다.

때때로 시스템 연구원들과 협력 한 이론가로서 말하기를, 수학적 세부 사항은 제가 가장 마지막 으로 이야기하고 싶은 것입니다!

잘못된 것을 공식화하는 것은 정말 쉽고, 엄청난 시간 낭비 일뿐만 아니라 정말 혼란 스럽습니다. 수학은 망치가 아닌 바늘이며 바늘의 각 b은 매우 비쌉니다. 내가 교회 공동 연구에 대해 시스템 연구자와 대화하고 있다면, 교회의 어떤 수학적 행사에 오기 전에 다음을 알고 싶다.

1. 그가 해결하려고하는 문제는 무엇이며, 누가 관심을 갖는가?
2. 그들이이 문제를 공격하기 위해 현재 사용하고있는 기술은 무엇입니까?
3. 그럴듯한 대안은 무엇입니까?
4. 솔루션의 제약 조건은 무엇입니까?
5. 그러한 제약으로 인해 어떻게 선택이 이루어 졌습니까?

이것들은 대부분 다른 예비 협력자가 알고 싶어하는 것과 동일하며, 그 이유는 생산적인 공격 라인 (수학적 또는 다른 방법)을 파악하기 위해 유지해야하는 것이 무엇인지 명확하게 이해해야하기 때문입니다. 모델에서 무엇이 중요하지 않습니다.

예를 들어, HCI 연구원과 협력하는 시스템 연구원은 HCI 담당자가 사용자 연구를 수행하는 데 유용한 실험 프로토콜을 설계하기 전에 동일한 프로세스를 거쳐야합니다. 문제의. 수학적 모델링에 대한 기대치도 동일해야합니다!

또한, 가장 중요한 요소는 대개 내가 이야기하는 사람의 좋은 취향과 공학적 감각에 살기 때문에 이러한 답변으로도 첫 번째 반올림이 잘못되는 경우는 거의 항상 그렇습니다. 좋은 미학을 가르치고 배우는 것은 어렵지만 그러한 협력이 가치가있는 이유이기도합니다.

나는 Neel의 답변을 정말로 좋아했으며, 때로는 더 많은 사람들과 협력하는 이론가로서의 내 경험 중 일부를 공유하도록 영감을주었습니다. 가장 어렵고 실망스러운 공동 작업 단계 중 하나는 공통 언어를 찾는 것이므로 문제를 올바르게 형식화 할 수 있습니다. 내 경험상, 이론가가 풀어야 할 문제를 제기 할 때 사람들은 관련이없는 세부 사항을 너무 많이 제시하는 경향이있다. 예를 들어, 시계열을 예측하려는 경우 이러한 금융 거래에는 이러한 방식으로 활용하려는 규제가 적용된다고 5 분 동안 알려 주어야합니까?

이론가들과 대화하기위한 구체적인 제안 : 불필요한 세부 사항을 모두 제거해보십시오. 배송 경로를 최적화하려는 경우 특정 주소를 알려주는 대신 지점 과 거리 에 대해 이야기하십시오. data 에 대해 이야기 할 때 문자열, 숫자 형 벡터, 이미지 (어떤 형식으로되어 있는지) 유형을 즉시 말하십시오. 레이블이 있거나 레이블이 없습니까? 전자의 경우 레이블 (이진, 다중 클래스, 다중 레이블, 텍스트 주석, 실제 값)의 "유형"은 무엇입니까?

$d$