Talk:R-tools

From Opasnet
Jump to: navigation, search

Kehitysideoita

Vapaamuotoisesti finglishinä.

Rstudio Shiny

Törmäsin tämmöiseen joskus R-bloggers sivulla: http://shiny.rstudio.com/ Se näyttäis olevan pidemmälle kehitetty interaktiivinen web app joka tekee samoja asioita kuin meidän R-tools. Se ei ole open-source, mutta ilmanen versio on suht feature complete. http://shiny.rstudio.com/articles/shiny-server.html En tiedä miten toimis käytännössä, mutta jos R-tools ikinä räjähtää meidän käsiin niin tässä vois olla alternatiivia.

Probabilistinen inputin tulkinta

Käyttäjän pitäisi pystyä antamaan probabilistisia lähtötietoja tietämättä todennäköisyyslaskennasta paljoakaan tai jopa mitään. Rcoden pitäisi ymmärtää selkokielisiä epävarmoja ilmauksia. Jos inputiksi annetaan esim. 50 - 250, rcode voisi tulkita tämän data.frame(run = 1:100, data = runif(100, 50, 250)).

Toinen tähän liittyvä toiminnallisuus olisi se, että mallit rakennettaisiin järjestelmällisesti niin, että vaikka ne olisivat deterministisiä alunperin, ne toimisivat myös probabilistisina, jos joku vain antaa syötteeksi jakauman. Tämän toteuttaminen vaatisi mietintää, että miten sen haluttaisiin toimivan periaatteessa. Vasta sitten sen voisi toteuttaa käytännössä. Tässä joitakin ajatuksia. En ole perehtynyt, miten Teemu tai muut ovat toteuttaneet probabilismin.

Jos malli on probabilistinen, käytettävissä data.frameissa on sarake run = 1:n, jossa oletusarvo n:lle on esim. 1000. Kun muuttujia malleissa yhdistellään, ne mergataan asianmukaisesti runilla kuten muillakin yhteisillä indekseillä. Pitäisikö runin pituus pakottaa samaksi kaikissa mallin osissa? Pitäisikö tämä tehdä automaattisesti? Entä jos ei tee?

TODO: {{#todo:Tämä oli se päivällä mieleen tulematon ajatus. Ei taida olla ihan valmis toteutettavaksi. Jouni|Teemu Rintala|Opasnet}}


----#: . Inputtiinhan voi laittaa funktioitakin. Esim. data.frame(Iteration = 1:10, Result = runif(10,2,4)) voi käyttää inputtina. Niin kauan kuin mallit rakennetaan käyttäen dataframeja ja mergeä probalistiset muuttujat toimivat itsestään jos niillä on joku samanniminen iteraatio-sarake. --Teemu R 10:59, 22 August 2011 (EEST) (type: truth; paradigms: science: comment)

Variables new syntax

Variablesit voisi laittaa määritettäväksi niin, että attribuuttien järjestyksellä ei ole väliä. Yksi mahdollinen tapa olisi sellainen, että attribuutit annetaan nimettyinä esim. näin: <rcode variables="name:<muuttujan nimi>|description:<muuttujan kuvaus>|default:<oletusarvo>">. Tässä on myös se hyvä puoli, että tulevaisuudessa uusia optionaalisia attribuutteja voidaan vaivatta lisätä. Oikeastaan pakollinen noista on muutenkin vain "name". Tähän malliin siirryttäessä voidaan myös taata vanhojen r-coodien taaksepäin-yhteensopivuus helposti. Tutkitaan vain, että löytyykö "name:", jos ei, niin sitten parseroidaan vanhan mallin mukaisesti tripletit.

Ylläoleva on jo toteutettu!

Variableille erilaisia tyyppejä

Olisi hienoa, jos variablesit voisi jotenkin tyypittää. Yksi ratkaisu, liittyen yllä esitettyyn, olisi "type"-attribuutti. Jos esim. "type:date", niin muuttujalle näytetään wiki-sivulla kolmesta alasvetovalikosta koottu päivämäärän valinta. Lisäksi hyödyllisiä tyyppejä voisivat olla "select" ja "checkbox". Näille tarvittavat optiot voisi antaa esim. "options"-attribuutilla puolipisteellä erotettuina pareina siten, että ensin on value ja sitten description (joka näytetään käyttäjälle). Esim. näin: <rcode variables="name:test|description:Testivariable|default:kuopio|type:checkbox|options:turku;Turku;kuopio;Kuopio(home town);helsinki;Helsinki">. Esimerkin muuttuja näkyisi käyttäjälle checkbox-ryhmänä, josta esivalittuna Kuopio.

GOSUB toiselle sivulle

Aiemminkin on keskusteltu siitä, että joskus pitäisi pystyä ajamaan eri sivuilla olevia koodeja osana jotain mallia. Toistaiseksi ratkaisuvaihtoja on ollut kaksi, mutta nyt ehdotan kolmatta:

  1. Koodi kopioidaan kyseiselle sivulle käsin.
  2. Olennaisen koodit rakennetaan paketiksi esim. OpasnetBaseUtilsiin tai vastaavaan, ja ladataan serverille.
  3. Otetaan käyttöön funktio #GOSUB("Op_en2345"), joka ei kommenttimuotoisena tee R:ssä mitään mutta serveri-R:llä ajettaessa käynnistää R:n ulkopuolisen rutiinin, joka kaivaa sivulta Op_en2345 ensimmäisen löytyvät R-koodin ja sijoittaa sen R-skriptiin kyseiselle kohdalle, jolloin se ajetaan osana ensimmäistä koodia. (Jos koodin haluaa ajaa omalla koneella, pitää GOSUB-koodit käydä kopioimassa käsin.) Tietoturvan kannalta lienee järkevää, että GOSUB-koodeja voi hakea vain Opasnetistä (fi tai en). (Vaihtoehtoisesti jos niitä haetaan Heandesta, se tehdän vain jos käyttäjä on loggautunut sinne sisään; tämä voi olla monimutkaista kertoa serveritasolla eikä kovin tärkeää.)

----#1: . GOSUB idea on sinällään hyvä. Tuohon voisi lisätä vielä skriptin nimen, jolloin ei haettaisi aina ensimmäistä vaan se tietty (rcode-tagin name parametrillä määritetty). Nimenä GOSUB on ehkä mielestäni vähäsen harhaanjohtava. Ehkä joku "include_code" tai vastaava olisi helpommin ymmärrettävä? Tuossa on oma haasteensa IT-huoneen porukalle, jotta saadaan parsittua wikisivun contentista oikeet koodit! --Einari 09:11, 22 June 2011 (EET) (type: truth; paradigms: science: comment)

←--2: . Kannatetaan tuota namen käyttöä. Itse nimi GOSUB on vain vitsi, kun tuli mieleeni että tuolla nimellähän ajettiin vastaavanlaisia alirutiineja Basicissä 80-luvulla. Toivottavasti joku nimeää uudelleen. {{{3}}} (type: truth; paradigms: science: defence)
----3: . Toteutettu R-toolsissa "include" attribuutilla! --Einari 13:42, 05 October 2011 (EET) (type: truth; paradigms: science: comment)

R-coden piilotus oletusarvoksi

Olisi aloitteleville käyttäjille ystävällistä, että pitkät ja vaikeaselkoiset R-koodit piilotettaisiin oletusarvioisesti. Eli näytettäisiin vain parametrien syöttökenttä ja teksti "Show code", jolla itse koodin saisi näkyviin.

Hienostelua mutta hienoa on sitten semmoinen parametri rcodeen, että esim. show_code="Yes" ajaisi yli oletusarvon ja näyttäisi kyseisen koodin. Käyttäjä saisi sen tietysti piiloon klikkaamalla "Hide code".

----#2: . Job done --Einari 08:48, 11 August 2011 (EET) (type: truth; paradigms: science: comment)