จูเลียมีความหวังใด ๆ หรือไม่ที่จะติดอยู่ในชุมชนทางสถิติ?

ฉันเพิ่งอ่านโพสต์จาก R-บล็อกที่เชื่อมโยงกับการโพสต์บล็อกนี้จากจอห์นไมลส์สีขาวเกี่ยวกับภาษาใหม่ที่เรียกว่าจูเลีย จูเลียใช้ประโยชน์จากคอมไพเลอร์ทันเวลาที่ให้เวลาการรันที่รวดเร็วและทำให้มันมีความเร็วเท่ากันกับ C / C ++ ( ลำดับเดียวกันไม่เร็วเท่ากัน) นอกจากนี้ยังใช้กลไกการวนลูปดั้งเดิมที่พวกเราที่เริ่มเขียนโปรแกรมเกี่ยวกับภาษาดั้งเดิมคุ้นเคยกับแทนที่จะใช้คำสั่ง R และการดำเนินการเวกเตอร์

R จะไม่หายไปด้วยวิธีการใด ๆ แม้จะมีการกำหนดเวลาที่ยอดเยี่ยมเช่นนี้จากจูเลียก็ตาม มีการสนับสนุนอย่างกว้างขวางในอุตสาหกรรมและแพ็คเกจที่ยอดเยี่ยมมากมายที่จะทำอะไรก็ได้

ความสนใจของฉันคือ Bayesian ในธรรมชาติซึ่งมักจะเป็นไปไม่ได้ที่ vectorizing แน่นอนว่างานอนุกรมต้องทำโดยใช้ลูปและเกี่ยวข้องกับการคำนวณหนักในแต่ละการทำซ้ำ R อาจช้ามากในงานวนลูปอนุกรมเหล่านี้และ C / ++ ไม่ใช่การเดินในสวนเพื่อเขียน จูเลียดูเหมือนเป็นทางเลือกที่ยอดเยี่ยมสำหรับการเขียนใน C / ++ แต่มันยังอยู่ในช่วงเริ่มต้นและขาดฟังก์ชั่นมากมายที่ฉันชอบเกี่ยวกับอาร์มันน่าจะเหมาะที่จะเรียนรู้ว่าจูเลียเป็นสถิติทางคอมพิวเตอร์ จากชุมชนสถิติและผู้คนเริ่มเขียนแพ็คเกจที่เป็นประโยชน์สำหรับมัน

คำถามของฉันเป็นไปตาม:

1. จูเลียจำเป็นต้องมีฟีเจอร์อะไรเพื่อให้มีเสน่ห์ที่ทำให้ R เป็นภาษาของสถิติอย่างแท้จริง?

2. อะไรคือข้อดีและข้อเสียของการเรียนรู้ Julia ในการทำงานหนักเชิงคำนวณเทียบกับการเรียนรู้ภาษาระดับต่ำเช่น C / ++?

ฉันคิดว่าสิ่งสำคัญคือห้องสมุดจะเริ่มพัฒนาเพื่อจูเลียหรือไม่ มันเป็นเรื่องที่ดีและดีที่จะเห็นตัวอย่างของเล่น (แม้ว่าพวกเขาจะเป็นของเล่นที่มีความซับซ้อน) แสดงให้เห็นว่าจูเลียพัด R ออกจากน้ำในงานที่ R ไม่ดี

แต่ลูปที่ทำไม่ดีและอัลกอริธึมการเขียนโค้ดด้วยมือไม่ใช่สาเหตุที่หลายคนที่ฉันรู้จักที่ใช้ R use R พวกเขาใช้เพราะเกือบทุกงานทางสถิติภายใต้ดวงอาทิตย์มีคนเขียนรหัส R ไว้ R เป็นทั้งภาษาโปรแกรมและแพ็คเกจสถิติ - ปัจจุบัน Julia เป็นเพียงอดีต

ฉันคิดว่ามันเป็นไปได้ที่จะไปถึงที่นั่น แต่มีภาษาที่ได้รับการยอมรับมากขึ้น (Python) ที่ยังคงต่อสู้กับการเป็นชุดเครื่องมือทางสถิติที่ใช้งานได้

ฉันเห็นด้วยกับความคิดเห็นอื่น ๆ มากมาย "ความหวัง"? แน่ใจ ฉันคิดว่า Julia ได้เรียนรู้มากมายจากสิ่งที่ R และ Python / NumPy / Pandas และระบบอื่น ๆ ได้ทำถูกและผิดในช่วงหลายปีที่ผ่านมา ถ้าฉันฉลาดกว่าฉันและต้องการเขียนภาษาการเขียนโปรแกรมใหม่ที่จะเป็นสารตั้งต้นสำหรับสภาพแวดล้อมการพัฒนาทางสถิติในอนาคตมันจะดูเหมือนจูเลียมาก

สิ่งนี้กล่าวว่าจะใช้เวลา 5 ปีก่อนที่คำถามนี้อาจตอบได้ในแบบย้อนหลัง ณ ตอนนี้ Julia ยังขาดประเด็นสำคัญต่อไปนี้ของระบบการเขียนโปรแกรมเชิงสถิติที่สามารถแข่งขันกับ R สำหรับผู้ใช้ประจำวัน:

(รายการอัปเดตเมื่อเวลาผ่านไป ... )

• ตัวเลือกประเภทปัจจัยสั่ง
• การทดสอบทางสถิติและแบบจำลองทางสถิติส่วนใหญ่
• สนับสนุนการเขียนโปรแกรม / การวิเคราะห์ที่สามารถอ่านออกเขียนได้จริง
• คลาส R หรือคลาสพล็อต Matlab

ในการแข่งขันกับแพ็คเกจ R, Julia และโปรแกรมเสริมจะต้องมีความสะอาดเพียงพอและสมบูรณ์เพียงพอที่นักเขียนโปรแกรมที่ไม่ฉลาดเช่นนักเรียนระดับบัณฑิตศึกษาในสาขาสังคมศาสตร์สามารถใช้มันได้อย่างสมเหตุสมผล มีงานมากมายที่ต้องไปที่นั่น บางทีมันอาจจะเกิดขึ้นบางทีมันอาจจะมอดลงหรืออาจเป็นอย่างอื่น (R 3.0?) จะแทนที่มัน

ปรับปรุง:

ตอนนี้ Julia รองรับ DataFrames ที่ไม่มีข้อมูล / NAs, โมดูล / เนมสเปซ, formulaประเภทและmodel.matrixโครงสร้างพื้นฐาน, การพล็อต (sorta), การสนับสนุนฐานข้อมูล (แต่ยังไม่ถึง DataFrames) และการส่งผ่านอาร์กิวเมนต์ด้วยคีย์เวิร์ด ขณะนี้มี IDE (Julia Studio), การสนับสนุน Windows, การทดสอบทางสถิติและการสนับสนุนวันที่ / เวลา

สำหรับฉันสิ่งหนึ่งที่สำคัญมากสำหรับภาษาการวิเคราะห์ข้อมูลคือการมีฟังก์ชันการสืบค้นพีชคณิตเชิงสัมพันธ์ที่มีค่าเริ่มต้นที่สมเหตุสมผลและการออกแบบเชิงโต้ตอบซึ่งควรเป็นภาษาในตัว IMO ไม่มีภาษา FOSS ที่ฉันใช้ทำสิ่งนี้ได้อย่างมีประสิทธิภาพไม่แม้แต่อาร์

data.frame เป็น clunky มากที่จะทำงานกับการโต้ตอบ - ตัวอย่างเช่นมันพิมพ์โครงสร้างข้อมูลทั้งหมดในการภาวนาไวยากรณ์$เป็นเรื่องยากที่จะทำงานกับโปรแกรมการสอบถามต้องมีการอ้างอิงตนเองซ้ำซ้อน (เช่นDF[DF$x < 10]) เข้าร่วมและการรวมตัวเป็นที่น่าอึดอัดใจ Data.table แก้ปัญหาความรำคาญเหล่านี้ได้ส่วนใหญ่ แต่เนื่องจากมันไม่ได้เป็นส่วนหนึ่งของการใช้งานหลักรหัส R ส่วนใหญ่จึงไม่ใช้ประโยชน์จากระบบ

นุ่นในหลามทนทุกข์จากความผิดพลาดเดียวกัน

กริปเปอร์เหล่านี้อาจดูเหมือนจะเป็นไนติงกี้ แต่ความผิดพลาดเหล่านี้สะสมและในที่สุดก็มีความสำคัญอย่างมากในการรวมเข้าด้วยกันเมื่อพวกเขาต้องเสียเวลามาก

ฉันเชื่อว่า Julia จะประสบความสำเร็จในฐานะที่เป็นสภาพแวดล้อมการวิเคราะห์ข้อมูลต้องใช้ความพยายามในการใช้ตัวดำเนินการชนิด SQL (โดยไม่ต้องมีน้ำหนักกระเป๋าของไวยากรณ์ SQL) กับผู้ใช้ที่เป็นมิตรกับตารางชนิดข้อมูล

ฉันสามารถลงชื่อภายใต้สิ่งที่ Dirk และ EpiGrad พูด; แต่มีอีกสิ่งหนึ่งที่ทำให้ R เป็นภาษาเฉพาะในช่องของมันนั่นคือระบบการพิมพ์ข้อมูล

R's ได้รับการออกแบบมาโดยเฉพาะสำหรับการจัดการข้อมูลนั่นเป็นสาเหตุที่ทำให้เวกเตอร์เป็นศูนย์กลางและมีสิ่งต่าง ๆ เช่น data.frames, factor, NAs และคุณลักษณะ
ประเภทของ Julia อยู่บนมืออื่น ๆ ที่มุ่งเน้นประสิทธิภาพเชิงตัวเลขดังนั้นเราจึงมีสเกลาร์โหมดการจัดเก็บที่กำหนดไว้อย่างดีสหภาพและโครงสร้าง

สิ่งนี้อาจดูอ่อนโยน แต่ทุกคนที่เคยลองทำสถิติกับ MATLAB รู้ว่ามันเจ็บจริงๆ

อย่างน้อยสำหรับฉันจูเลียก็ไม่สามารถเสนออะไรที่ฉันไม่สามารถแก้ไขได้ด้วยชิ้นส่วน C สองสามบรรทัดและฆ่าความหมายที่มีประโยชน์มากมาย

ฉันเห็นว่า Julia มาแทนที่ Matlab ซึ่งจะเป็นบริการที่ยิ่งใหญ่สำหรับมนุษยชาติ

ในการแทนที่ R คุณจะต้องพิจารณาทุกสิ่งที่ Neil G, Harlan และคนอื่น ๆ พูดถึงรวมถึงปัจจัยสำคัญอีกข้อหนึ่งที่ฉันไม่เชื่อว่าได้รับการแก้ไข: ติดตั้งแอปพลิเคชันและไลบรารีได้ง่าย

ตอนนี้คุณสามารถดาวน์โหลดไบนารีของ R สำหรับ Mac, Windows หรือ Linux มันทำงานนอกกรอบด้วยวิธีการทางสถิติที่มีให้เลือกมากมาย หากคุณต้องการดาวน์โหลดแพ็คเกจมันเป็นคำสั่งง่ายๆหรือการคลิกเมาส์ มันใช้งานได้

ฉันไปดาวน์โหลด Julia แล้วมันก็ไม่ง่าย แม้ว่าคุณจะดาวน์โหลดไบนารีคุณจะต้องติดตั้ง gfortran เพื่อรับไลบรารี่ที่เหมาะสม ฉันดาวน์โหลดที่มาและพยายามmakeและมันล้มเหลวโดยไม่มีข้อความที่เป็นประโยชน์จริงๆ ฉันมีระดับปริญญาตรีและสูงกว่าปริญญาตรีสาขาวิทยาศาสตร์คอมพิวเตอร์ดังนั้นฉันจึงสามารถไปรอบ ๆ เพื่อให้มันทำงานได้ถ้าฉันมีความโน้มเอียง (ฉันไม่ได้) โจสถิติจะทำเช่นนั้น?

R ไม่เพียง แต่มีแพ็คเกจให้เลือกมากมาย แต่ยังมีระบบที่ค่อนข้างซับซ้อนซึ่งทำให้ไบนารีของแอปพลิเคชันและแพ็คเกจเกือบทั้งหมดโดยอัตโนมัติ ถ้าด้วยเหตุผลบางอย่างคุณจำเป็นต้องรวบรวมแพ็กเกจจากแหล่งข้อมูลนั่นไม่ใช่เรื่องยากอีกต่อไป (ตราบใดที่คุณมีคอมไพเลอร์ที่เหมาะสม ฯลฯ ติดตั้งในระบบของคุณ) คุณไม่สามารถเพิกเฉยต่อโครงสร้างพื้นฐานนี้ทำทุกอย่างผ่าน GitHub และคาดว่าจะมีการนำไปใช้อย่างกว้างขวาง

แก้ไข: ฉันต้องการที่จะเล่นกับจูเลีย - มันดูน่าตื่นเต้น ปัญหาสองประการ:

1) เมื่อฉันพยายามติดตั้งแพคเกจเพิ่มเติม (ลืมสิ่งที่พวกเขาเรียกว่าใน Julia) มันล้มเหลวด้วยข้อผิดพลาดที่คลุมเครือ เห็นได้ชัดว่า Mac ของฉันไม่มีเครื่องมือที่ทำให้พวกเขาคาดหวัง ไม่เพียง แต่จะล้มเหลว แต่ยังทำให้สิ่งที่วางอยู่รอบ ๆ นั้นฉันต้องลบด้วยตนเองไม่เช่นนั้นการติดตั้งอื่น ๆ จะล้มเหลว

2) พวกมันบังคับให้เว้นวรรคในบรรทัดของโค้ด ฉันไม่มีรายละเอียดอยู่ข้างหน้าฉัน แต่มันเกี่ยวกับมาโครและไม่มีช่องว่างระหว่างมาโครกับวงเล็บที่เปิดอาร์กิวเมนต์ ข้อ จำกัด แบบนั้นทำให้ฉันเป็นแมลงจริงๆเนื่องจากฉันได้พัฒนารูปแบบรหัสของฉันในหลายปีที่ผ่านมาและภาษาและฉันได้เว้นช่องว่างระหว่างชื่อฟังก์ชัน / แมโครและวงเล็บเปิด ข้อ จำกัด การจัดรูปแบบโค้ดบางอย่างที่ฉันเข้าใจ แต่มีช่องว่างภายในบรรทัด?

ภาษาจูเลียนั้นค่อนข้างใหม่ ถึงเวลาในสปอตไลท์ที่สามารถวัดได้ในหลายสัปดาห์ (แม้ว่าจะสามารถวัดระยะเวลาในการพัฒนาได้เป็นปี) ตอนนี้สัปดาห์ที่ผ่านมาในสปอตไลท์เป็นสัปดาห์ที่น่าตื่นเต้นมาก --- ดูตัวอย่างการพูดคุยครั้งล่าสุดที่ Stanford ที่ "เพิ่งเริ่มต้น" --- แต่สิ่งที่คุณถามในแง่ของโครงสร้างพื้นฐานที่กว้างขึ้นและการสนับสนุนแพ็คเกจจะใช้เวลานานกว่า เป็นตัวเป็นตนขึ้น

ดังนั้นฉันจะใช้ R และคำนึงถึงทางเลือกที่กำลังพัฒนาอยู่ เมื่อปีที่แล้วผู้คนจำนวนมากต่างก็คลั่งไคล้กับ Clojure ปีนี้จูเลียเป็นรสชาติใหม่ที่กำลังมาแรง เราจะดูว่ามันเกาะติดไหม

Bruce Tate ที่นี่ผู้แต่งเจ็ดภาษาในเจ็ดสัปดาห์ นี่คือความคิดบางอย่าง ฉันกำลังทำงานกับจูเลียสำหรับหนังสือติดตามผล ต่อไปนี้เป็นเพียงความเห็นของฉันหลังจากเล่นไปสองสามสัปดาห์

มีกองกำลังพื้นฐานสองอย่างในการเล่น ครั้งแรกทุกภาษามีอายุขัย R จะถูกแทนที่ในบางวัน เราไม่รู้ว่าเมื่อไหร่ ภาษาใหม่มีช่วงเวลาที่ยากลำบากในการพัฒนา เมื่อภาษาใหม่มีวิวัฒนาการมันมักจะแก้จุดปวดที่ท่วมท้น

สองสิ่งนี้เกี่ยวข้องกัน สำหรับฉันเรากำลังเริ่มเห็นชุดรูปแบบที่ล้อมรอบภาษาอย่างอาร์มันไม่เร็วพอและยากกว่าที่มันจะต้องเป็น ผู้ที่สามารถอาศัยอยู่ในซองจดหมายแสดงผลงานบางอย่างและอยู่ในห้องสมุดที่จัดตั้งไว้ได้ก็เป็นเรื่องปกติ ผู้ที่ไม่ต้องการมากขึ้นและพวกเขาเริ่มมองหามากขึ้น

สิ่งนี้คือสถาปัตยกรรมคอมพิวเตอร์มีการเปลี่ยนแปลงและเพื่อให้ได้ประโยชน์จากพวกเขาภาษาและโครงสร้างของมันจะต้องถูกสร้างขึ้นในลักษณะที่แน่นอน การใช้งานพร้อมกันของจูเลียนั้นน่าสนใจ มันปรับสิ่งที่เหมาะสมสำหรับภาษาเช่น: การแจกแจงที่โปร่งใสและการเคลื่อนไหวของข้อมูลระหว่างกระบวนการอย่างมีประสิทธิภาพ เมื่อฉันใช้ Julia สำหรับงานทั่วไปแผนที่และการแปลงและสิ่งที่คล้ายกันฉันแค่เรียกฟังก์ชั่น ฉันไม่ต้องกังวลเรื่องท่อประปา

สำหรับฉันแล้วความจริงที่ว่า Julia นั้นเร็วกว่าในโพรเซสเซอร์ตัวหนึ่งนั้นน่าสนใจ แต่ก็ไม่ได้สร้างความเสียหายให้อาร์มากนักสิ่งที่น่าสนใจสำหรับฉันก็คือเมื่อโปรเซสเซอร์ขึ้นอยู่กับมัลติคอร์มากขึ้นสำหรับประสิทธิภาพ เพื่อใช้ข้อได้เปรียบที่ดีที่สุดให้เป็นภาษาที่เหมาะสม

คุณสมบัติอื่น ๆ ที่จะช่วยให้เกิดขึ้นได้คือมาโคร ก้าวของภาษาเป็นเพียงรุนแรงในขณะนี้ มาโครให้คุณสร้างบล็อคที่ใหญ่และสะอาดกว่า การดูห้องสมุดน่าสนใจ แต่ไม่ได้บอกภาพรวมทั้งหมด คุณต้องดูการเติบโตของห้องสมุด เส้นทางการเคลื่อนที่ของจูเลียอยู่ที่นี่มากทีเดียว

Clojure น่าสนใจสำหรับบางคนเพราะไม่มีภาษาทางเทคนิคที่ทำในสิ่งที่ R สามารถทำได้ดังนั้นบางคนมองไปที่ภาษาที่ใช้โดยทั่วไปเพื่อเติมเต็มช่องว่างนั้น จริงๆแล้วฉันเป็นแฟนตัวยง แต่ Clojure เป็นวิปริตของสมองที่ค่อนข้างร้ายแรง Clojure จะอยู่ที่นั่นสำหรับโปรแกรมเมอร์ที่จำเป็นต้องทำการคำนวณทางเทคนิค มันจะไม่เหมาะสำหรับวิศวกรและนักวิทยาศาสตร์ มีมากเกินไปที่จะเรียนรู้

ดังนั้นสำหรับฉัน Julia หรืออะไรทำนองนี้จะแทนที่ R อย่างแน่นอนในบางวัน มันเป็นเรื่องของเวลา

ทุกครั้งที่ฉันเห็นภาษาใหม่ฉันถามตัวเองว่าทำไมภาษาที่มีอยู่ไม่สามารถปรับปรุงได้แทน

ข้อดีข้อใหญ่ของไพ ธ อนคือ

• ชุดโมดูลจำนวนมาก (ไม่ใช่แค่สถิติ แต่รวมถึงการพล็อตไลบรารี่เอาต์พุตไปยัง pdf ฯลฯ )
• ภาษาที่สร้างขึ้นที่คุณต้องการในระยะยาว (โครงสร้างเชิงวัตถุที่คุณต้องการในโครงการขนาดใหญ่เช่นนักตกแต่ง, การปิด, ฯลฯ ที่ทำให้การพัฒนาง่ายขึ้น)
• บทเรียนมากมายและชุมชนการสนับสนุนที่มีขนาดใหญ่
• เข้าถึง mapreduce หากคุณมีข้อมูลจำนวนมากที่ต้องดำเนินการและไม่รังเกียจที่จะจ่ายเงินสักสองสามเพนนีเพื่อเรียกใช้บนคลัสเตอร์

เพื่อที่จะแซง R, Julia เป็นต้น Python สามารถใช้งานได้

• การพัฒนาการคอมไพล์แบบทันเวลาสำหรับ Python แบบ จำกัด เพื่อให้คุณมีความเร็วมากขึ้นในเครื่องเดียว (แต่ mapreduce ยังดีกว่าถ้าคุณสามารถทนต่อเวลาแฝง)
• คลังสถิติที่สมบูรณ์ยิ่งขึ้น

จูเลียจะไม่เข้าครอบครอง R ในไม่ช้า ลองเปิด Microsoft R

https://mran.revolutionanalytics.com/open/

นี่เป็นรุ่นปรับปรุงของ R ซึ่งจะใช้แกนประมวลผลทั้งหมดของคอมพิวเตอร์ของคุณโดยอัตโนมัติ มันเป็น R, ภาษาเดียวกัน, แพ็คเกจเดียวกัน เมื่อคุณติดตั้ง RStudio จะใช้ในคอนโซล ความเร็วของ MRO นั้นเร็วกว่า Julia ฉันใช้งานคอมพิวเตอร์จำนวนมากและใช้ Julia มานานกว่าหนึ่งปี ฉันเปลี่ยนเป็น R เมื่อเร็ว ๆ นี้เพราะ R มีการสนับสนุนที่ดีกว่าและ RStudio เป็นเครื่องมือแก้ไขที่ยอดเยี่ยม จูเลียยังอยู่ในช่วงเริ่มต้นและอาจจะไม่ตาม Python หรือ R ในไม่ช้า

ต่อไปนี้อาจไม่เหมาะสมที่จะเป็นคำตอบ แต่มันสำคัญเกินกว่าที่จะถูกฝังไว้เพื่อแสดงความคิดเห็นต่อการตอบสนองของคนอื่น ...

ฉันไม่เคยได้ยินเรื่องที่พูดมากเกี่ยวกับการใช้หน่วยความจำเพียงความเร็ว ความหมายทั้งหมดของ R ที่ถูกส่งผ่านตามตัวอักษรนั้นอาจจะเจ็บปวดและนี่เป็นคำวิจารณ์อย่างหนึ่งของภาษา (ซึ่งเป็นประเด็นแยกต่างหากจากจำนวนแพ็คเกจที่มีอยู่แล้ว) จัดการหน่วยความจำดีเป็นสิ่งสำคัญเช่นจะมีวิธีการจัดการกับการประมวลผลออกจากหลัก (เช่น numpy ของอาร์เรย์หน่วยความจำที่แมปหรือpytablesหรือปฏิวัติ Analytics' รูปแบบ XDF) ในขณะที่คอมไพเลอร์ JIT ของ PyPy อนุญาตให้ใช้มาตรฐาน Python ที่โดดเด่นบางอย่างการใช้หน่วยความจำอาจค่อนข้างสูง ดังนั้นใครบ้างมีประสบการณ์กับ Julia และการใช้หน่วยความจำหรือยัง ดูเหมือนว่ามีการรั่วไหลของหน่วยความจำในรุ่น "alpha" ของ Windows ซึ่งไม่ต้องสงสัยเลยว่าจะได้รับการแก้ไขและฉันยังคงรอการเข้าถึงกล่อง Linux เพื่อเล่นกับภาษาด้วยตัวเอง

ฉันคิดว่ามันไม่น่าเป็นไปได้ที่ Julia จะมาแทนที่ R ด้วยเหตุผลหลายประการที่กล่าวถึงก่อนหน้านี้ Julia เป็น Matlab แทนไม่ใช่ R แทนที่ พวกเขามีเป้าหมายที่แตกต่างกัน แม้ว่าจูเลียจะมีห้องสมุดสถิติที่เต็มไปด้วยเนื้อหนัง แต่ก็ไม่มีใครสอนชั้นอินโทรไปสู่สถิติในนั้น

อย่างไรก็ตามพื้นที่ที่น่าเหลือเชื่อคือภาษาการเขียนโปรแกรมที่ปรับความเร็วได้ซึ่งเจ็บปวดน้อยกว่า C / C ++ หากมันเชื่อมโยงกับ R (ต่อเนื่องในรูปแบบของ Rcpp) อย่างต่อเนื่องมันก็จะเห็นการใช้งานมากมายในการเขียนเซ็กเมนต์โค้ดที่มีความสำคัญต่อความเร็ว ขออภัยไม่มีลิงก์ดังกล่าวอยู่ในขณะนี้:

https://stackoverflow.com/questions/9965747/linking-r-and-julia

ฉันเป็นมือใหม่ของจูเลียและเป็นผู้ที่มีความสามารถ เหตุผลที่ทำให้ฉันค้นพบว่าจูเลียน่าสนใจมากในตอนนี้คือประสิทธิภาพและความเข้ากันได้

เครื่องมือ GPU ฉันต้องการใช้ CUSPARSE สำหรับแอปพลิเคชันทางสถิติ ผลการ CRANบ่งชี้ว่ายังมีอะไรไม่มากนัก จูเลียมีการผูกไว้ซึ่งดูเหมือนว่าจะทำงานได้อย่างราบรื่นจนถึงขณะนี้

using CUSPARSE
N = 1000
M = 1000
hA = sprand(N, M, .01)
hA = hA' * hA
dA = CudaSparseMatrixCSR(hA)
dC = CUSPARSE.csric02(dA, 'O') #incomplete Cholesky decomp
hC = CUSPARSE.to_host(dC)

เครื่องมือ HPC หนึ่งสามารถใช้คลัสเตอร์แบบโต้ตอบกับหลายโหนดการคำนวณ

nnodes = 2
ncores = 12    #ask for all cores on the nodes we control
procs = addprocs(SlurmManager(nnodes*ncores), partition="tesla", nodes=nnodes)
for worker in procs
    println(remotecall_fetch(readall, worker, `hostname`))
end

หลามเข้ากันได้ มีการเข้าถึงระบบนิเวศหลาม เช่นตรงไปตรงมาเพื่อหาวิธีอ่านข้อมูลการถ่ายภาพสมอง:

import PyCall
@pyimport nibabel

fp = "foo_BOLD.nii.gz"
res = nibabel.load(fp)
data = res[:get_data]();

ความเข้ากันได้ C ข้อมูลต่อไปนี้สร้างจำนวนเต็มแบบสุ่มโดยใช้ไลบรารีมาตรฐาน C

ccall( (:rand, "libc"), Int32, ())

ความเร็ว. คิดว่าฉันจะเห็นว่าแพ็คเกจ Distributions.jl นั้นเทียบกับ rnorm ของ R ได้อย่างไร - ซึ่งฉันคิดว่ามันเหมาะสมแล้ว

julia> F = Normal(3,1)
Distributions.Normal(μ=3.0, σ=1.0)

julia> @elapsed rand(F, 1000000)
0.03422067

ใน R:

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 

Julia 1.0 เพิ่งออกมาพร้อมกับ IDE (Juno) ที่ใช้งานได้ดีมาก มันออกมาช้าไปจนถึงงานปาร์ตี้เนื่องจาก Python ครองตำแหน่ง Machine Learning ไว้แล้วในขณะที่ R ยังคงครองการวิเคราะห์ทางสถิติทุกประเภท ดังที่กล่าวไปแล้ว Julia กำลังเพิ่มความโดดเด่นในด้านการเงินและอัลกอริธึมการค้าเนื่องจากต้องใช้เวลาในการพัฒนาและการดำเนินการที่รวดเร็ว ในความคิดของฉันยกเว้นว่ามีภาษาอื่นเข้ามาในภาษาที่ดีกว่าชัดเจนการที่จูเลียขึ้นสู่ความโดดเด่นอาจจะมีลักษณะเช่นนี้:

(1) เริ่มกินอาหารกลางวันของ MATLAB ผู้ใช้ MATLAB ชอบไวยากรณ์ของ MATLAB แต่ไม่ชอบสิ่งอื่นใด ความเชื่องช้า, ใบอนุญาตราคาแพง, วิธีที่ จำกัด อย่างมากในการจัดการกับโครงสร้างข้อมูลที่ซับซ้อนที่ไม่ใช่เมทริกซ์ ฉันจำคำพูดเดียวที่มีคำกล่าวไว้ว่า "ถ้า Julia มาแทนที่ MATLAB มันจะเป็นบริการที่ยิ่งใหญ่สำหรับมนุษยชาติ" ผู้ใช้ MATLAB สามารถสร้างความเชี่ยวชาญใน Julia ได้อย่างรวดเร็วและจะประทับใจกับความง่ายในการเขียนโค้ดคุณภาพที่ทำได้มากกว่า MATLAB ที่สามารถทำได้ (Structs ที่เร็วซึ่งคุณสามารถใส่ในอาร์เรย์ ไม่เพียงแค่นี้นักวิจัยสามารถสร้างกล่องเครื่องมือที่จริงจังในจูเลีย (นักเรียนปริญญาเอกกลุ่มเล็ก ๆ เขียนชุดสมการเชิงอนุพันธ์ระดับโลก) ที่จะเป็นไปไม่ได้กับ MATLAB

(2) เริ่มทำการวิจัยในวิธีการเชิงตัวเลขและการจำลอง MIT กำลังขว้างน้ำหนักของตนไว้ข้างหลัง Julia และชุมชนการวิจัยได้ฟัง MIT การจำลองเชิงตัวเลขและวิธีการเชิงตัวเลขใหม่เป็นปัญหาที่กำหนดไม่ดีที่ไม่มีไลบรารี นี่คือที่จูเลียเป็นภาษาส่อง; ถ้าไม่มีไลบรารี่อยู่มันจะง่ายกว่าในการเขียนโค้ดคุณภาพสูงในจูเลียมากกว่าภาษาอื่น ๆ มันจะเป็นภาษาเชิงตัวเลข / การจำลองที่เขียนขึ้นโดยนักคณิตศาสตร์สำหรับนักคณิตศาสตร์ (เสียงคล้ายกับ R หรือยัง)

(3) ความก้าวหน้าในการเรียนรู้ของเครื่องจักรอีกครั้งเกิดขึ้นที่ทำให้จูเลียมีความทันสมัย นี่เป็นสัญลักษณ์แทนที่ซึ่งอาจไม่เกิดขึ้น TensorFlow นั้นยอดเยี่ยม แต่มันยากมากที่จะแฮก Python เริ่มแสดงรอยร้าวและ TensorFlow เริ่มใช้ Swift (โดย Julia ได้รับการกล่าวถึงอย่างมีเกียรติ) หากการเรียนรู้ด้วยเครื่องจักรอื่นเกิดขึ้นมันจะง่ายกว่ามากในการนำไปใช้และแฮ็กในแพ็คเกจ Julia เช่น Flux.jl

(4) จูเลียเริ่มช้าถึง R ซึ่งจะใช้เวลาสักครู่ การทำสถิติใน MATLAB นั้นเจ็บปวด แต่ Juila ก้าวไปข้างหน้าของ MATLAB ด้วย Distributions.jl ความจริงก็คือเวิร์กโฟลว์ R สามารถแปลเป็น Julia ได้อย่างง่ายดาย ข้อได้เปรียบที่แท้จริงเพียงอย่างเดียว R คือความจริงที่ว่ามีแพ็คเกจจำนวนมากถูกเขียนขึ้นโดยนักสถิติสำหรับนักสถิติ อย่างไรก็ตามกระบวนการนี้ยังทำได้ง่ายในจูเลีย ข้อแตกต่างคือจูเลียนั้นรวดเร็วและคุณไม่จำเป็นต้องใช้ภาษาอื่นในการแสดง (แพ็คเกจ R ที่ "จริงจัง" นั้นเขียนด้วยภาษาเช่น C) ปัญหาเกี่ยวกับ R คือแพ็กเกจที่เขียนด้วย R ช้าเกินไปที่จะจัดการกับชุดข้อมูลขนาดใหญ่ ทางเลือกเดียวคือการแปลแพ็กเกจเป็นการพัฒนาภาษาอื่นใน R ช้ากว่าจูเลีย

ฉันสนใจด้วยคำมั่นสัญญาของความเร็วที่ดีขึ้นและการขนานที่ง่ายขึ้นโดยใช้สถาปัตยกรรมที่แตกต่างกัน ด้วยเหตุนี้ฉันจะเฝ้าดูการพัฒนาของ Julia อย่างแน่นอน แต่ฉันไม่น่าจะใช้มันจนกว่ามันจะสามารถจัดการกับโมเดลเชิงเส้นผสมทั่วไปได้แพคเกจ bootstrap ทั่วไปที่ดีภาษาจำลองง่าย ๆ สำหรับการออกแบบอาคารฝึกอบรมความสามารถเทียบเท่า ggplot2 และหลากหลาย จากอัลกอริทึมการเรียนรู้ของเครื่อง

นักสถิติไม่สามารถที่จะมีทัศนคติแบบยึดถือหลักนิยมในการเลือกเครื่องมือ เราจะใช้สิ่งที่ทำให้เราสามารถทำงานได้อย่างมีประสิทธิภาพมากที่สุด ฉันเดาว่าฉันจะติดกับ R ไม่กี่ปีที่ผ่านมา แต่ แต่มันจะดีที่จะประหลาดใจ

ความหรูหราของ NA's ใน R ไม่ได้เกิดขึ้นหากไม่มีการลงโทษ ถ้า Julia สนับสนุน NA's ด้วยค่าปรับประสิทธิภาพที่น้อยลงมันน่าสนใจสำหรับเซ็กเมนต์ของชุมชนสถิติ แต่ NA ก็กำหนดให้มีการทำงานเพิ่มขึ้นอย่างมากเมื่อใช้รหัสที่คอมไพล์ด้วย R

แพ็กเกจจำนวนมากใน R ขึ้นอยู่กับรูทีนที่เขียนด้วยภาษาดั้งเดิม (C, Fortran หรือ C ++) ในบางกรณีรูทีนที่คอมไพล์ได้รับการพัฒนาภายนอก R และใช้เป็นพื้นฐานสำหรับแพ็กเกจไลบรารี R ในคนอื่น ๆ มีการใช้งานประจำเป็นครั้งแรกใน R จากนั้นส่วนที่สำคัญจะถูกแปลเป็นภาษาที่คอมไพล์เมื่อพบว่าประสิทธิภาพลดลง Julia จะน่าสนใจหากสามารถนำไปใช้ในการทำกิจวัตรที่เท่าเทียมกันได้มีโอกาสออกแบบการสนับสนุนระดับต่ำสำหรับ NA ในวิธีที่ทำให้การจัดการ NA ง่ายกว่าสิ่งที่เรามีตอนนี้เมื่อใช้ R กับโค้ดที่คอมไพล์

ไลบรารี R จำนวนมากแสดงถึงความพยายามของผู้ใช้หลายคน สิ่งนี้เป็นไปได้เพราะ R ให้ความสามารถที่ไม่สามารถใช้งานได้ / ราคาเหมาะสม หาก Julia ใช้กันอย่างแพร่หลายก็ต้องมีกลุ่มผู้ใช้ที่พบว่าทำสิ่งที่พวกเขาต้องการได้ดีกว่าทางเลือกอื่น ๆ ที่คุ้มค่ากับความพยายามที่จำเป็นในการจัดหาสิ่งพื้นฐานมาก ๆ (เช่นกราฟิกชั้นเรียนวันที่เป็นต้น) ) มีให้จากภาษาที่มีอยู่

ฉันจะอยู่ข้างหน้าฉันไม่มีประสบการณ์กับ R แต่ฉันทำงานกับผู้คนมากมายที่คิดว่ามันเป็นเครื่องมือที่ยอดเยี่ยมสำหรับการวิเคราะห์ทางสถิติ พื้นหลังของฉันอยู่ในคลังข้อมูลและเนื่องจาก Julia's กระจายได้ง่าย แต่รูปแบบการเขียนโปรแกรมมาตรฐานมากขึ้นฉันคิดว่ามันอาจเป็นสิ่งที่น่าสนใจมากสำหรับการเปลี่ยนส่วนของเครื่องมือ ETL แบบดั้งเดิมที่โดยทั่วไปทำงานได้ไม่ดีนักส่วนใหญ่ไม่มีทาง สร้างการแปลงมาตรฐานได้อย่างง่ายดายหรือใช้ผลลัพธ์ของการแปลงที่ดำเนินการแล้วในชุดข้อมูลก่อนหน้า การสนับสนุนสำหรับ tuples ที่กำหนดและพิมพ์อย่างชัดเจนนั้นชัดเจนถ้าฉันต้องการสร้าง OLAP cube ที่จำเป็นต้องสร้าง tuples ที่มีรายละเอียดมากขึ้น (ตารางข้อเท็จจริง) จาก tuples ที่คำนวณไว้แล้วเครื่องมือ ETL ในปัจจุบันไม่มี 'building block' ที่จะพูดถึงสิ่งนั้น สามารถช่วย, อุตสาหกรรมนี้ได้แก้ไขปัญหานี้ด้วยวิธีการต่าง ๆ ในอดีต แต่มีการแลกเปลี่ยน ภาษาการเขียนโปรแกรมแบบดั้งเดิมสามารถช่วยได้ด้วยการนำเสนอการเปลี่ยนแปลงที่กำหนดจากส่วนกลางและ Julia อาจลดความซับซ้อนของการรวมและการกระจายที่ไม่ได้มาตรฐานในระบบคลังข้อมูลที่ซับซ้อนมากขึ้น

คุณสามารถใช้ Julia และ R ด้วยกันได้ มีอินเตอร์เฟซจูเลียไป-R ด้วยแพ็คเกจนี้คุณสามารถเล่นกับ Julia ได้ในขณะที่เรียก R เมื่อใดก็ตามที่มีไลบรารี่ที่จำเป็น

จูเลียไม่ต้องสงสัยเลยว่าทุกครั้งที่มีโอกาสกลายเป็นสถิติผู้ใช้ที่ใฝ่ฝันจะเป็นจริงพา SAS ตัวอย่างเช่นมันมีพลังอยู่ใน procs จำนวนมากที่เขียนใน C - สิ่งที่จูเลียสามารถทำได้คือให้ procs กับซอร์สโค้ด การแจกจ่ายชนิดข้อมูลในตัวด้วย SAS / iml ฉันไม่สงสัยเลยว่านักสถิติจะแห่กันไปที่จูเลียเมื่อพวกเขาได้รับการจัดการกับสิ่งที่ลูกสุนัขตัวนี้สามารถทำได้

โอ้ใช่แล้วจูเลียจะแซงอาร์ได้อย่างรวดเร็ว และเหตุผลหลักจะเป็น "มาโคร" 95% ของภาษาถูกนำไปใช้ในจูเลียและไม่มีเสียงรบกวน หากคุณยังไม่มีประสบการณ์เกี่ยวกับภาษาแบบ lisp คุณอาจยังไม่เข้าใจ แต่คุณจะเห็นได้อย่างรวดเร็วว่าอินเตอร์เฟสสูตร R จะกลายเป็นกลไกที่ล้าสมัยและน่าเกลียดและจะถูกแทนที่ด้วยภาษาจำลองขนาดเล็กคล้ายกับ CL มาโครวนรอบ การเข้าถึงการอ้างอิงระดับต่ำของวัตถุก็เป็นข้อดีเช่นกัน ฉันคิดว่า R ยังไม่ได้รับการซ่อน internals จากผู้ใช้จริงซับซ้อนกว่าทำให้สิ่งต่าง ๆ ง่ายขึ้น

อย่างที่ฉันเห็นตอนนี้ (มีการใช้ R เป็นจำนวนมากเป็นเวลาหลายปีและเพิ่งอ่านคู่มือจูเลียเสร็จสิ้น) ข้อเสียเปรียบหลักของจูเลียที่เกี่ยวกับ R นั้นไม่ได้รับการสนับสนุนสำหรับการสืบทอดทางโครงสร้าง ระบบประเภทของ Julia มีความทะเยอทะยานน้อยกว่า S4; มันยังรองรับการแจกจ่ายหลายครั้งและการสืบทอดหลายรายการ แต่ด้วยการจับ - มีคลาสคอนกรีตเพียงระดับเดียวเท่านั้น ในทางกลับกันฉันไม่ค่อยเห็นลำดับชั้นของชั้นเรียนใน R ที่ลึกกว่า 3 ระดับ

เวลาจะบอก แต่จะเร็วกว่าที่ผู้ใช้ R ส่วนใหญ่คิด :)

กรณีการใช้เป้าหมายแรกของ Julia นั้นเป็นปัญหาเชิงตัวเลข โดยพื้นฐานแล้วคุณสามารถแบ่งการวิเคราะห์และวิทยาศาสตร์การคำนวณเหล่านี้เป็นศาสตร์ข้อมูล (ขับเคลื่อนด้วยข้อมูล) และวิทยาศาสตร์จำลอง (ขับเคลื่อนด้วยแบบจำลอง) Julia กำลังจัดการกับกรณีการใช้วิทยาศาสตร์จำลองก่อน พวกเขายังจัดการกับกรณีศาสตร์ข้อมูล แต่ช้ากว่า R จะไม่มีประโยชน์อย่างมากสำหรับวิทยาศาสตร์การจำลอง แต่จูเลียจะมีประโยชน์มากสำหรับทั้งสองในสองสามปี

จะต้องสามารถใช้ฟังก์ชันใด ๆ กับชุดข้อมูลขนาดใหญ่ที่ไม่พอดีกับหน่วยความจำที่โปร่งใสสำหรับผู้ใช้
นั่นรวมถึงการใช้งานเอ็ฟเฟ็กต์แบบผสมอย่างน้อยรุ่นเอาชีวิตรอดหรือ MCMC ในชุดข้อมูลที่พอดีกับดิสก์ แต่ไม่ได้อยู่ในหน่วยความจำ และถ้าเป็นไปได้ในชุดข้อมูลที่กระจายในคอมพิวเตอร์หลายเครื่อง