Julia vs Python

Juliasta

Julia on avoimen lähdekoodin ohjelmointikieli, jolla on seuraavia ominaisuuksia:

  • Suorituskykyisyys
  • Dynaaminen tyypitys, mutta mahdollisuus määritellä tyypitys
  • Yleinen ohjelmointikieli, oliomallin hyödyntäminen sekä funktionaalinen ohjelmointi onnistuvat
  • Oppimisen helppous

Pythonilla on osittain samoja ominaisuuksia, joskin Julia on uudempi ja suunnittelussa on otettu huomioon enemmän vaatimuksia, joita esimerkiksi tieteellinen laskenta asettaa.

Asentaminen

Julian asennusohjeet Windows – ympäristössä löytyvät täältä, tärkeää on muistaa lisätä sovelluksen asennuspolku Windowsin PATH – ympäristömuuttujaan. Tätä polkua tarvitaan seuraavassa vaiheessa.

Visual Studio Code

Visual Studio Code (VSC) on Microsoftin ilmainen koodieditori, jolla on mahdollista työskennellä hyvin erilaisten ohjelmointikielien sekä templaattien kanssa. Ominaisuuksiltaan rikkaampi kehitysväline on perinteisen maksullisen Visual Studion uusin versio.

Juliaa varten on olemassa VSC laajennus, jonka käyttöönotossa pitää huomioida, että VSC:n konfiguraatio osoittaa oikeaan polkuun.

Tässä blogikirjoituksessa suoritetut koodierovertailut luotiin Visual Studio Codea käyttäen.

Erovertailua: yleistä

Julia on käännetty kieli, Julia käyttää JIT eli Just-In-Time kääntäjää. Julia on dynaamisesti tyypitetty kuten Pythonkin, mutta sen lisäksi on vaihtoehtona staattinen tyypitys. Tämä tarkoittaa, että kun muuttujille on ennalta määritelty datatyyppi, niin laajoissa ohjelmissa voidaan välttyä jo ennakolta tietyiltä virheiltä.

Uudemmissa Pythonin versioissa on myös mahdollista määritellä muuttujille datatyypit, mutta sen lisäksi pitää ottaa käyttöön erillinen kirjasto tai käyttää jonkun kehittimen kuten PyCharmin ominaisuuksia. Julian kirjastojen hallinnan moduuli on nimeltään Pkg ja Pythonissa yleisesti käytetään pip:ä.

Juliassa koodiblokin lopettaa end, myöskin kontrollirakenteissa käytetään end lopetusta eikä sisennyksessä ole toiminnan kannalta merkitystä.

Erovertailua: lineaarialgebran esimerkki

Tässä esimerkissä demonstroidaan vektorien sisätulon laskennalla näiden ohjelmointikielten syntaksia ja toiminnallisuuksia.

Pythonin numpy kirjastoa käyttäen luodaan kaksi satunnaisvektoria ja palautetaan niiden tulos.


import numpy as np

x=np.random.rand(1000000000)
y=np.random.rand(1000000000)

z=np.dot(x,y)
print(z)

Julian tapauksessa käytetään LinearAlgebra kirjastoa.


using LinearAlgebra

x=rand(1000000000)
y=rand(1000000000)

z=dot(x,y)
println(z)

Kirjaston LinearAlgebra funktio dot ei tarvitse ”as la” tyyppistä aliasta kun se on määritelty käytettäväksi using syntakstilla.

Molemmissa tapauksissa laskennan suorittaminen vei kohtuullisen paljon aikaa ja koko muisti oli käytössä sekä myös jonkinlaista muistiswappaamista tapahtui Task Managerin tietojen perusteella.

Erovertailua: funktiot

Julian funktioiden suurin ero suhteessa Pythoniin on, että funktio alkaa function määrityksessä ja loppuu end sanaan, sisennyksillä ei ole väliä, joskin on hyvä kirjoittaa selkeää koodia, jossa eri osiot erottuvat toisistaan.

Kirjoitetaan yksinkertainen lämpötilankonversiofunktio molemmilla ohjelmointikielillä.

def fromcelsius_tofahrenheit(t):
    """
    This function returns Celsius
    degrees as Fahrenheit degrees
    """
    return t*1.8+32

z=fromcelsius_tofahrenheit(30)
print(z)

Julian funktioissa on mielenkiintoinen ”dot-notaatio”, funktiosta on olemassa ilman erityistä määritettelyä vektorisoitu versio. Tuo ylempi Pythonin funktio ei hyväksy argumentiksi vektoria, mutta Julian vektorisoitu funktio hyväksyy.

function fromcelsius_tofahrenheit(t)
    """
    Returns degrees in Celsius as Fahrenheit
    degrees
    """
    return t*1.8+32
end

println(fromcelsius_tofahrenheit(30))
println(fromcelsius_tofahrenheit.([30,20,10]))

Yhteenveto

Julia vaikuttaa mielenkiintoiselta ja suorituskykyiseltä ohjelmointikieleltä, mutta tiettyjen kirjastojen vähäinen määrä rajoittaa tällä hetkellä mielestäni sen hyödyllisyyttä data-analytiikan käyttöön.  

En näe kuitenkaan suurta haastetta sen haltuunottoon, jos tilanne erilaisten kirjastojen määrän suhteen muuttuu tulevaisuudessa.

Kirjoittajasta

Kirjoittaja Asko Kauppinen
Asko Kaupppinen on Ready Solutions Oy:n konsultti ja osakas.

Kirjoittaja on Ready Solutions Oy:n konsultti, jolla on vuosien kokemus erilaisista data-alustoista.

Asko.kauppinen@readysolutions.fi

+358451374850