Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537 Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537
最近在學習Web頁面3D效果方面的東西,感覺十分有趣。在Web方面實現3D現在手段十分豐富,可以純javascript,也可以HTML5+CSS3,另外還有其他一些手段。對于Access實現3D相對來說手段就要少很多,不過少并不意味著不能。于是乎便寫了這個示例,來說明Access實現3D的一些基本的方法。
為了簡化問題,便也就用了最為簡單的3D矩陣來作為問題的原型。在這個示例中我們來實現一個1×4×5的靜態圖片矩陣。由于Access比較難以實現圖片的透明度設置,所以你將只能看到一個近大遠小的效果,而看不出透明度的變化。即便如此,還是能感覺出3D來。
如果你有興趣,還可以進一步修改這個示例,將其變化為l×m×n的圖片矩陣,也可再進一步加入矩陣隨鏡頭移動的變化效果來。不過我要告訴你,這些改進會比較復雜,而且演示的效果并不一定好。
演 示:
示例下載:
【Access小品】3D圖片矩陣【Access軟件網】
文首發于計算化學公社,RTX4090 配置方案與軟件搭配(DeePMD,Gromacs等)詳情咨詢 “庚子計算” 客服。
這次測試最初的目的是證明用何種性能級別的CPU可在運行GPU加速GROMACS(簡稱GMX)時榨干最新頂級消費級GPU——NVIDIA GeForce RTX 4090,對RTX 4090進行迄今全網最具系統性的分子動力學(MD)模擬性能測試。由于中文互聯網上與GPU加速MD相關的benchmark文章較少,本文的討論將不會局限于RTX 4090本身,會做一些擴展討論。
NVIDIA官方對相關軟件已經進行了一些測試,但其測試只針對極度昂貴的數據中心GPU產品,以展示多GPU并行性能和其GPU節點對CPU節點的替代能力為主要目的;且筆者發現,其在使用不同軟件運行STMV模型的測試中所用具體參數大相徑庭,無法實現不同程序間的公平對比。因此,筆者特意在本次測試中使用了一些公平的模型和參數。此外,本次測試僅考慮單GPU運行的使用場景,因為這是實際使用中的大多數狀態,且RTX 4090不具備NVLink,使用多GPU并行意義不大。
硬件平臺(由于51972暫時不能提供RTX 3090Ti,故用ROG STRIX RTX 3090額外超頻150MHz并將功耗上限設為480W以模擬RTX 3090Ti):軟件環境:Ubuntu 22.04.1 LTS Desktop; Linux version 5.15.0-52-generic; GNU 11.2; CUDA Tookit 11.8; NVIDIA GPU Driver 520.56.06
本次測試涉及GMX、AMBER、NAMD3、LAMMPS共4款MD軟件,基準數據集和測試腳本在SI中(tar.bz2)。GMX、AMBER、NAMD3所用各模型主要參數如下表:
其中,A和A-2為表面活性劑在油-水界面的slab模型;B為體相的表面活性劑膠束模型;B-TI為模擬單個表面活性劑(134原子)從膠束中解耦過程的ΔG的熱力學積分(TI)模擬的某個λ窗口模擬;4個STMV開頭的模型均為STMV(煙草花葉病毒衛星病毒,經典的benchmark專用模型,近20年來被廣泛用于HPC性能測試)在水環境中的模型,后3個是相應程序此前已公開報道的測試所用的模型與參數;benchPEP-h為若干小肽鏈在水環境中的模型。A、A-2、B、B-TI均選自筆者此前研究工作,與5月發布的HPC benchmark報告所用模型完全相同。
值得一提的是,STMV-AMBER測試中額外使用了AMBER官方benchmark文件包中的優化版參數進行測試,即所謂“Boost”設置,具體機制是通過手動指定合適的“skin_permit”參數以減少pair list的頻繁更新引起的性能下降,根據AMBER開發組的說法,將此參數設為0.75可在多數體系中獲得8-12%的性能提升,并兼顧模擬的“安全性”,但此功能未在公平版mod中啟用。
10月11日筆者在BB空間發布“預告”后,有網友要求增加LAMMPS測試,但實際上筆者一開始特意將LAMMPS排除在測試列表外,因為其主攻固體材料模擬,力場基本與另3款軟件不兼容,故無法與另3款軟件橫向對比;此外,其GPU加速功能對GPU的雙精度浮點性能需求高,較不適合用來測試雙精度浮點性能孱弱的游戲GPU。不過既然網友已明確提出需求,又考慮到RTX 4090的雙精度浮點性能已超過1 TFLOPS,有一定測試價值,遂將LAMMPS加入測試列表。LAMMPS測試所用文件即為NVIDIA網站上公布的測試所用的文件,3個任務分別為LJ 2.5、EAM、Tersoff。經過測試,目前使用RTX 4090運行ReaxFF/C任務有bug,故放棄ReaxFF/C。也有網友提出希望測試VASP,但此軟件是純商業軟件,筆者個人未購買使用許可,故無法進行測試,Material Studio同理(建議自發抵制VASP、MS這類溢價軟件,尤其是MS)。本次測試所用的4款經典MD軟件是當前最主流的,參考2021年計算化學公社論壇“你最常用的計算化學程序和DFT泛函”投票結果統計。
GROMACS 2022.3根據筆者博客上公布的流程編譯CUDA版本;AMBER22根據筆者博客上公布的流程編譯串行+CUDA版本,因為不測試多GPU并行,所以不編譯MPI版本,也不啟用NCCL;NAMD3直接使用官網提供的Alpha13預編譯版本(NAMD_3.0alpha13_Linux-x86_64-multicore-CUDA-SingleNode.tar.gz,NVIDIA最新的測試也使用了此版本);LAMMPS版本為23Jun2022_update1,使用cmake預設文件“basic.cmake”和“kokkos-cuda.cmake”進行編譯(“kokkos-cuda.cmake”中“Kokkos_ARCH_PASCAL60”改為“Kokkos_ARCH_AMPERE86”,未選擇針對Ada Lovelace架構優化是因為目前沒有相關選項),同時額外指定編譯REAXFF包(-D PKG_REAXFF=on)。
GMX的開發遵循硬件資源利用率最大化的原則,因此近些年來其GPU加速一直采用CPU+GPU的方案,運行MD模擬時需要CPU參與部分計算工作,CPU-GPU的任務分配在一定程度上可人工調節,以獲得最優效率。在最新的版本中,GMX最多可將非鍵相互作用、成鍵相互作用、PME、坐標/速度/力更新和約束計算完全offload到GPU上運行(GPU-resident模式,須在mdrun命令中添加“-bonded gpu -update gpu”),但域分解(domain decomposition)、對搜索(pair search)、一些特殊力的計算以及特殊算法仍必須使用CPU執行。值得一提的是,只有當CPU資源嚴重匱乏時,采用GPU-resident模式才能快于使用CPU計算成鍵相互作用(J. Chem. Phys. 2020, 153, 134110 Fig. 10),而“CPU資源嚴重匱乏”對于不同模型并無確定的分界點,因此本次測試將分別記錄以這兩種方式運行GMX的性能數據。
近些年來,GPU性能增速飛快,CPU的性能開始表現出不足,例如2020年9月發布的NVIDIA GeForce RTX 3090,若用來運行GPU加速GMX,須配合同期的高端CPU——AMD Ryzen R9 5900X才能發揮出大部分性能。而RTX 4090的理論性能相較于RTX 3090翻倍有余,CPU性能的瓶頸將更為明顯,因此,非常有必要研究如何讓RTX 4090在GROMACS任務中發揮最大性能。
AMBER、NAMD3、LAMMPS這3款MD軟件的GPU加速模塊均采用了“純GPU”方案,這與GMX不同。采用這種方案的程序在運行時僅會占用1個CPU線程,幾乎所有計算都在GPU上完成。但CPU單核性能對這類MD任務運行速度的影響依然值得考慮。
本次測試使用了4款典型的CPU,其中,AMD Ryzen R9 7950X和intel Core i9 13900K都是最新的頂級MSDT平臺CPU,特點是單核性能都非常強,多核性能也不弱;AMD EPYC 7R32適合計算密集型應用,具有48顆Zen2核心;intel XEON Platinum 8369B是近期intel陣營的高性價比服務器CPU,具有32顆Sunny Cove核心,在GMX測試中最多同時使用了2顆此CPU(64核)。
測試使用shell腳本自動運行,詳見SI。在GMX測試中,STMV-NPT、STMV-GMX和benchPEP-h的性能數據并非直接取自mdrun運行日志,而是扣除Write traj.項的Wall time后重新計算。因為這3個模型模擬過程中不寫軌跡,但GPU計算完成后會花較長時間寫gro文件,而mdrun運行日志給出的性能數據包含了這一耗時。在運行時間較長的生產模擬中這一耗時可忽略不計,而在benchmark任務中理應扣除這一耗時。
圖1展示了GMX運行各模型MD模擬的速度與所使用的CPU核數之間的關系。A和A-2模型中有大量成鍵項數量與原子數比值很大的分子(即烷烴和表面活性劑,其原子數占總原子數的60%),因此成鍵相互作用使用CPU計算與使用GPU計算的性能差異很明顯,在圖中直觀地表現為兩條曲線的交叉角度很大。其中A-2模型的cutoff更小,非鍵相互作用計算量更少,進一步突出了上述差異。在1250萬原子的benchPEP-h模型的測試中,通過檢查nvidia-smi dmon性能監控日志可發現,如果使用CPU計算成鍵相互作用,RTX 4090運行此模型時會出現間歇性的低時鐘占用率、低功耗狀態,且PCIe實時數據傳輸速率一直維持在近10GB/s,峰值可達20GB/s;而若采用GPU-resident模式,可以觀察到GPU間歇性“熄火”的狀況有一定改善,且PCIe數據傳輸量也有所減少;圖1也顯示對于該模型采用GPU-resident模式的模擬速度完全快于使用CPU計算成鍵相互作用??傊瑢τ诖蠖鄶刁w系,只要CPU資源不是極度匱乏,都建議把成鍵相互作用放在CPU上計算(在mdrun命令中添加“-update gpu”,不添加“-bonded gpu”);而對于主觀估計為CPU資源極度匱乏(例如使用服務器CPU搭配多塊高性能GPU),或體系中成鍵項數量與原子數比值很大且使用了較小cutoff,或體系極度龐大(近千萬原子級別)的情況,應當嘗試采用GPU-resident模式,觀察其速度是否更快。
7R32作為4款CPU中多核理論性能最強者,運行GPU加速GMX卻最慢,其原因是GPU加速GMX時CPU部分的計算是純OpenMP并行,這種并行模式在高并行度下并行效率低,且對CPU核心間通信延遲很敏感,而7R32的理論單核性能較差,其多核理論性能靠核心數量支撐,且CPU本身采用小芯片設計,48個CPU核心分布在6個CCD上,跨CCD延遲較高。
8369B雖然理論單核性能沒有比7R32高很多,但它是單Die設計,核心間通信延遲很低,所以運行GPU加速GMX時其表現明顯優于7R32(部分項目略低于之是因為受到客觀條件限制,8369B使用了機架式平臺,散熱較差,RTX 4090高負載下的Boost頻率比7R32所用的塔式平臺低50MHz)。
7950X的表現比8369B更好,主要原因是其單核理論性能極強,達到了7R32、8369B的2倍以上,然而,7950X仍稍弱于13900K。
13900K采用了混合架構,P-Core與E-Core的性能差異極大,線程綁定的OpenMP并行在這種CPU上會使線程間有明顯的負載不均衡問題,最終導致無法發揮出CPU的完整性能。從圖1中也可發現,8-9核處普遍有一斷層,但是,從第12核左右開始,混用P-Core與E-Core的速度就會反超使用8個P-Core的速度,intel Raptor Lake相較于前代Alder Lake增加E-Core數量、增大E-Core緩存、優化P-Core與E-Core間延遲是有明顯益處的。13900K也是4款CPU中表現最好者。此外,從圖中還可看出,24核稍慢于23核,因此,在使用13900K時,建議留一個E-Core供系統進程和GPU驅動使用,這也是GMX手冊所建議的。
值得注意的是,13900K中16個E-Core的性能在本測試中僅相當于5-6個P-Core,且13900K本身還有混合架構導致的線程負載不均衡問題,但其配合RTX 4090運行GPU加速GMX的性能卻比7950X稍強,出現這一現象的原因除了13900K P-Core的理論單核性能稍強于7950X外,也包括其核心間通信延遲總體上比7950X更低。7950X跨CCD的延遲過高,嚴重限制了其性能發揮。實際上從圖1中也能看出,部分7950X的曲線在8-10核處有一凹陷,且8核之后曲線斜率明顯變小。@ECSM_Official在這2款CPU的首發評測中就已測試了它們的核心間延遲:Raptor Lake S,再進一步,Intel Core i9 13900K評測;它很接近完美了,AMD R9 7950X全面評測。
綜上,在GPU加速GMX這一應用場景中對CPU的需求有以下特征:首先,需要單核性能與多核性能都強的CPU,相同理論多核性能下,單核越強、核數越少越好;其次,核心間通信延遲對CPU性能發揮有很大負面影響。
圖2展示了4款CPU配合RTX 4090運行GMX、AMBER、NAMD3和LAMMPS的性能,0%基準線是7950X。前2幅小圖是圖1的另一種表現形式,從中可以發現,對于GMX,CPU多核性能對不以GPU-resident模式運行MD任務的速度有很大影響,但對GPU-resident模式影響較小。從后4幅小圖中可以發現,CPU單核性能對4款MD軟件運行MD任務的速度均有影響,其中對GMX和AMBER的影響很明顯,而對NAMD3和LAMMPS的影響相對小一些。
再談談采購建議。若使用RTX 4090加速GMX,當下最佳搭檔CPU是intel Core i9 13900KF,如果采購時發現AMD Ryzen R9 7950X及其主板的價格遠低于前者,也可買之。如果預算較低,打算選4080 16GB、3090Ti級別的GPU,推薦13700KF,不推薦7900X。暫不推薦任何服務器CPU,尤其是AMD EPYC CPU,若已有這類CPU,可在此基礎上添加多塊RTX 4090,為每塊RTX 4090保留8-16核,以GPU-resident模式運行MD模擬。采購用于搭配RTX 4090運行AMBER、NAMD3或LAMMPS的CPU時,單核性能同樣是首要關注因素,但不必選13900K,用13600KF配2塊RTX 4090即可。
RTX 4090的理論性能是RTX 3090Ti的2倍,這一次的性能提升可能是十多年來NVIDIA消費級GPU性能提升最大的一次,非常有必要測試并對比兩者用于GPU加速經典MD模擬時的實際性能。此外,實際做研究時,在系統穩定的前提下計算速度越快越好,能效并不重要,超頻是可行的操作,筆者自己跑生產模擬時也會對硬件進行一些保守的超頻,所以有必要測試保守超頻的收益。
圖3展示了RTX 4090和超頻150MHz且功耗上限提升至600W的RTX 4090相較于RTX 3090Ti在各MD任務下的性能提升百分比,數據在3號和4號硬件平臺(13900K平臺)上測得。從圖中可以發現,RTX 4090運行經典MD模擬的性能并沒有實現普遍的“翻倍”,在不同模型、不同軟件下的表現各不相同,超頻收益普遍較明顯。
對于GMX,當成鍵相互作用在CPU上計算時,不同模型的表現差異非常大,其中A-2模型極低的提升幅度顯然是由于CPU性能有嚴重瓶頸,benchPEP-h模型提升幅度較低是因為CPU-GPU通信有明顯瓶頸,這些都已在第3節有所討論。從圖1中可以知道,上述2個模型以GPU-resident模式運行速度明顯更快,在實際生產模擬中必然會以GPU-resident模式運行,故可忽略圖3第1幅小圖中的這2個模型。當GMX以GPU-resident模式運行時,不同模型的表現差異顯著縮小。對于GMX和AMBER來說,幾個STMV模型基本實現了“翻倍”,其中AMBER的STMV-NPT模型提升幅度高達108.65%。作為“純GPU”程序,AMBER和NAMD3下各個模型的提升幅度均達到了70%以上;AMBER的上限更高,且超頻收益與超頻幅度相符;而NAMD3下沒有任何模型實現“翻倍”,超頻的收益也不大。對于LAMMPS,LJ 2.5和EAM兩個任務中RTX 4090性能實現“翻倍”,Tersoff任務離“翻倍”還有較大距離。而對比NVIDIA公布的測試結果,RTX 4090運行LAMMPS的性能(具體數據見SI)仍明顯不如A100,甚至不如V100,這顯然是因為RTX 4090無FP64執行單元,雙精度浮點性能太弱??傊陨辖Y果體現了模型大小以及MD程序本身的設計對RTX 4090性能發揮的重要影響,實際上,模型大小的影響在一定程度上是軟件優化的問題。
此外,通過檢查nvidia-smi dmon性能監控日志還可發現,在測試運行過程中,全程顯存占用率不超過60%,對GMX而言甚至不超過40%,所以顯存不存在瓶頸,這否定了此前一些人關于“顯存瓶頸”的猜想。需注意,顯存占用率和顯存使用量不同,前者是指在采樣周期內GPU讀寫顯存的時間百分比。
結合本節和第3節內容可得出結論:當前,制約RTX 4090的性能在GMX、AMBER、NAMD3和LAMMPS中發揮的主要瓶頸是CPU單核性能以及軟件優化,對于GMX,CPU多核性能、CPU核間通信延遲以及CPU-GPU通信能力是次要瓶頸;當前,RTX 4090運行經典MD模擬的性能相較于RTX 3090Ti總體上有62~109%的提升,在使用合適的軟件和模型的情況下,確實可實現“翻倍”,超頻150MHz后實際提升幅度為1~6%。如今Ada Lovelace架構剛剛上市,并無針對性優化,預計在將來幾個月,隨著幾款MD軟件以及編譯器和驅動層面對于Ada Lovelace架構的優化,RTX 4090運行MD模擬的性能還會有進一步提升。
去年12月有朋友對NVIDIA官網測試結果做了詳細分析( http://bbs.keinsci.com/thread-27072-1-1.html ,4樓),討論的是STMV模型,但NVIDIA官方在使用不同軟件運行STMV模型時所用的具體參數區別很大,無法實現不同程序間的公平對比,因此,筆者重新使用一些公平的參數對GMX、AMBER和NAMD3這3款主流MD軟件的速度進行對比。
圖4選取了在3號和4號硬件平臺(13900K平臺)上測得的數據,以在單CPU線程、GPU-resident模式下運行GMX的速度為100%基準;“max perf.”指的是圖1中相應曲線最高點的數值,即充分利用13900K CPU資源后能達到的最高性能。從圖4中可發現,雖然GMX的GPU-resident模式未徹底將MD計算轉移到GPU,但其只用1個CPU線程來與AMBER公平對比時并無明顯弱勢,而GMX充分利用CPU資源后,性能還有巨幅提升,最終遠超AMBER;此外,NAMD3的性能明顯弱于GMX和AMBER。綜上,當前還是最推薦廣大研究者使用GMX和AMBER做經典MD模擬,這2款軟件性能都不錯(根據NVIDIA的測試,后者多GPU并行效率極高),且在功能方面可以互補,足以勝任絕大部分研究工作。
SI
致謝
本次測試所用的硬件由bilibili UP主@51972和庚子計算(濟南庚子矩陣云科技有限公司)遠程贊助,同時感謝他們專業且高效的協作,使本次測試得以順利完成。
數學中,矩陣(Matrix)是一個按照長方陣列排列的實數集合 ,最早來自于方程組的系數及常數所構成的方陣。矩陣是高等代數學中的常見工具,也常見于統計分析等應用數學學科中。 矩陣的運算是數值分析領域的重要問題。將矩陣分解為簡單矩陣的組合可以在理論和實際應用上簡化矩陣的運算。
矩陣在統計學中的用途廣泛且多樣,主要用于表示和操作數據、簡化計算過程以及解決各種統計問題。通過矩陣運算可以簡化和加速統計數據分析、建模和計算過程。無論是基本的線性代數操作,還是高級的統計分析方法,矩陣都為我們提供了強大而靈活的工具。
1、矩陣基礎函數
(1)生成空矩陣
【語法】
// 函數
webTJ.Matrix.getMEmpty(rows, col);
// 參數
【arrs:二維數組】
【代碼】
webTJ.clear();
var oArrs=webTJ.Matrix.getMEmpty(4,5);
oArrs[3][3]=100;
oArrs[0][0]=200;
oArrs[2][1]=300;
webTJ.display(oArrs,1)
(2)矩陣加
【語法】
// 函數
webTJ.Matrix.getPlus(arrs1, arrs2);
// 參數
【arrs1, arrs2】
【二維數組1 二維數組2】
【代碼】
webTJ.clear();
var oTxt1="3:2:6:5:2:7,5:3:6:5:9:6,5:2:1:5:2:6,1:2:6:5:2:0"; //格式字符串
var oTxt2="2:1:2:3:2:2,5:3:5:5:2:6,5:2:1:3:2:2,3:2:2:5:1:1"; //行分割符","、列分割符":"
var oArr1=webTJ.getArrs(oTxt1,",",":"); //按行、列分割符轉換為二維矩陣
var oArr2=webTJ.getArrs(oTxt2,",",":");
webTJ.display(oArr1,1);
webTJ.display(oArr2,1);
var oArr=webTJ.Matrix.getPlus(oArr1,oArr2); //兩矩陣相加
webTJ.display(oArr,1);
注:矩陣(二維數組)加或減時,arrs1和arrs2的行和列相等
(3)矩陣減
【語法】
## 函數 ##
webTJ.Matrix.getMinus(arrs1, arrs2);
## 參數 ##
【arrs1, arrs2】
【二維數組1, 二維數組1】
【代碼】
webTJ.clear();
var oTxt1="3:2:6:5:2:7,5:3:6:5:9:6,5:2:1:5:2:6,1:2:6:5:2:0";
var oTxt2="2:1:2:3:2:2,5:3:5:5:2:6,5:2:1:3:2:2,3:2:2:5:1:1";
var oArr1=webTJ.getArrs(oTxt1,",",":");
var oArr2=webTJ.getArrs(oTxt2,",",":");
webTJ.display(oArr1,1);
webTJ.display(oArr2,1);
var oArr=webTJ.Matrix.getMinus(oArr1,oArr2);
webTJ.display(oArr,1);
(4)矩陣乘
【語法】
// 函數
webTJ.Matrix.getMultiply(arrs1, arrs2);
// 參數
【arrs1, arrs2】
【二維數組1, 二維數組2】
【代碼】
webTJ.clear();
var oTxt1="3:2:6:5:2:7,5:3:6:5:9:6,5:2:1:5:2:6,1:2:6:5:2:0";
var oTxt2="2:1:2:3,5:5:2:6,5:2:2:2,3:2:2:5,3:4:2:1,5:2:6:4";
var oArr1=webTJ.getArrs(oTxt1,",",":");
var oArr2=webTJ.getArrs(oTxt2,",",":");
webTJ.display(oArr1,1);
webTJ.display(oArr2,1);
var oArr=webTJ.Matrix.getMultiply(oArr1,oArr2);
webTJ.display(oArr,1);
注:兩矩陣相乘,arrs1的列和arrs2的行相等(Ai×j × Bj×k = Ci×k)
(5)矩陣轉置
【語法】
// 函數
webTJ.Matrix.getTranspose(arrs);
// 參數
【arrs】
【二維數組】
【代碼】
webTJ.clear();
var oArr=[
[3,2,6,5,2,7], [5,3,6,5,9,6],
[5,2,1,5,2,6], [1,2,6,5,2,0]];
webTJ.display(oArr,1);
var oArr1=webTJ.Matrix.getTranspose(oArr);
webTJ.display(oArr1,1);
(6)計算逆矩陣
【語法】
// 函數
webTJ.Matrix.getInverse(arrs);
// 參數
【arrs】
【二維數組】
【代碼】
webTJ.clear();
var oArrs=[[2,2,3],[2,1,2],[1,3,4]];
webTJ.display(oArrs,1);
var oArrs1=webTJ.Matrix.getInverse(oArrs);
webTJ.display(oArrs1,1);
注:矩陣(二維數組)arrs為方陣
(7)計算矩陣的行列式
【語法】
// 函數
webTJ.Matrix.getDet(arrs);
// 參數
【arrs】
【二維數組】
【代碼】
webTJ.clear();
var oArrs = [
[6,8,4,2,8,5], [3,5,2,4,9,2], [7,6,8,3,4,5],
[5,5,2,8,1,6], [3,2,2,4,2,2], [8,3,2,2,4,1]];
var oV=webTJ.Matrix.getDet(oArrs);
webTJ.display(oV,0);
注:矩陣(二維數組)arrs為方陣
2、矩陣編輯(修改)
(1)在指定位置添加行
【語法】
// 函數
webTJ.Matrix.getInsertRRow(arrs, rarr, row);
// 參數
【arrs, rarr, row】
【二維數組, 行數組, 添加行位置】
【代碼】
webTJ.clear();
var oArrs=[[3,2,5,1],[2,5,4,3],[3,1,2,4],[2,1,1,5],[4,1,3,1]];
webTJ.display(oArrs,1);
var oRowv=[3,4,1,7]; //添加數組
var oTs=webTJ.Matrix.getInsertRRow(oArrs,oRowv,1); //在第2行插入添加行
(2)在指定位置添加列
【語法】
// 函數
webTJ.Matrix.getInsertRCol(arrs,carr,col);
// 參數
【arrs, carr, col】
【二維數組, 給定數組, 添加列位置】
【代碼】
webTJ.clear();
var oArrs=[[3,2,5,1],[2,5,4,3],[3,1,2,4],[2,1,1,5],[4,1,3,1]];
webTJ.display(oArrs,1);
var oColv=[1,3,2,4,5]; //添加數組
var oTs=webTJ.Matrix.getInsertRCol(oArrs,oColv,1); // 在第2列添加數組
webTJ.display(oTs,1);
(3)刪除行
【語法】
// 函數
webTJ.Matrix.getRemoveRow(arrs, row);
// 參數
【arrs, row】
【二維數組, 刪除行位置】
【代碼】
webTJ.clear();
var oArrs=[[3,2,5,1],[2,5,4,3],[3,1,2,4],[2,1,1,5],[4,1,3,1]];
webTJ.display(oArrs,1);
var oTs=webTJ.Matrix.getRemoveRow(oArrs,1); //刪除第2行
webTJ.display(oTs,1);
(4)刪除列
【語法】
## 函數 ##
webTJ.Matrix.getRemoveCol(arrs,col);
## 參數 ##
【arrs:二維數組】
【col: 刪除列位置】
【代碼】
webTJ.clear();
var oArrs=[[3,2,5,1],[2,5,4,3],[3,1,2,4],[2,1,1,5],[4,1,3,1]];
webTJ.display(oArrs,1);
var oTs=webTJ.Matrix.getRemoveCol(oArrs,1); //刪除第2列
webTJ.display(oTs,1);
文中介紹了矩陣的基本運算和編輯操作,所有的示例代碼都經過了在線工具“http://www.galaxystatistics.com/webTJX.html”的運行驗證。
*請認真填寫需求信息,我們會在24小時內與您取得聯系。