Keskustelu: Yleinen keskustelu: Kommentteja R:stä

Olen huomannut, että monet kunnialliset ohjelmoijat ovat nykyään kiinnostuneita R:stä ja olisivat kiinnostuneita opettelemaan sitä. Tekisi melkein mieli sanoa, että eipä maksa vaivaa. Kirjoitin vähän aikaa sitten seuraavat valitukset, joita kuvaavaa kyllä ei hyväksytty kummallekaan R-yhteisön isolle sähköpostilistalle:

"I have been using R for over 15 years. I want to raise an issue which has been haunting me for some time now: It feels as if R is falling apart. I try to justify this feeling by providing three discussion points:

1. Version compatibility issues seem to be on the rise. Very often, you get the message that package x was built on R version y (and thus, won't work in your version of R). When you update to the latest version of R, you realize that not all packages are available for that version. It seems that for each version, only a (non-predictable) subset of packages is available.

2. The overhead of installing new packages seems to be on the rise. It seems that the packages depend on more and more other packages. The more packages you have in the 'foundations' of package x, the more likely it is that one of these causes an error and the whole stack fails. Installing used to be easy back in the day: You got a 20 lines' output. Now you get endless prints. I may be mistaken but some packages seem to require admin rights on your computer which you don't often have on your work PC.

3. R seems to be developing into different dialects. You have dplyr and tidyr, some people prefer data frames, some prefer tibbles. Some people use pipes, some use traditional syntax. Some prefer object-oriented programs, some prefer procedural scripts. If you put in a job announcement that somebody has to know R, it doesn't mean the same thing for different people.

If you compare the use experience of R in 2025 to that of Matlab, the difference is striking: Matlab is concise and clear, R is more and more about endless prints. Of course, Matlab is a commerical product, but R used to be the same way. I don't know if many other people feel the same way, but I think I am shifting away from R."

Voi vielä sanoa, että ero Matlabiin on todella iso. Alkuperäinen syy lähteä käyttämään R:ää oli, että se oli kätevä korkean tason kieli. Onhan se vieläkin korkean tason kieli, mutta enpä tiedä kätevyydestä.

Englanninkielisiin valituksiin voi vielä lisätä sen, että kontribuoidut paketit voivat sisältää mitä tahansa. Olen löytänyt niistä ihan selviä laskuvirheitä. Sanoisin että base R:ään ja yleisimpiin paketteihin (stringr, readxl yms.) voi jollain tasolla luottaa, muuhun ei.

Minusta Octave on paljon parempi kuin R, mutta R on syntaksiltaan sulavampi, jos tekee vain tilastoanalyysejä. Yleiseen laskentaan, ei todellakaan. Nuo muut ongelmat ovat osiltaan myös Python:issa. Octave:ssa suurin ongelma on Matlab-vastaavuus.

R ei ole yleinen korkean tason kieli, vaan se on erikoiskieli tilastollisiin skripteihin. Matlab on korkean taso kieli matriiseilla tehtäviin laskelmiin. Python on yleinen korkean tason kieli.

Oikeastaan näissä kaikissa häiritsee se, että ne ovat liian lähellä toisiaan, joten sitten usean manageroimisesta tulee vain turhaa työtä.

Olisi parempi, jos ne kaikki olisi toteutettu tulkkeina Pythoniin.

Small kirjoitti:

If you put in a job announcement that somebody has to know R, it doesn't mean the same thing for different people.

Onko tämä erityisesti R:ään liittyvä ongelma vai yleisempi ongelma? Ajattelisin itse, että sama ongelma voisi olla myös haettaessa esim. C++- tai PHP-ohjelmoijaa.

Small kirjoitti:

If you compare the use experience of R in 2025 to that of Matlab, the difference is striking: Matlab is concise and clear, R is more and more about endless prints.

Mitä "endless prints" tarkoittaa? Olen tutustumassa lähiaikoina R-kieleen työhöni liittyen ja aihe kiinnostaa tämän takia.

Vielä semmoinen, että R pitää muistaa S:n seuraajaksi, joten sen oikea vertailukohta on SAS eikä esim. Octave, Matlab tai Python. On toki totta, että näissä vaihtoehdoissa on jossain määrin vastaava toiminnallisuus, mutta ei todellakaan SAS:n kirjastoja. Avoimessa lähdekoodissa on kuitenkin niin paljon muitakin ongelmia, että sanoisin, että eri syntaksien ja runtime:jen tekeminen ei ole prioriteettilistan kärjessä.

Jos katsot tuota "open source" -menua tuolla ylhäällä täällä: https://developer.sas.com/open-source/python

niin huomaat, että SAS antaa kyllä työkaluja neljään kieleen:

Python, R, Lua, Java

joten SAS:n kontekstissa luulisi, että nämä ovat kaikki hyviä vaihtoehtoja. Valtava ero on kuitenkin, että näistä muita on hyvä käyttää muuhunkin, mutta en tiedä, miksi kukaan tekisi R:llä mitään muuta kuin SAS-tyylisiä ohjelmia. Näistä myös Python on selvästi yleisin muuten ja Java-SAS kuulostaa vaan todella työläältä, joten siksikin Python on vaan paras.

Toisaalta riippuen kontekstista, R voi olla hyödyllinen joihinkin proto-tason juttuihin. Jos halusin tehdä tekoälyn prototyyppejä, niin saattaisin harkita R:n käyttämistä jonkin LISP:in sijaan.

R on jännä kieli. Sillä voi tehdä ihan söpöjä pikku skriptejä jos on tarve vaikka ladata cvs-tiedosto ja visualisoida dataa esim. ggplot2-kirjaston avustuksella. Suurempaan projektiin en sitä käyttäisi. Itseäni risoo mm.

- Virheilmoitukset: Kun Pythonissa jokin menee pieleen, saat selvän stack tracen ja koodiin liittyvän virheilmoituksen. Kun R:ssä jokin menee pieleen, niin virheilmoitus on aina luokkaa "Abort in malloc.c".
- Yllättävät rajatapaukset: Esim. 1-rivinen matriisi muuttuu slaissatessa implisiittisesti vektoriksi (joka käyttäytyy kuin 1-sarakkeinen matriisi), joten lineaarialgebraa tekevä koodi voi toimia normaalisti mutta yllättäen hajota jos joku osatulos sattuu olemaan 1:n kokoinen.
- Oudot semantiikat: Moni ei edes tiedä että R on laiskasti evaluoitu kieli kuten vaikka Haskell; f(g()) evaluoi g():n vasta kun f käyttää sen arvoa. Tämä mahdollistaa söpön syntaksin dataa manipuloiville kirjastoille kun dplyr yms, mutta vaikeuttaa refaktorointia kun niin paljon kaikenlaista taikuutta tapahtuu implisiittisesti.

Voi olla että olen vähän tarpeettoman negatiivinen koska yksi ikävimpiä työmuistojani oli ylläpitää tilastotieteilijöiden kirjoittamaa R-ohjelmaa, joskin kuten sanottu niin FORTRANia voi kirjoittaa millä tahansa kielellä.

KORJAUS: Viestini julkaistiin R-help-listalla, ja sain muutaman asiallisen vastauksen. Vastaajat myönsivät, että jotain ongelmaa voi olla olemassa, mutta varoittivat minua, että muut open source -kielet ovat ihan yhtä pahoja.

Antti Laaksonen, tämä on tosiaan ongelma monessa kielessä/teknologiassa. Loputtomat skriptit tarkoittavat sitä tilannetta, kun jotain suosittua pakettia varten pitää asentaa kaikki sen riippuvuudet, ja jokainen näistä tuottaa oman printin, joka sitten usein sisältää varoituksen tai virheen. Omien subjektiivisten muistikuvieni mukaan tyypillisellä paketilla oli aikoinaan 2-3 riippuvuutta. Nyt tuohon voi pistää nollan perään. (Toki monet paketit tuottavat printtejä myös käytössä.)

mavavilj, kyllähän R:llä voi periaatteessa tehdä kaikkea mitä muillakin ohjelmointikielillä, mutta enpä lähtisi tekemään sillä esim. webbiohjelmointia.

Sisuaski, kokeilepa R:n pyöristystä: round(c(0.5,1.5,2.5,3.5)) tai kokeile poistaa rivejä komennolla A = A[-which(0>1:10),]. Nämä on vain näitä pikku ihmeellisyyksiä, jota pitää tietää!

Small kirjoitti:

kokeilepa R:n pyöristystä: round(c(0.5,1.5,2.5,3.5))

No R käyttää oletuksena pankkiirin pyöristystä. Eihän tuossa ole mitään ihmeellistä, näin VB6:kin teki. :D

Sanoisin että ohjelmointikielestä riippumatta auttaa jos tietää mitä funktiot tekee eikä oleta.

Minusta tuntuu vähän, että AP:lla on vähän heikko kokemus ohjelmointikielistä ja R:stäkin. Siksi painotetaan nyt vielä, että R ei missään nimessä edes näytä yleiseltä dynaamiselta kieleltä, vaan nimenomaan sellaiselta, jolla on sopiva tehdä tilastollisia skriptejä. Niissä on ihan erityinen malli, ja tämän puolia ovat esim.:

* dataa tulee voida transformoida lyhyillä käskyillä eli vähällä vaivalla, koska tätä tehdään usein tilastoanalyyseissä
* iteraatioiden tulee olla nopeita, koska niitä tehdään usein paljon
* kielessä ei ole tarpeen olla mukana konstruktoita, joita tilastoanalyysissä ei yleensä tarvitse

Tässä nyt vaikkapa yksi näkemys, miksi R ei ole yleinen ohjelmointikieli:

https://stackoverflow.com/questions/11073253/is-there-a-way-to-declare-public-and-private-methods-for-s4-reference-classes

Vaikka se voisi olla sellainen, niin se ei välttämättä ole hyödyllistä.

Aloituksen R:n ja Matlab:in vertailu on hieman ongelmallinen, koska hyödyt ja haitat riippuvat käyttötarkoituksesta. R vs Python on jo hieman hedelmällisempi.

mavavilj, tarkoitatko että "OP:llä on vähän heikko kokemus ohjelmointikielistä"? Olen kyllä ohjelmoinut useilla kielillä yli 20 vuotta, mutta niistä tosiaan ylivoimaisen valtaosan R:llä. Kuitenkin muista kielistä on kokemusta sen verran, että osaan verrata. Mikään ammattiohjelmoija en kyllä missään tapauksessa ole, vaan dataorientoitunut ohjelmoija.

* R:n käskyt eivät useinkaan ole lyhyitä verratuna esim. Matlabiin. Käytännössä pituus tulee siitä, että täytyy jatkuvasti tarkistaa erilaisia poikkeustapauksia, esim. drop=F lienee tuttu ja myös esim. tuossa rivien poistossa joutuu käyttämään if-lauseketta.

* R:n matriisioperaatiot ovat nopeita mutta iteraatiot hitaita. Tästä syystä vähänkin isommassa datassa vältän viimeiseen asti datan läpi käymistä for-silmukalla ja pyrin aina käyttämään R:n erikoisfunktioita kuten applya ja tapplya, mutta näistä tulee sitten kankea syntaksi.

* Kielessä on mukana konstruktioita esim. visualisointiin, tieteelliseen laskentaan jne. Minulla ei sinänsä ole mitään tätä vastaan, mutta ollaan varmaan yhtä mieltä siitä, että R:n järkevin käyttötarkoitus on tilastoanalyysi. Tuossa lähettämässäsi linkissä pohditaan public- ja private-metodeja. Hyvä keskustelu, mutta eihän kaikki kielet ole oliokieliä?

Sanoisin että jos tarvitsee tehdä nimenomaan tilastoanalyysia (suht pienellä) datalla, tietää mitä tekee ja haluaa tehdä nätin skriptin, joka tulostaa valmiit tulokset esim. tekstitiedostoon, niin siihen R on omiaan.

R:n ja Matlabin vertailu ei tosiaan ole oikeudenmukaista siinä mielessä, että Matlab-lisenssi maksaa. Entäpä sitten tämä Octave? Onko jollain lukijoista kokemusta Octavesta?

Small kirjoitti:

R:n ja Matlabin vertailu ei tosiaan ole oikeudenmukaista siinä mielessä, että Matlab-lisenssi maksaa. Entäpä sitten tämä Octave? Onko jollain lukijoista kokemusta Octavesta?

Kyllä, mutta en tekisi silläkään R:n juttuja, koska R:llä on vahvempi tilastoyhteisö takanaan.

Tässä kun pohdit näitä, että mikä syntaksi on hyvä ja näin, niin muista nyt edelleen, että R on SAS-vaikutteinen. SAS:ssa on esim. DROP:
https://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a000202902.htm
https://online.stat.psu.edu/stat481/lesson/14/14.2

No tuo, mitä vertailet ei edusta minusta valistunutta vertailua, koska vertaat ominaisuuksia, jotka eivät ole R:n päätavoitteita välttämättä. Siksi vertailu on harhaanjohtavaa, koska se on apples to oranges -tyylistä, minusta.

Täälläkin R:llä on erilainen suosio kuin Matlab:illa, joten go figure:

https://survey.stackoverflow.co/2024/technology­#2-programming-scripting-and-markup-languages

Apples to oranges: https://en.wikipedia.org/wiki/False_equivalence

Jaahas, ehkä mun kokemus tilastoanalyysista on, että aina tarvii tehdä sitten kuitenkin jotain muuta kuin varsinaista tilastoanalyysia, esim. matriisioperaatioita, I/O:ta, datan muokkausta, kuvia jne.

Eli vaikka se vakiomuotoinen tilastomalli toimii hienolla syntaksilla, esim. lineaariselle mallille mod = lm(y~., data=mydata), mutta se on vain pieni osa sitä worflow'ta. Joku sanoi hyvin, että tilastohommissa 90% on datan muokkausta ja 10% datan analysointia, ja sitten on tosiaan kaikkea muuta.

Small kirjoitti:

Jaahas, ehkä mun kokemus tilastoanalyysista on, että aina tarvii tehdä sitten kuitenkin jotain muuta kuin varsinaista tilastoanalyysia, esim. matriisioperaatioita, I/O:ta, datan muokkausta, kuvia jne.

Joo ja esim. minusta R:llä datat ovat jo lähtökohtaisesti esim. pienennettyjä. Ei kukaan jauha jollain R:llä jotain big data:n pilkkomista, koska se on hidas siihen. Sen sijaan, se on nopea siihen, jos puhdistetuista data set:eistä pitää tehdä päätelmiä. Kuviakin on helppo tehdä.

En myöskään tekisi jotain matriisista FEM-mallia R:llä, koska Matlab/Octave on siihen enemmän käytetty. Signaalinkäsittelykin on vähän siinä ja siinä, että miten paljon sitä kannattaa yrittää R:llä vs Signal Processing Toolbox:illa.

Small kirjoitti:

(19.06.2025 16:26:57): Eli vaikka se vakio­muo­toinen tilas­to­mal­li...

Niin eli R:n vahvin puoli on tuossa 10% osassa.

Tein taannoin yhdessä projektissa data set:ien muodostamisen Python:issa ja vain analyysin R:ssä. Tämä oli paljon hyödyllisempi balanssi kuin pelkkä R. R on paljon nopeampi käyttää plot:eihin yms., mutta Python on nopeampi käsittelemään dataa, ja sen syntaksi antaa tehdä ohjelmista selkeämpiä ja ylläpidettävämpiä.

Jeps, samoilla linjoilla ollaan.

Tuossa mainitsemassasi esimerkissä joutuu sitten tietysti tekemään käsityötä ja hyppimään R:n ja Pythonin välillä - ellei sitten tee shell-skriptiä, joka ajaa molempia kieliä - tai jos tarvitsee iteroida R:ssä mallia, niin kutsuu Pythonia R:n sisältä - mitä en ole itse saanut koskaan toimimaan.

Small kirjoitti:

(19.06.2025 16:36:11): Tuossa mainit­se­massasi esimerkissä joutuu...

Siihen nimenomaan kannattaa tehdä shell-skriptejä siten, että voi hallita koko pipeline:ä mielellään yhdestä tiedostosta.

Jos muistan oikein, niin voi kuitenkin myös tehdä pelkän Python-skriptin ja sitten aloittaa sen sisällä oikeissa kohdin R-skriptejä prosesseina. Nämä R-skriptit voi halutessaan myös generoida Python:ista.

^Niin ja toisin kuin shell-skriptit, niin Python on myös luettavampaa ja hyvin portautuvaa.

Octave:en/Matlab:iin kannattaa suhtautua sellaisena, jossa tekisi asian muuten C++:lla, mutta johon asiaan C++ on liian työläs käyttää.

ChatGPT antoi tämmöisen esimerkin esimerkiksi:

R:

data(mtcars)
model <- lm(mpg ~ wt + hp, data = mtcars)
summary(model)

Matlab:

load carsmall
X = [Weight, Horsepower];
y = MPG;
b = regress(y, [ones(size(X,1),1), X]);
disp(b)

Laajempi esimerkki:

library(tidyverse)

# Read CSV
data <- read_csv("data.csv")

# Group by 'Group' and summarize
summary_stats <- data %>%
  group_by(Group) %>%
  summarise(
    mean_score = mean(Score),
    sd_score = sd(Score),
    count = n()
  )

print(summary_stats)

# Grouped bar plot
ggplot(summary_stats, aes(x = Group, y = mean_score, fill = Group)) +
  geom_col() +
  geom_errorbar(aes(ymin = mean_score - sd_score, ymax = mean_score + sd_score), width = 0.2) +
  labs(title = "Mean Score by Group", y = "Mean Score") +
  theme_minimal()

# Boxplot of Score by Group
ggplot(data, aes(x = Group, y = Score, fill = Group)) +
  geom_boxplot() +
  labs(title = "Score Distribution by Group") +
  theme_minimal()

% Read the CSV
data = readtable('data.csv');

% Grouping using 'findgroups'
[G, groupNames] = findgroups(data.Group);

% Summary statistics
mean_score = splitapply(@mean, data.Score, G);
sd_score = splitapply(@std, data.Score, G);
count = splitapply(@numel, data.Score, G);

% Display as a table
summaryStats = table(groupNames, mean_score, sd_score, count)

% Grouped bar plot with error bars
figure;
bar(mean_score)
hold on
er = errorbar(1:length(mean_score), mean_score, sd_score, 'k', 'linestyle', 'none');
set(gca, 'XTickLabel', groupNames)
xlabel('Group')
ylabel('Mean Score')
title('Mean Score by Group')
hold off

% Boxplot of Score by Group
figure;
boxplot(data.Score, data.Group)
xlabel('Group')
ylabel('Score')
title('Score Distribution by Group')

^Joista ehkä jo nähdään, että kyseessä on apple to oranges -vertaus, koska R on selvästi vahvempi näissä esimerkeissä. Tämä ei kuitenkaan tarkoita, että se on yleisesti parempi kuin Octave/Matlab, vaan tämä riippuu siitä, että mitä tehdään.

Jos ratkaistaan osittaisdifferentiaaliyhtälö, niin balanssi vaihtuu:

Matlab:

function heat1D
    m = 0; % Cartesian coordinates (1D)
    x = linspace(0, 1, 50);
    t = linspace(0, 0.5, 100);
    sol = pdepe(m, @pdefun, @icfun, @bcfun, x, t);

    % Plot the solution
    surf(x, t, sol)
    title('1D Heat Equation')
    xlabel('x'), ylabel('t'), zlabel('u(x,t)')
end

% PDE function
function [c, f, s] = pdefun(x, t, u, dudx)
    alpha = 0.01;
    c = 1;
    f = alpha * dudx;
    s = 0;
end

% Initial condition
function u0 = icfun(x)
    u0 = sin(pi * x);
end

% Boundary conditions
function [pl, ql, pr, qr] = bcfun(xl, ul, xr, ur, t)
    pl = ul; ql = 0;
    pr = ur; qr = 0;
end

R:

# Load libraries
library(ReacTran)
library(deSolve)

# Spatial grid
nx <- 50
x <- setup.grid.1D(x.up = 0, x.down = 1, N = nx)
dx <- x$dx
alpha <- 0.01

# Initial condition
u_init <- sin(pi * x$x.mid)

# PDE function (finite difference)
pde_model <- function(t, state, parms) {
  dudx <- tran.1D(C = state, D = alpha, dx = dx, full.output = TRUE)
  list(dudx$dC)
}

# Time sequence
times <- seq(0, 0.5, by = 0.01)

# Solve the PDE
out <- ode.1D(y = u_init, times = times, func = pde_model, parms = NULL,
              nspec = 1, names = "u", dimens = nx)

# Plot the solution
image(x$x.mid, times, out[,-1], xlab = "x", ylab = "time", main = "1D Heat Equation")

Sitten jos tätä yo. ratkaisee Python:illa, niin yksi ongelma on se, että siinä ei tule mukana esim. funktiota pdepe().