Olen käyttänyt MATLABia yli 25 vuotta. (Ja sitä ennen käytin jopa MATRIXx:ää, myöhäistä, valitettavaa spinoff-yritystä, tai ehkäpä kopiointia). Se ei ole ensimmäinen kieli, jolla opettelin ohjelmoimaan, mutta se on kieli, jonka kanssa tulin täysi-ikäiseksi matemaattisesti. MATLABin osaaminen on ollut erittäin hyödyllistä uralleni.
Mutta on mahdotonta sivuuttaa Pythonin nousua tieteellisessä tietojenkäsittelyssä. MathWorksin täytyy tuntea samoin: sen lisäksi, että he ovat lisänneet mahdollisuuden kutsua Pythonia suoraan MATLABista, he ovat myös omaksuneet joitakin sen kielen ominaisuuksia, kuten aggressiivisemman lähetyksen binäärioperaattoreiden operandeille.
Olemme päässeet pisteeseen, jossa olen kyseenalaistanut MATLABin jatkuvan käytöni sekä tutkimuksessa että opetuksessa. Kuitenkin niin paljon tulee minulle siinä helposti, ja minulla on niin paljon panostettu sitä koskeviin materiaaleihin, että oli vaikea kerätä motivaatiota todella oppia jotain uutta.
Tulee MATLAB-pohjainen oppikirja, jonka olen kirjoittanut yhdessä johdantokurssin laskennalliseen matematiikkaan. Kirjassa on yli 40 funktiota ja 160 laskentaesimerkkiä, ja se kattaa mielestäni perusteellisen perustan MATLABin käytölle numeerisessa tieteellisessä laskennassa. Osittain itsensä kehittämiseksi ja osittain kirjan hyödyllisyyden lisäämiseksi ryhdyin tänä vuonna kääntämään koodit Juliaan ja Pythoniin. Tämä kokemus on johtanut siihen, että minulla on erityinen näkökulma näihin kolmeen kieleen suhteessa tieteelliseen laskentaan, jota yritän kuvata seuraavassa.
Kustannuksiin ja avoimuuteen liittyvät kysymykset jätän enimmäkseen sivuun. MATLAB, toisin kuin Python ja Julia, ei ole kaljaton eikä sanaton. Tämä on todellakin valtava ero – joillekin jopa ratkaiseva – mutta haluan tarkastella teknisiä ansioita. Monien vuosien ajan MATLAB oli monilla erittäin hyödyllisillä tavoilla paljon hyödyllisempi kuin mikään ilmainen tuote, ja jos halusi olla tuottava, kustannuksista viis. Se on erillinen näkökohta kielen ja ekosysteemin platonisesta viehättävyydestä.
Kun kustannukset jätetään sivuun, hyödyllinen kehys näiden kielten välisille eroille löytyy niiden alkuperästä. MATLAB, vanhin näistä pyrkimyksistä, priorisoi matematiikkaa, erityisesti numeerisesti suuntautunutta matematiikkaa. Python, joka aloitti tosissaan 1980-luvun lopulla, keskittyi tietotekniikkaan. Julia, joka aloitti vuonna 2009, pyrki löytämään enemmän tasapainoa näiden puolien välille.
MATLAB
Alun perin jokainen arvo MATLABissa oli joukko kaksoistarkkuuden liukulukuja. Tämän valinnan molemmat puolet, sekä matriisit että liukuluvut, olivat inspiroivia suunnittelupäätöksiä.
IEEE 754 -standardi liukuluvuille otettiin käyttöön vasta vuonna 1985, ja muistia mitattiin K:ssa, ei G:ssä. Liukulukujen kaksiluvut eivät olleet tehokkain tapa esittää merkkejä tai kokonaislukuja, mutta tiedemiehet, insinöörit ja yhä useammin myös matemaatikot halusivat käyttää niitä useimmiten. Lisäksi muuttujia ei tarvinnut ilmoittaa eikä muistia varata erikseen. Tietokoneen antaminen hoitaa nämä tehtävät ja tietotyyppien vieminen pois tieltä vapautti aivot miettimään algoritmeja, jotka toimisivat datan kanssa.
Arraytit olivat tärkeitä, koska lineaarialgebran numeeriset algoritmit olivat tulossa omaan käyttöönsä LINPACKin ja EISPACKin muodossa. Mutta niiden käyttäminen tieteellisen tietojenkäsittelyn standardikannattajalla, FORTRAN 77:llä, oli monivaiheinen prosessi, johon kuului muuttujien ilmoittaminen, kryptisesti nimettyjen rutiinien kutsuminen, koodin kääntäminen ja sitten data- ja tulostiedostojen tutkiminen. Matriisikertolaskun kirjoittaminen muodossa A*B ja vastauksen saaminen heti tulostettuna oli mullistavaa.
MATLAB teki myös grafiikasta helppoa ja paljon helpommin lähestyttävää. Ei hankalia konekohtaisia kirjastoja matalan tason kutsuineen, vain plot(x,y) ja näit melko lailla saman, minkä kuka tahansa MATLABia käyttävä näkee. Oli muitakin innovaatioita, kuten sisäänrakennetut kompleksiluvut, harvat matriisit, työkalut monialustaisen graafisen käyttöliittymän rakentamiseen ja huippuluokan ODE-ratkaisijapaketti, jotka tekivät MATLABista paikan, jossa voi tehdä tieteellisiä laskutoimituksia ajatuksen nopeudella.
Mutta vuorovaikutteisia laskutoimituksia, jopa pitkiä laskutoimituksia, varten ihanteellinen muotoilu ei aina edesauttanut hyvien ja suorituskykyisten ohjelmistojen kirjoittamista. Tietojen siirtäminen monien funktioiden välillä vaati monien muuttujien jongleeraamista ja usein tapahtuvaa tutustumista dokumentaatioon tulo- ja lähtöargumenteista. Yksi funktio levytiedostoa kohti tasaisessa nimiavaruudessa oli virkistävän yksinkertaista pienessä projektissa, mutta päänvaivaa suuressa projektissa. Tiettyjä ohjelmointimalleja (vektorointi, muistin ennakkoallokaatio) oli sovellettava, jos haluttiin välttää nopeuden pullonkaulat. Tieteellistä tietojenkäsittelyä sovellettiin nyt paljon useammilla aloilla, joilla oli valtavia määriä erilaisia natiivitietotyyppejä. Ja niin edelleen.
MathWorks reagoi tähän jatkamalla innovointia MATLABissa: inline-funktiot, sisäkkäiset funktiot, muuttujien sulkeminen, lukuisat tietotyypit, olio-ominaisuudet, yksikkötestauskehykset ja niin edelleen. Jokainen innovaatio oli todennäköisesti ratkaisu tärkeään ongelmaan. Näiden muutosten kasautuminen 40 vuoden aikana on kuitenkin johtanut siihen, että yksinkertaisuus ja konseptin yhtenäisyys ovat hävinneet. Vuonna 2009 kirjoitin kirjan, joka kattoi melko hyvin sen, mitä pidin MATLABin olennaisimpina asioina, alle 100 sivulla. Tietääkseni kaikki nuo asiat ovat edelleen saatavilla. Mutta nyt pitää osata paljon enemmän, jotta voi kutsua itseään osaavaksi.
Python
Tietyllä tavalla Pythonin historia näyttää olevan melkeinpä MATLABin peilikuvana. Molemmissa oli interaktiivinen komentorivi (jota nykyään kutsutaan yleisesti REPL:ksi (read-eval-print loop)) ja vapaus muuttujien ilmoittamisesta ja kääntämisestä. MATLAB luotiin kuitenkin numeeristen analyytikkojen leikkikentäksi, kun taas Python luotiin hakkereita ajatellen. Kumpikin kasvoi sitten kohti toista yleisöä tarkistusten ja laajennusten kautta.
Minusta Pythonista puuttuu edelleen matemaattinen vetovoima. Siellä on rumuutta ja pieniä ärsyttävyyksiä, kuten ** ^:n sijasta, @ matriisien kertolaskua varten (tuore innovaatio!), shape matriisin koon sijasta, rivikeskeinen tallennus jne. Jos uskot, että V.conj().T@D**3@V on tyylikäs tapa kirjoittaa $V^*D^3V$, sinun on ehkä mentävä lääkäriin. Ja on olemassa nollaindeksointi (toisin kuin indeksit, jotka alkavat 1:stä). Olen lukenut argumentit, enkä pidä niitä ratkaisevina. Kyse on selvästi mieltymyskysymyksestä – netin pyhien sotien aineksista – koska kummastakin yleissopimuksesta voi mainita kömpelöitä esimerkkejä. Minusta ratkaisevaa on se, että meillä on vuosikymmenien matemaattinen käytäntö indeksoida vektorit ja matriisit ykkösestä, ja suurin osa pseudokoodista käyttää tätä oletusta.
Pienien ärsytysten lisäksi pidän Python+NumPy+SciPy-ekosysteemiä kömpelönä ja epäjohdonmukaisena. Todiste A on se, että huolimatta siitä, että kieli on melko omistautunut olio-orientaatiolle, on olemassa matriisiluokka, ja silti sen käyttöä ei suositella ja se poistetaan käytöstä. Ehkä MATLAB on yksinkertaisesti turmellut minut, mutta minusta matriisit ovat tarpeeksi tärkeä objektityyppi, jotta niitä voidaan pitää ja edistää. Eikö OOP:n tärkein myyntivaltti ole se, että * voi tehdä eri asioita matriiseille ja matriiseille? Tässä suhteessa on monia muitakin epäkohtia. (Miksi tarvitsen komennon nimeltä spsolve? Enkö voi vain kutsua solve harvalle matriisille? Ja niin edelleen.)
On myös paikkoja, joissa numeerinen ekosysteemi näyttää minusta hieman ohuelta. Esimerkiksi kvadratuuri- ja ODE-ratkaisijat näyttävät vuonna 2019 minimaaliselta joukolta. AFAICT ei ole menetelmiä DAE:ille, DDE:ille, symplektisille ratkaisijoille tai implisiittisille ratkaisijoille, jotka sallivat sisäiset Krylovin iteraatiot. Tutustu näiden funktioiden viitteisiin; ne ovat enimmäkseen 30 tai enemmän vuotta vanhoja – edelleen hyviä, mutta hyvin kaukana täydellisestä. Matplotlib-paketti on hämmästyttävä teos, ja jonkin aikaa se näytti paremmalta kuin MATLAB, mutta minusta se on edelleen melko puutteellinen 3D:ssä.
Jotkut asiantuntijat väittävät, että on syvällisiä syitä siihen, miksi Python-koodi kamppailee suoritusnopeudessa käännettyjen kielten kanssa. Minua huvittaa hakutulokset hakusanalla ”python on liian hidas”. Pythonin puolestapuhujat esittävät paljon samoja perusteluja / anteeksipyyntöjä kuin ihmiset tekivät MATLABille aikoinaan. Se ei tarkoita, että he olisivat väärässä, mutta kyseessä on muutakin kuin pelkkä havainto-ongelma.
Luulen ymmärtäväni, miksi Python on ollut niin jännittävä monille tieteellisen tietojenkäsittelyn ihmisille. Siinä on jonkin verran MATLABin kaltainen syntaksi ja teho, joka on saatavilla REPL:stä. Sen ympärillä on loistavia työkaluja ja se pelaa hyvin muiden kielten ja tietojenkäsittelyn osa-alueiden kanssa. Se tarjosi tämän ilmaiseksi ja paljon paremmalla pitkäaikaisella toistettavuudella. On selvää, että se toimii hyvin monille ihmisille, jotka luultavasti näkevät vähän syytä vaihtaa.
Mutta niissä asioissa, joita osaan tehdä tieteellisessä laskennassa, Python tuntuu paljon työläämmältä oppia ja käyttää kuin mihin olen tottunut. Emme tiedä vielä vähään aikaan, jatkaako se pyyhkäisyä yhteisössä vai onko se jo lähestynyt huippuaan. Minulla ei ole erityisiä ennustuskykyjä, mutta olen karhumielinen.
Julia
Julialla on myöhäisen tulokkaan edut ja haitat. Suosittelen Julian tekijöitä siitä, että he ajattelivat pystyvänsä parempaan:
Haluamme kielen, joka on avoimen lähdekoodin kieli, jolla on liberaali lisenssi. Haluamme C:n nopeuden Rubyn dynaamisuudella. Haluamme kielen, joka on homoikoninen, jossa on aitoja makroja kuten Lispissä, mutta jossa on ilmeinen, tuttu matemaattinen notaatio kuten Matlabissa. Haluamme jotain yhtä käyttökelpoista yleiseen ohjelmointiin kuin Python, yhtä helppoa tilastointiin kuin R, yhtä luonnollista merkkijonojen käsittelyyn kuin Perl, yhtä tehokasta lineaarialgebraan kuin Matlab, yhtä hyvää ohjelmien yhteenliimaamiseen kuin shell. Jotain, jonka oppiminen on helppoa, mutta joka pitää vakavimmatkin hakkerit tyytyväisinä. Haluamme sen interaktiivisena ja käännettynä.
Uskon, että he ovat onnistuneet siinä suurelta osin. Myöhään versiossa 1.0 he näyttivät hieman vähättelevän REPL:ää, ja MATLABista lähdettiin melkein turhaan poispäin. (Miten tarkalleen ottaen LinRange on parempi kuin linspace?) Nämä ovat kuitenkin pikkuseikkoja.
Tämä on ensimmäinen käyttämäni kieli, joka ylittää ASCII:n. Saan edelleen kohtuuttoman paljon tyydytystä käyttämällä muuttujia kuten ϕ ja operaattoreita kuten ≈. Se on enemmän kuin kosmeettista; se, että kieli näyttää enemmän kirjoittamiemme matemaattisten lausekkeiden kaltaiselta, on todellista plussaa, vaikka se vaikeuttaakin hieman opettamista ja dokumentointia.
Työskentely Juliassa paljasti minulle, että olen omaksunut joitakin ohjelmointitapoja MATLABin valintojen takia, ei luontaisen ylivertaisuuden vuoksi. Vektorointi ei ole luonnollista monille asioille. On silmiä avaavaa huomata Juliassa, että voit vektoroida minkä tahansa funktion vain lisäämällä pisteen sen nimeen. Matriisin rakentaminen ymmärryksen avulla saa sisäkkäiset silmukat (tai meshgrid-temput) näyttämään siihen verrattuna bugisilta piiskoilta, ja matriisin välttäminen kokonaan yksinkertaisen yhteenlaskun generaattorin avulla tuntuu siltä kuin saisi jotakin ilmaiseksi. (Olen tietoinen siitä, että Pythonissa on samanlaisia kielen ominaisuuksia.)
Moninkertaisen lähetyksen suuri ominaisuus tekee joistakin asioista paljon helpompia ja selkeämpiä kuin olio-orientaatio tekee. Oletetaan esimerkiksi, että perinteisessä olio-orientoituneessa kielessä sinulla on Wall- ja Ball-luokat. Kumman luokan pitäisi havaita pallon törmäys seinään? Vai tarvitsetko Room-luokan toimimaan erotuomarina? Tämäntyyppiset kysymykset voivat ajaa minut sekaisin. Multiple dispatch -menetelmässä data paketoidaan oliotyyppeihin, mutta dataa operoivat metodit eivät ole sidottuja luokkaan. Eli
function detect_collision(B::Ball,W::Wall)tietää tyypit, mutta on määritelty niistä riippumatta. On vaatinut melko paljon ohjelmointia, ennen kuin olen ymmärtänyt, kuinka mielenkiintoinen ja mahdollisesti tärkeä käsite moninkertainen lähetys on kielen laajentamisen kannalta.
Numeerinen ekosysteemi on kehittynyt nopeasti. Minun ykkösesimerkkini on DifferentialEquations.jl, jonka on kirjoittanut hämmästyttävä Chris Rackauckas. Jos tämä ohjelmisto ei pian voita Wilkinson-palkintoa, järjestelmä on rikki. Menkää vain sivustolle ja valmistautukaa muuntumaan.
En ole vielä nähnyt Julian lupaamia suuria nopeusetuja MATLABiin verrattuna. Osittain se johtuu suhteellisesta kokemattomuudestani ja siitä, millaisia tehtäviä teen, mutta osittain myös siitä, että MathWorks on tehnyt uskomatonta työtä koodin automaattisessa optimoinnissa. Se ei kuitenkaan ole koodauksen osa-alue, johon keskityn suurimman osan ajasta.
Juulia-ohjelmointi on vienyt minulta jonkin aikaa, ennen kuin tunnen oloni mukavaksi (ehkä olen vain vanhenemassa ja kiteytymässä). Se saa minut miettimään tietotyyppejä enemmän kuin haluaisin, ja aina on hiipivä epäilys, että olen missannut oikean tavan tehdä jotain. Mutta jokapäiväisessä käytössä käännyn nyt yhtä todennäköisesti Julian kuin MATLABin puoleen.
Lopputulos
MATLAB on yritysratkaisu, erityisesti insinöörityössä. Se on luultavasti edelleen helpoin oppia perusnumeerisiin tehtäviin. Huolellinen dokumentaatio ja vuosikymmeniä mukana olleet oppimistyökalut ovat ehdottomasti tärkeitä.
MATLAB on tieteellisen tietojenkäsittelymaailman BMW-sedan. Se on kallis, ja tämä ennen kuin aletaan puhua lisävarusteista (työkalupaketeista). Maksat kivikovasta, sujuvasta suorituskyvystä ja palvelusta. Se herättää myös suhteettoman paljon vihaa.
Python on Ford pickup. Se on kaikkialle levinnyt ja monien rakastama (USA:ssa). Sillä voi tehdä kaiken haluamasi, ja se on rakennettu tekemään joitakin asioita, joita muut ajoneuvot eivät voi tehdä. Todennäköisesti haluat lainata sellaista silloin tällöin. Mutta se ei tarjoa suurta puhdasta ajokokemusta.
Julia on Tesla. Se on rakennettu rohkealla tavoitteella muuttaa tulevaisuus, ja se saattaa muuttaa sen. Siitä voi myös tulla vain alaviite. Mutta sillä välin pääset sinne, minne olet menossa, tyylillä ja varavoimalla.