파이썬이 고성능 / 과학 컴퓨팅에 사용되는 이유는 무엇입니까 (하지만 루비는 그렇지 않습니까)?


106

PyCon 2011 강연에서 인용내용 은 다음과 같습니다.

적어도 우리의 상점 (Argonne National Laboratory)에는 과학 컴퓨팅을위한 3 개의 언어가 있습니다. 이 순서대로 그들은 C / C ++, 모든 방언의 Fortran 및 Python입니다. Ruby, Perl, Java의 절대 및 전체 부족을 알 수 있습니다.

보다 일반적인 컴퓨팅 환경에서 사용되었습니다. 이 인용문은 한 상점에서만 나온 것이지만 HPC 언어에 대한 또 다른 질문은 파이썬을 배우는 것으로 (루비가 아닌) 나열합니다.

이제 C / C ++ 및 Fortran이 해당 문제 공간에서 사용되는 것을 이해할 수 있습니다 (그리고 Perl / Java 는 사용 되지 않음 ). 그러나 HPC에서 Python과 Ruby의 사용이 상당히 유사하다는 점에서 큰 차이가 있다는 사실에 놀랐습니다. (참고-저는 파이썬의 팬이지만 루비 는 아무런 관련이 없습니다 ).

일부 거기에 특정 하나 개의 언어가 이륙 왜 이유는? 사용 가능한 라이브러리에 관한 것입니까? 특정 언어 기능? 커뮤니티? 아니면 단지 역사적 연속성 일 수도 있고, 다른 방향으로 갈 수도 있었을까요?


2
동적 언어이지만 파이썬과 루비는 상당히 다릅니다. 비슷한 것보다 더 다릅니다.
Adam Crossland

20
나는 이것이 답이라는 것을 모르지만, 루비가 Rails와 함께 작은 커뮤니티 밖으로 나가기 전에 파이썬이 더 많은 '추적 력'을 가졌다는 것을 기억하십시오 (2005-2006 년경). 구글은 한동안 파이썬을 사용해 왔는데, 이로 인해 (2000 년대 초) 프로파일이 높아졌다. 파이썬의 구문은 명확하고 배우기 쉽고 읽기 쉽습니다 (그리고 이것이 Perl이 실제로 유일한 다른 주요 옵션이었을 때였 음을 기억하십시오). 그 후 사람들이 NumPy / SciPy, MatPlotLib 및 기타 많은 과학 컴퓨팅 패키지를 만들었을 때 자체 강화 작업 일 것입니다.
wkl

4
이 질문에 관심있는 사람들은 Computational Science 스택 교환 사이트 를 확인하는 데 관심이 있습니다.
Mark Booth

2
"가독성"
jsbueno

1
일부 계산 화학 관점을 제공하기 위해 계산을 파이썬과 병렬화하는 것도 쉽지 않습니다. 아마도 둘 다 루비에서도 마찬가지입니다. 모르겠어요
Jonathan Landrum

답변:


108

내 의견을 확장하겠습니다.

과학적 컴퓨팅에서 파이썬의 사용에 영향을 미치는 몇 가지 요소가 있다고 생각하지만 "그렇습니다. 파이썬이 루비 / 다른 어떤 것보다 파이썬을 사용하는 이유입니다." "

초기 역사

파이썬과 루비는 거의 같은 나이입니다. 위키 백과에 따르면, 파이썬은 공식적으로 1991 년에 처음 출시되었고 루비는 1995 년에 출시되었습니다.

그러나 구글이 이미 파이썬을 사용하고 밀레니엄 시대에 파이썬 개발자를 찾고 있었기 때문에 파이썬이 루비보다 일찍 눈에 띄게되었습니다. 우리가 프로그래밍 언어 사용의 역사와 그 언어를 사용하는 사람들에게 미치는 영향을 잘 정리 한 것은 아니기 때문에, 구글이 파이썬을 초기에 채택한 것은 Matlab, C ++, 포트란, 스타 타, 수학 등

즉, Google은 수천 대의 머신 (병렬화 및 스케일링 생각)이 있고 수백만 개의 데이터 포인트 (다시 스케일)를 지속적으로 처리하는 시스템에서 Python을 사용하고 있음을 의미합니다.

이벤트 합류

과학 컴퓨팅은 SGI 및 Crays와 같은 특수 기계에서 수행되었지만 (기억해야합니까?) 물론 FORTRAN은 상대적 단순성으로 인해 더 쉽게 최적화 될 수 있었기 때문에 널리 사용되었습니다.

지난 10여 년 동안 상용 하드웨어 (백만장자가되지 않아도 될 수있는 물건을 의미 함)는 과학적이고 방대한 컴퓨팅 영역에서 인수되었습니다. 상기 봐 현재 상위 500 순위 - 세계의 '슈퍼 컴퓨터의 순위 상단의 많은 정상 인텔 / AMD 하드웨어에 내장되어 있습니다.

구글이 파이썬을 홍보하고 구글이 상용 하드웨어를 사용하고 수천 대의 머신을 보유한 이후로 파이썬은 좋은시기에 들어 왔습니다.

또한 오래된 과학 컴퓨팅 기사를 파헤 치면 2000 년 무렵부터 시작되었습니다.

이전 지원

다음 은 2000 년에 작성된 천문학적 데이터 분석 소프트웨어 및 시스템 용으로 작성된 기사로 , 과학 컴퓨팅을위한 언어로 파이썬을 제안합니다.

이 기사에는 Python에 대한 다음 인용문이 있습니다.

Python은 과학 응용 프로그램에서 상당한 주목을 받기 시작한 해석 된 객체 지향 프로그래밍 언어입니다 (Python, 1999). 파이썬과 스크립팅 언어는 많은 과학 프로젝트의 다음 단계를 나타 내기 때문입니다 (Dubois 1994). 첫째, 파이썬은 과학 프로그램에 의해 이미 사용 된 간단한 명령 언어의 확장으로 볼 수있는 해석 된 프로그래밍 언어를 제공합니다

둘째, 파이썬은 다른 언어로 작성된 소프트웨어와 쉽게 통합됩니다. 결과적으로 기존 프로그램을 구동하기위한 제어 언어와 서로 다른 시스템을 결합하기위한 글루 언어로 사용될 수 있습니다. 마지막으로 Python은 서드 파티 및 온라인 참조 형식의 다양한 타사 모듈 모음, 확립 된 사용자 기반 및 다양한 문서를 제공합니다. 이런 이유로, 과학자들은 자신의 명령 해석기를 작성할 때 종종 과학자들이 달성하려고하는 것의 고도로 세련되고 확장 된 버전으로 볼 수 있습니다.

따라서 파이썬은 이미 기존 시스템과 기능적으로 유사하고 파이썬을 C 및 기존 프로그램과 같은 것들과 쉽게 통합하기 때문에 90 년대 후반으로 거슬러 올라간 견인력을 가지고 있음을 알 수 있습니다. 기사의 내용을 바탕으로 파이썬은 이미 1995-1996 시대로 거슬러 올라가 과학적으로 사용되었습니다.

인기 성장의 차이

루비의 인기는 2004 년에 처음 등장한 루비 온 레일즈와 함께 폭발적으로 증가했습니다. 루비에 대한 소문을 처음 들었을 때 저는 대학에 있었고 2005-2006 년 무렵이었습니다. 파이썬 용 django는 같은 시간대에 발표되었지만 (Wiki에 따르면 2005 년 7 월) 루비 커뮤니티의 초점은 웹 애플리케이션에서의 사용을 촉진하는 데 크게 집중된 것으로 보였다.

반면에 파이썬에는 과학적 컴퓨팅에 적합한 라이브러리가 이미 있습니다.

  • NumPy -NumPy는 2005 년에 공식적으로 시작되었지만, Numeric (1995)과 Numarray (2001?)라는 두 라이브러리가 이전에 릴리스되었습니다.

  • BioPython -Python 용 생물학적 컴퓨팅 라이브러리, 2001 년으로 거슬러 올라갑니다.

  • SAGE -2005 년 초에 최초 공개 릴리스가 포함 된 수학 패키지

그리고 더 많은 것은 (다운로드 사이트를 탐색하는 것 외에도) 많은 타임 라인을 모르지만 Python에는 SciPy (2006 년에 릴리스 된 NumPy를 기반으로 함)가 있으며 R (통계 언어)과 바인딩되었습니다. 2000 년대 초에 MatPlotLib을 얻었고 ipython에서 정말 강력한 쉘 환경을 얻었습니다.

ipython 은 2000 년대 초에 처음 출시되었으며 통합 된 matplotlib 그래프 및 계산 클러스터 관리 와 같은 과학 컴퓨팅에 매우 유용한 많은 기능이 추가되었습니다 .

위 기사에서 :

또한 많은 다른 파이썬 관련 과학 컴퓨팅 프로젝트에 주목할 가치가 있습니다. 숫자 파이썬 확장은 파이썬에 빠른 배열 및 행렬 조작을 추가하고 (Dubois 1996), MMTK는 분자 모델링을위한 Python 기반 툴킷 (Hinsen 1999)이며, Biopython 프로젝트는 생명 과학 연구를위한 Python 기반 도구를 개발하고 있습니다 (Biopython 1999). VTK (Visualization Toolkit)는 Python 바인딩이 포함 된 고급 시각화 패키지입니다 (VTK, 1999). 또한 Python 커뮤니티에서 진행중인 프로젝트는 이미지 처리 및 플로팅을위한 확장 기능을 개발하고 있습니다. 마지막으로 (Greenfield, 2000)에 제시된 작업은 STScI의 프로젝트에서 Python을 사용하는 것에 대해 설명합니다.

좋은 파이썬에 대한 과학 및 숫자 패키지의 목록 .


따라서 많은 것은 아마도 초기 역사와 2000 년대까지 루비의 상대적인 모호성 때문일 것입니다. 반면에 파이썬은 구글의 전도 덕분에 인기를 얻었습니다.

1995 ~ 2000 년 사이에 스크립팅 언어를 평가하고 있다면 실제로 무엇을보고 있었습니까? 사람들이 사용하고 싶지 않은 문법적으로는 Perl이 있었고, 더 명확한 구문과 더 나은 가독성을 가진 Python이있었습니다.

그리고 아마도 많은 자기 강화가있을 것입니다-파이썬에는 이미 과학 컴퓨팅을위한 위대하고 유용한 라이브러리가 모두 있으며 루비에는 과학에서의 사용을 옹호하는 소수의 목소리가 있으며 SciRuby 와 같은 일부 라이브러리가 생겨납니다 . Python의 도구는 지난 10 년 동안 발전했습니다.

루비의 커뮤니티는 대체로 루비를 웹 언어로 발전시키는 데 훨씬 더 관심이있는 것 같습니다. 왜냐하면 그것이 실제로 잘 알려 졌기 때문입니다. 반면에 파이썬은 다른 경로에서 시작하여 나중에 웹 언어로 널리 사용되었습니다.


8
나는 c 통합에 대해 조금 잊었다. 많은 경우 과학 계산은 계산 집약적이며 해당 비트에 대해서만 AC 루틴을 작성할 수 있다는 것이 중요한 이점입니다.
스펜서 Rathbun

1
@SpencerRathbun이 기사에서는 SWIG과 함께 Python을 사용하여 래퍼를 생성하고 Python이 C / C ++ 코드와 상호 작용할 수 있도록 언급했습니다. SWIG는 2004 년에 출시 된 Ruby 1.6 이전까지 공식적인 Ruby 지원을받지 못했습니다. 따라서 Python은 이미 사람들이 Python을 기존 시스템에 볼트로 고정 할 수 있도록하기 위해 이미 큰 관심을 가지고있었습니다. 사용중인 기존의 최적화 된 FORTRAN / C 코드를 모두 버리지 않아도 가장 큰 드라이버 일 것입니다.
wkl

3
1991 년에 우리는 대량의 C / Fortran을 쓰지 않고도 데이터를 분석하는 방법으로 숫자 라이브러리를 연결하기 위해 TCL을 사용했습니다. 파이썬은 TCL을 교체하기 위해 적시에 나왔습니다. (그리고 포트란과 F2C에 의해) 'C'와 인터페이스의 용이성 PERL, 'C'로 TCL 인터페이스에 비해 큰 문제는 매우 간단이었다
마틴 베켓

우선 첨부 과정 은 어떤 언어가 사용되는지에 대해 많은 설명을합니다. Zipfian입니다! 참조 이는 Zipf Myatery "PAP는"그것으로 12시 50분에 설명되어 있습니다.
radarbob

37

엔지니어링 응용 프로그램에는 Python을, 웹 응용 프로그램에는 Ruby를 광범위하게 사용했습니다.

루비를 과학 언어로 볼 때의 문제는 주어진 작업에 너무 많은 구문 옵션이 있다는 것입니다.

파이썬은 다음과 같은 전제로 설계되었습니다. "한 가지 분명한 방법이 있어야합니다." 이를 통해 누군가의 코드를 쉽게 읽고 의도를 파악할 수 있습니다. 엔지니어링 등을위한 피어 리뷰의 핵심입니다.

나는 Ruby를 좋아하고 특정 작업에는 훌륭하지만 Ruby 코드는 구문이 완전히 다른 프로그래머의 코드와 완전히 똑같을 수 있습니다. 이것은 과학 또는 엔지니어 환경에서 너무 모호합니다.


3
네 확실합니다. 루비는 TIMTOWTDI 전통에 있으므로 약간 더 나은 Perl입니다. 소프트웨어는 프로그래머를 위해 작성되었습니다. 이런 의미에서 컴파일러 / 통역사는 2 차 청중입니다. 과학자들은 불필요하게 어려운 소프트웨어의 방해없이 업무를 수행하는 데 진지한 경향이 있습니다. QED
Dominic Cronin

4
이 주장을 잘 모르겠습니다. 기계가 아닌 프로그래머가 주요 대상인 경우, 문구를 다르게 표현하여 선명도를 향상시키고 의도를 강조하는 경우가 있습니다. 더 유연한 언어가 부드러운 인간 두뇌의 이해를 돕지 않습니까?
앤드류 비타

10
그러나 C는 ASCII Factory에서도 폭발처럼 보일 수 있습니다. C에서 배열은 포인터 주변의 스킨입니다. 따라서 array [5]는 * (array + 5)로 작성 될 수 있으며, 대안 적으로 5 (array)로 작성 될 수있는 * (5 + array)로 작성 될 수 있습니다. 바보입니다.
Jonathan Landrum

1
저는 매우 장기적인 펄 프로그래머이며 대부분의 목적에 가장 좋아하는 언어로 남아 있습니다. 그래도 수학에 대해서는 확실하지 않습니다. TIMTOWTDI 접근 방식에 대한 이러한 태도에 동의하지 않습니다. 여러 가지 접근 방식을 사용할 수 있다고해서 모든 것이 다 좋은 것은 아니지만 표현을 사용자 정의하여 사람과 기계 청중 모두에게 표현하는 아이디어에 명확하고 직접 매핑되도록하는 것이 중요합니다. 구문 옵션이 부족해도 도움이되지 않습니다.
mc0e

@AndrewVit : 반드시 그런 것은 아닙니다. TIMTOWTDI는 개발자가 한 명이거나 작고 긴밀하게 통합 된 개발자 팀이있는 경우 효과적입니다. 그러나 바로이 같은 코드 작업을 만난 적이없는 사람들이, 당신이 자신을 물어 시작하는거야 가지고 "아, 왜 그것을 할 것입니다 방법은?" 또는 모든 사람이 같은 방식으로 작업하도록 강제하는 스타일 가이드를 작성하면 더 이상 TIMTOWTDI를 수행하지 않습니다.
Kevin

17

추측하자면, 많은 부분이 많은 연구자들에 의해 matlab 에 의존 할 것 입니다. 파이썬에는 sage 와 같은 대안이 있습니다. 루비는 그렇지 않지만 적어도 명백한 것은 없습니다.

두 번째로 Ruby FAQ에 따르면 파이썬은 절차 지향적이며 객체 지향적이며 루비 는 절차 적 언어로 가장 합니다. matlab에서와 같이 수학 목적으로 작은 스크립트를 작성하는 경우 OO 패러다임은 두통입니다. 뿐만 아니라 연구자들이 사용하는 기능적 / 절차 적 패러다임으로부터 개념적인 도약을 강요합니다. 수학 OO 가 아닙니다 . 수학은 기능적이며 절차 적입니다 (논리적 증거를 생각하십시오).

마지막으로, Ruby FAQ는 루비가 파이썬보다 더 복잡하다고 명시합니다. 우리와는 달리 프로그래밍은 연구자들에게 두 번째로 나옵니다.


22
나는 OO가 약간 빨간 청어라고 생각합니다. 연구원은 표현식 1 + 1이 메시지 +를 객체에 보낼지 여부를 어떻게 관리 1합니까? 그것은 프로그램의 구조를 조금도 바꾸지 않습니다.
sepp2k

1
@ sepp2k, Spencer는 Ruby가 과학자들이 다르게 프로그래밍 하도록 요구할 것이라고 제안합니다 . Ruby를 모르지만 Ruby 로 프로그램을 작성하기 위해 객체를 작성 해야 한다고 가정 하지만 Python은 절차를 허용하므로 정신적 오버 헤드가 추가됩니다. 많은 것이 아니라 프로그래머가 아닌 사람에게는 많은 추가 작업이 다른 언어를 사용해야하는 이유가됩니다.
Cyclops

7
@ Cyclops 나는 그가 제안하는 것을 얻습니다. 나는 그것이 틀렸다고 말하고있다. 절차 적 언어로서 루비 마스커레이딩에 대한 인용의 요점은 프로그램을 객체 지향 방식으로 구성 할 필요가 없다는 것입니다. "2 + 2"와 같은 것을 입력하면 두 개의 Integer 객체를 만들고 하나의 메서드를 호출합니다 (다른 하나는 인수로 전달 함). 그러나 루비에서 "2 + 2"를 입력하는 것이 다른 언어로 "2 + 2"를 입력하는 것보다 더 많은 노력을 기울이지 않습니다.
sepp2k

5
나는 sepp2k를 사용하고 있으며 그 주장도 사지 않습니다. Java와 같은 일부 언어는 Ruby와 달리 OO 패러다임을 강요합니다. 루비에서 순전히 절차 적 또는 기능적 프로그램을 작성하는 데 방해가되는 것은 무엇입니까?
Mike Baranczak

2
@Cyclops 정확하게. 루비는 절차적인 을 할 수 있지만 사소한 상황에서는 OO 패러다임이 언어를 특정 방식으로 작동시키는 상황에 처하게됩니다. 이해하지 못하거나 무시하면 원하는 것을 할 수 없거나 지저분한 해킹으로 끝납니다.
Spencer Rathbun

14

BDFL (Guido van Rossum)이 처음 Python을 작성했을 때의 목표는 일반적인 코딩 오류를 제거하는 평범한 영어 (DARPA 자금 제안)만큼 이해가 가능하다는 것이 었습니다.

눈에 잘 띄는 문제는 들여 쓰기를 사용하여 블록을 구분하는 것입니다. 명시 적으로 복잡한 명령문 구분 기호 (예 : C 중괄호, Pascal BEGIN / END)가있는 언어에서는 코드를 어휘 분석기에 공급하기 전에 공백이 단일 공백 ​​문자로 축소됩니다. 이렇게하면 코드 레이아웃 방식이 크게 달라질 수 있습니다.

전문 프로그래머에게는 일주일에 30 시간 이상 연습하도록 훈련했기 때문에 문제가되지 않습니다.

프로그래밍이 도구 인 다른 전문가에게는이 문제가 큰 문제가됩니다. 이 그룹에는 수학자, 물리학 자, 화학자, 엔지니어 등이 포함됩니다.

파이썬은 비전문가 프로그래머의 오류를 줄이므로, 그들이 해결하려는 문제에 대해 생각할 수있게하며 언어의 역학을 다루지 않아도됩니다.

이것이 프로그래밍 직업 외부에서 인기있는 이유의 단일 예입니다. 배터리 포함, Python of Zen ( import this), Monty Python 유머 사용 등과 같은 동일한 요점을 설명하는 데 사용할 수있는 다른 예가 있습니다 .


귀도의 이력서 또는 출판물 목록 에서 논문 또는 박사 과정에 대한 언급을 찾을 수 없습니다 . 이에 대한 인용이 있습니까? 이 인터뷰 는 그가 CWI의 연구원이라고 말했습니다.
M. Dudley

나는 그가 완전히 엉망이되었다. 나는 그가 한 논문에 대한 논문이지만, 그것에 대한 적절한 연구를하지 않았다는 것을 읽었다. 이 게시물을 작성한 후 내 오류를 발견했지만 여기에서 수정하지 않았습니다. 감사.
랜스 Helsten

5

이것은 훌륭한 토론입니다. 여기의 게시물은 왜 파이썬이 과학계에서 더 인기가 있는지에 대한 답이라고 생각합니다. 그러나 루비 과학에 대한 반론이 있습니다.

  • 루비는 파이썬 (DSL 등)보다 직관적으로 코딩 될 수 있습니다.

    bioruby 확인 : http://bioruby.org/을 시퀀스 예비 간단하게 될 수 있습니다 s.reverse 등이 데이터베이스를 사용하는 경우 : 루비 데이터베이스 바인딩 API는 틀림없이 파이썬보다 낫다.

  • 루비는 간결한 동시에 더 높은 수준의 추상화를 허용합니다.

  • 더 나은 패키지 관리 시스템 : 루비 젬은 setuptools, pip 등에 비해 훨씬 쉽습니다.

그러나 루비의 채택은 그 복잡성으로 인해 방해를받을 것입니다. 나는 Lisp가 훌륭하고 강력한 언어라고 생각하지만 왜 일반 언어로 이륙하지 않았습니까? 비슷한 상황은 루비와 함께 여기에 있습니다-lisp, small talk 및 perl!에서 많은 힘을 상속받습니다. 결국, 특정 틈새 / 특수 영역 (웹의 레일, 구성의 꼭두각시 등)에서 강하게 유지 될 수 있지만 '비'프로그래머는 완전히 즐기기가 어렵지만 프로그래머의 좋은 친구 일 수 있습니다 (일부 컴퓨터를 보았습니다) 과학자들은 언어를 즐깁니다 : http://www.cleveralgorithms.com/nature-inspired/index.html )

가장 최근의 업데이트 : 파이썬이 이미 경관을 인계하고있는 것 같습니다. 최근 : http://www.amazon.com/Python-Data-Analysis-Wes-McKinney/dp/1449319793 및 기타 많은 책 (데이터 분석, 기계 학습 등)과 같은 책은 모두 사용 된 언어로 파이썬으로 작성되었습니다. . 루비가 따라 오려면 진지한 노력이 필요합니다. 파이썬에서 matplotlib을 고려할 때 아마도 현재 상태로 만드는 데 몇 년이 걸릴 것입니다. 진지한 노력이 루비에 들어 가지 않으면, 아마도 2-3 년 안에 파이썬 데이터 분석 / 과학 계산 단계를 따라 잡을 수 없을 것입니다.


3

ruby, lua 및 R을 사용한 경험에서 비롯된 데이터 분석을 위해 파이썬을 잠시 사용한 후, numpy 패키지 (및 많은 관련 과학 라이브러리)는 빠른 계산을 수행 할 수있게합니다 (numpy와 같이 C와 유사한 속도) 파이썬에서 프로그래밍하기 쉽도록 C 코드와 함께 작성 / 통합됩니다.

Numpy는 한동안 존재 해 왔으며, 가용성은 scipy, pandas 등과 같은 많은 다른 관련 과학 패키지를 구축하는 데 도움이되었습니다. 훌륭한 도구는 파이썬을 과학 컴퓨팅을위한 훌륭한 생태계로 만드는 반면 Ruby에서는 유사한 빠른 매트릭스 계산 라이브러리가 개발 중입니다 (NMtrix : https://github.com/SciRuby/nmatrix ). 이 거대한 타이밍 차이로 인해 파이썬은 과학 컴퓨팅에 대한 확실한 선택입니다.


5
"결국, 파이썬은 모든 사람의 언어와 같습니다."이를 백업 할 소스를 제공해야합니다.
Walter

2

나는이 같은 것을 궁금해했다. Spencer Rathbun이 말했듯이 파이썬의 절차 적 측면 때문에 그렇게 생각합니다. "비 프로그래머"이기 때문에 Ruby로 코딩 할 수있는 방법이 아름답다는 것을 알게되었습니다. Rails 프레임 워크는 사용하기 편리합니다. 그러나 과학적 목적 (수학, 생물학 등)으로 코딩 할 때 일반적으로 "수학적"언어로 생각합니다. 즉,

Person.find_by_name 'Juanito'

하지만 넌 더 신경써

A = B*C + D

그래서 루비는 많은 기능이 과학 프로그램에서 사용되지 않을 정도로 강력하다고 생각합니다. 절차를 생각하는 것이 더 쉽습니다.


0

Python은 Numpy 패키지를 사용하여 N 차원 배열을 더 잘 지원합니다. 루비와 비슷한 것을 보지 못했습니다.

파이썬은 내가 한 수치 컴퓨팅 / 과학 컴퓨팅에서 더 빠른 것 같습니다. 파이썬과 루비에서 비슷한 알고리즘을 작성할 때 외에는 파이썬 알고리즘이 더 빨리 실행되었습니다 (YMMV).


2
이것은 실제로 토론에 크게 기여하지는 않습니다. Numpy의 효과는 이미 받아 들여진 답변 에 자세히 설명되어 있습니다. 당신의 수행 주장은 설득력이 없습니다. 나는 역사적 성과를 논의 할 때 일화에 의존하는 것을 좋아하지 않습니다. 특히 그러한 주장이 이미 신뢰할 수있는 (잘, 맥락이없는 일화보다 더 신뢰할 수있는) 벤치 마크로 잘 덮여있을 때 특히 그렇습니다.
Brian

@ 브라이언은 동의했다.
Josh Petitt

@Brian, 내 특정 기여는 N 차원 배열에 대한 의견이었습니다. 이것이 Numpy가 만들어지는 핵심입니다. 그렇지만 ND 어레이에 대해서는 언급하지 않았습니다. 이것이 선형 대수의 핵심이며 Matlab과 Numpy가 잘하는 일입니다. 루비는 프로그래머가 배열을 사용하는 것처럼 엔지니어를 사용하고 과학자가 배열을 사용하는 것처럼 (예 : 행렬) 배열을 사용합니다. 도움이 될 것이라고 생각되면 수락 된 답변에 ND 배열에 대한 의견을 추가 할 것입니다.
Josh Petitt

@Brian, 나는 여전히 과학 컴퓨팅을 위해 Ruby에 대한 좋은 ND 배열 지원을 보지 못했다는 내 의견을지지합니다.
Josh Petitt

0

한가지 이유는 파이썬이 C / C ++ 코드의 사용 / 통합 / 호출을 잘 지원하는 반면, 루비는 같은 정도의 통합을 제공하지 않습니다. 즉, C / C ++로 고성능 코드 구성 요소를 작성한 다음 Python (즉, 눈에 잘 띄는 언어)을 사용하여 모든 것을 함께 붙일 수 있습니다. 이것이 Google의 초기 제도적 채택 이유 중 하나라고 생각합니다.


0

파이썬이 데이터 과학으로 인기를 얻은 주요 이유 중 하나는 실제 솔루션 (예 : 소프트웨어 시스템)에 대한 스크립트를 확장하기 위해 절약 할 수있는 시간 / 노력 (예 : 돈) 때문이었습니다. Python을 사용하면 데이터 과학을 위해 작성한 코드를 기반으로 시스템 솔루션을보다 쉽게 ​​구축 할 수 있습니다.

약 15 년 전에이 기능으로 통역사 언어를 검색 한 경험이 있습니다. 당시 파이썬은 데이터 과학을위한 완벽한 언어가 아니라 C / C ++ /와 같은 다른 언어와의 인터페이스로 확장 할 수있는 빠른 / 휴대용 인터프리터가있는 희귀 한 OOP 언어이기 때문에 파이썬으로 선택되었습니다. 자바. 오늘날과는 달리, 데이터 과학을 위해 이미 구현 된 기본 코드에서 솔루션을 직접 빌드하는 데는 위대하지만 드문 기능이었습니다.

시간은 데이터 과학 언어를 만드는 또 다른 중요한 요소 일 수 있습니다. 15 년 전, 파이썬에서 숫자 계산을위한 숫자 및 scipy와 같은 기본 패키지가 이미 있다는 것을 알았지 만 프로그래밍 언어로 Ruby의 존재조차 알지 못했습니다. 2018 년 말 현재 데이터 과학에 Ruby를 사용하는 여러 프로젝트를 찾을 수있었습니다. 아마도 10 년 후 루비가 AI에 왜 그렇게 인기가 있는지 묻습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.