Kertoman laskeminen BASH:illa

[petteriIII]

Lasken BC:n kuuluvan BASH:iin.

Taas kertaalleen kertoman laskemiseen tuli lisää nopeutta, tälläkertaa noin kolminkertaisesti ja nyt asia on jo oman ketjun arvoinen. Varmaankin koodi on jonkun "maailman suur-virtuoosin" tuntema, mutta minulle tämä on melkein täysin uutta vaikka sen itse teinkin "yritä-erehdy-yritä uudelleen" menetelmällä. Koodi on:

Koodia: [Valitse]

echo 'c=1;b=1;n=777;while(n--)b=(b*(n+1));b*c' | bc
- siis luku josta kertoma lasketaan on 777 . c ja b ovat vain apumuuttujia.
- en osaa C:tä. Voisiko joku C-virtuoosi kertoa onko tuo C:tä ? Asia on merkityksellinen sillä BC tottelee tuota koodaustapaa ja sillä voi laskea erittäin nopeasti mitävaan - mutta olisi kiva tuntea säännöt.

[kamara]

- en osaa C:tä. Voisiko joku C-virtuoosi kertoa onko tuo C:tä ?

Vähän muistuttaa C:tä, muttei siinä aseteta tyypityksiä, eikä ole main-funktiota eikä koodilohkoja.

[retu]

Sehän on BC:tä (koska BC suorittaa tuon koodin).

Manuaali saattaisi selventää http://linux.die.net/man/1/bc

Aika moneen ohjelmointikieleen on kyllä apinoitu c-mäinen syntaksi vaikka itse kieli muuten olisi ihan eri planeetalta, kuten perl tai javascript.

[petteriIII]

Tattista nopeista vastauksista. Mutta kyllä tuo bc:n manuaali saa taas kerran epäilemään etteivät nuo "suur-virtuoosit" edes halua kenenkään oppivan mitään, sillä tuon manuaalin perusteella ei tosiaankaan pysty tekemään mitään, eikä se minunmielestäni se ei edes vihjaa mitä kannattaisi tehdä. Lopputuloksesta kyllä näkee että lasku noudattaa manuaalia.

[kamara]

Mutta kyllä tuo bc:n manuaali saa taas kerran epäilemään etteivät nuo "suur-virtuoosit" edes halua kenenkään oppivan mitään, sillä tuon manuaalin perusteella ei tosiaankaan pysty tekemään mitään, eikä se minunmielestäni se ei edes vihjaa mitä kannattaisi tehdä. Lopputuloksesta kyllä näkee että lasku noudattaa manuaalia.

Heh... man-sivut näyttävät olettavan, että osaa ohjelmoida C:n tapaista kieltä. Man sivuissa on varsin lyhyesti esitetty syntaksi.

Tuolla on vähän helpommin lähestyttäviä esimerkkejä...
http://www.folkstalk.com/2012/09/bc-command-examples-in-unix-linux.html

Tosin nekin näyttävät loppuvan varsin lyhyeen.

Minulle tuo be on uusi tuttavuus, ja minun kannattaneen muuttaa vanhat genius-laskut bc:ksi.

Siispä kiitokset esimerkistä.

[nm]

Tattista nopeista vastauksista. Mutta kyllä tuo bc:n manuaali saa taas kerran epäilemään etteivät nuo "suur-virtuoosit" edes halua kenenkään oppivan mitään, sillä tuon manuaalin perusteella ei tosiaankaan pysty tekemään mitään, eikä se minunmielestäni se ei edes vihjaa mitä kannattaisi tehdä. Lopputuloksesta kyllä näkee että lasku noudattaa manuaalia.

Ehkäpä sinunkin kannattaisi eksyä shell-skripteistä välillä oikeiden ohjelmointikielten ihmeelliseen maailmaan.

C voi toki olla hieman tymäkkää, mutta esimerkiksi Pythonin oppimiskäyrä on loiva, ja aloittelijaystävällistä dokumentaatiota on tarjolla runsaasti. Kielenä Python on paljon Bashia mukavampi, ja bonuksena python-tulkissa on sisäänrakennettuna interaktiivinen komentorivi, joka toimii vähän kuin Bashin komentokehote.

Tässä esimerkkinä kokonainen Python-ohjelma, jolle annetaan komentoriviparametrina luku. Ohjelma laskee luvun kertoman ja tulostaa sen merkkijonona päätteeseen:

Koodia: [Valitse]

import sys

def factorial(n):
    f = 1
    for k in range(2, n+1):
        f = f * k
    return f

def main():
    if len(sys.argv) < 2:
        print("usage: {} n".format(sys.argv[0]))
        return
    n = int(sys.argv[1])
    print(factorial(n))

if __name__ == "__main__":
    main()
Pythonissa on myös laaja peruskirjasto, jonka math-moduulista löytyy mm. valmis kertomafunktio. Tässä esimerkki sen käytöstä Pythonin komentotulkissa:

Koodia: [Valitse]

$ python3
Python 3.4.3 (default, Oct 14 2015, 20:28:29)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.factorial(100)
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
>>>
Omalla koneellani sekä itse kyhätty funktio että valmis math.factorial() laskee esimerkiksi luvun 10000 kertoman 20 kertaa nopeammin kuin bc. Suurten kokonaislukujen kanssa leikkiminen on muutenkin helppoa ja mukavaa Pythonilla moniin muihin vakavasti otettaviin kieliin verrattuna. Perus-doublea suuremmat tai tarkemmat desimaaliluvut sen sijaan ovat hieman hankalampia, koska niitä pitää käsitellä decimal-moduulin tapaisilla apuvälineillä.

[jarmala]

Koodi on:

Koodia: [Valitse]

echo 'c=1;b=1;n=777;while(n--)b=(b*(n+1));b*c' | bc


Tuo antaa vastaukseksi luvun, jossa on pitkä pötkö nollia perässä:

Koodia: [Valitse]

ari@ari:~$ echo 'c=1;b=1;n=777;while(n--)b=(b*(n+1));b*c' | bc
17974887924634788591539025486098577211001520227715867075530993931989\
48060081687275262677088214223326769959970176766550428343607293200311\
50808295761857269193222722736908228562360430531917430683666632570222\
63749188634289100517816645225592929076620281516686809972708506292113\
47238619842812634704384867753777645748049771584906590024617306328379\
21146589368499153923601384860240012216365386908982665938676611128958\
37773623760412227144924481126139903060769865304045112872697393707445\
58180050557431954274929130297679261177792314752483806997060406368276\
29261705723793684679525708285489082794811185492056733837067876601909\
49401188357950934653749416601510035371227078558280729400662138020258\
52187131077418893896845177926923617544904135936067817386126599333524\
19839346158785426492364253430891798558468354200622536432107188204231\
06310065313698381286858129772320464150654043504203608892176976975983\
74627197656176432317355331159167726644587970841565158655555046509004\
97620523910098016694353927747171911162967143494305053884052549765045\
80505190691167107041745861931081890901894177492795555813214477640839\
51878738071440754496217188877703292666914149431538922390590669010636\
91873780797743177448721177187594863956254648413430376265224016968697\
51383851338778707038005276393574587764552010249435548794948336236984\
08530031074783449527450435500809834302277462577600161351356782514276\
17541862082804978298494462381855936995337013589399406284668020494916\
71510437925866380486997056855309699987703137168565517130690706274119\
54792617957837952988918425500842304586759033679193626963440095589654\
86868532248434814042685233471036391696092962299446509330110793434267\
33262802837526138105368952875793847790959210287697050414951835200418\
66375526370141798400000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
0000000
ari@ari:~$

En usko, että se on niin.

[petteriIII]

En usko, että se on niin.

Jokakerran kun kerrot kymmenellä, jollakin kymmenen kerrannaisella tai "sekä kahdella että viidellä" niin tuloksen perään tulee uusi nolla eikä se sittemmin poistu koskaan. Mutta netistä löytyy kyllä laskentapaikkoja ja niistä voi tarkistaa.

- esimerkiksi paikassa: http://www.calculatorsoup.com/calculators/discretemathematics/factorials.php

[petteriIII]

Ehkäpä sinunkin kannattaisi eksyä shell-skripteistä välillä oikeiden ohjelmointikielten ihmeelliseen maailmaan.

Olet ihan oikeassa: Python on paljon nopeampi ja muutenkin parempi kuin BASH, ja täytyy tunnustaa että laiskuuteni vuoksi en ole siirtynyt Pythonin käyttäjäksi.

Mutta oikeastaan vertailtaessa Python ei ole hyvä mutta BASH on huono - koska BASH:ia ei juurikaan ole kehitetty vuosikymmeniin sillä kaikki panokset on pistetty Pythoniin.

Eilen sanoin yhdessä postauksessani muualla että "merkityksetönhän se BASH nyttemmin on". Minut teilattiin heti esimerkiksi sanomalla: "Miksi Mikrosoft sitten tuo BASH:in Windowsiin?" .  Saapa nähdä millainen se Redmondin toteutus on - epäilenpä sen kykyjä mutta mielelläni olen väärässä. Mutta jo pelko Mikrosoftin meiningeistä saattaa pistää BASH:in kehittämiseen vauhtia.

- muuten muutakin siirtyy, taitaa myös Python kuulua joukkoon.

[retu]

Nm:n pointti ei tainnut olla niinkään python, vaan se että opettelemalla uusia ohjelmointikieliä saisit avarrettua näkövinkkeliäsi. Ehkä nuo bc scriptitkin sitten aukeaisi helpommin. Python nyt sattuu olemaan helposti lähestyttävä ja yleiskäyttöinen kieli, joten siitä on hyvä aloittaa myös imho. Että eikun käärmettä pyssyyn...

Muuten, bashin, bc:n tai pythonin saa jo nytkin windowsiin asentamalla cygwin ympäristön, johon saa koko liudan gnu/linux ohjelmia. Bash tulee myös mingw:n mukana (minimalistisempi gnu-paketti windowsille). En tiedä mikä tuo MS:n versio on, mutta kyllä senkin pitäisi silti olla samanlainen kaikkien muiden kanssa, muutenhan ne ei olisi yhteensopivia, eikä sitä sitten voisi kutsua bashiksi. (Ok, myönnetään ettei MS ole kovin kuuluisa yhteensopivuuden säilyttämisestä)

[Postimies]

Pistetään ruby versio kertoman laskemisesta.

# Ruby kertoma
#

def kertoma(n)
  if n == 0
    1
  else
    n * kertoma(n-1)
  end
end

puts kertoma(ARGV[0].to_i)

Linda Liukas on kirjoittanut Hello Ruby kirjan, joka on kuulemma
menestynyt maailmalla. Itse en ole tutustunut tuohon lapsille
suunnattuun ohjelmointioppaaseen. Itse en pidä C:stä. Se on jotain
sellaista mistä kannattaa pysyä erossa. C:llä kertoman pystynee
kirjoittamaan sellaiseen while lauseeseen, josta ei heti tajua
mitä e tekee. Tuossa yksinkertainen rekursio. Koodi on tehoton,
mutta on tarkoitettu vain esimerkiksi.

[DDR55]

unixeissa ohjelmat tehdään standardin mukaan c kielellä. skriptiohjelmat taas tehdään perl kielellä

näiden lisäksi unixiin on tehty myöhemmin muita kieliä joita monet oikeat ohjelmoijat sanovat lelukieliksi esim python, ruby, jaava, C # jne.

en ole ohjelmointia kunnolla koskaan harrastanut, ehkä voisin aloittaa sen myös tämän linux harrastuksen rinnalle 

[nm]

Itse en pidä C:stä. Se on jotain
sellaista mistä kannattaa pysyä erossa. C:llä kertoman pystynee
kirjoittamaan sellaiseen while lauseeseen, josta ei heti tajua
mitä e tekee.

Se nyt onnistuu kielellä kuin kielellä. C:n silmukkasyntaksit ovat sinänsä varsin selkeitä (for-loop voi olla aluksi outo), ja monet uudemmat kielet käyttävät samoja rakenteita. C:n tekee hankalaksi staattinen tyypitys, manuaalinen muistinhallinta ja ylivuotojen ja rajojen tarkistusten puuttuminen. Ohjelmoijan täytyy ymmärtää tietokoneen toimintaa hieman syvällisemmin kuin korkeamman abstraktiotason kieliä käyttäessä. Lisäksi C:n peruskirjasto on varsin rajallinen, joten vähänkään monimutkaisemmissa ohjelmissa on yleensä paljon riippuvuuksia muihin kirjastoihin.

Matalan tason käyttöjärjestelmäohjelmoinnissa C:lle (ja sen oliolaajennuksille, C++:lle ja Objective-C:lle) ei oikein vieläkään ole varteenotettavia vaihtoehtoja, paitsi ehkä Rust, joka on vähitellen saavuttanut suosiota. Sillä on jopa kirjoitettu toimiva käyttöjärjestelmä, Redox. Applen Swift on myös lupaava tulokas. Hieman korkeamman tason sovellus- ja palvelinohjelmoinnissa onkin sitten jo paljon enemmän valinnanvaraa ja uusia kieliä ilmaantuu sieltä täältä.

unixeissa ohjelmat tehdään standardin mukaan c kielellä.

Missä standardissa näin sanotaan?

skriptiohjelmat taas tehdään perl kielellä

Nykyisin Perliä käytetään vähenevässä määrin, vaikka sillä toteutettuja skriptejä on toki vielä paljon mukana jakeluissa. Uudet monimutkaisemmat skriptit kirjoitetaan usein Pythonilla, ja yksinkertaisemmat hommat hoituvat edelleen shell-skripteillä. Bashin sijaan järjestelmäskripteissä pyritään käyttämään kevyempää POSIX shell -yhteensopivaa syntaksia, jota voidaan ajaa esimerkiksi nopealla Dash-tulkilla.

näiden lisäksi unixiin on tehty myöhemmin muita kieliä joita monet oikeat ohjelmoijat sanovat lelukieliksi esim python, ruby, jaava, C # jne.

Hyvä tietää.

[Postimies]

Tiedä sitten noista lelukielistä. Ilman pythonia ei oikein pärjää. Pitää olla useampi asennenettuna. Jaava on/oli monissa kouluissa ensimmäisenä opetettavana kielenä. Kielenä järkevämpi kuin C, vaikka sitä paljon muistuttaa.

kertoma perlillä

Koodia: [Valitse]

sub kertoma {
   my ($n) = @_;
   my $kertoma = 1;
   $kertoma *= $n-- while $n > 0;
   return $kertoma;
}

Toivottavasti meni oikein. Esimerkki lauseesta joita jotkut tykkää kirjoittaa ja tyhmemmiltä menee
tovi ennenkuin ymmärtää mitä tuokin tekee.  C:n syntaksi mahdollistaa melko erikoisia lauseita
myös. Kun niitä on muutama sata sivua siinä on ihmettelyä. Varsinkin osoittimissa mihin kohtaan
muistia ne tässä kohtaa mahtavat osoitella. Sitä en tajua mitä hankalaa on staattisessa tyypityksessä.
Tyypin muutokset onnistuvat muistaakseni helposti. Siitä on kyllä 20 v aikaa kun luin C:n alkeet.
Muistaakseni C ei paljoa välitä mitä pistää minkin arvoksi.

C on varsin rajallinen ja se käännetään paljolti itsellään. Jos asennan uuden C:n (5) ja minulla
on C 4.x asennettuna. Ensimmäisen käännöksen jälkeen uusi C on käsittääkseni käännetty C 4:llä.
Toisella kertaa osa siitä muuttuu C 5 koodiksi. Vasta kolmas käännös toden sanoo ja uusi
C on kokonaan käännetty itsellään. Lisämausteen tuo vielä jos haluaa tehdä käännöksiä muille
alustoille... Valmiit binaaripaketit ovat kivoja ja helppoja.

[nm]

Sitä en tajua mitä hankalaa on staattisessa tyypityksessä.

Aloittelijan kannalta staattinen tyypitys aiheuttaa lisävaivaa, joka tyyppien koodaamiseen ja miettimiseen menee. Edistyneemmän koodaajan kannalta ongelmana on kielen ilmaisuvoiman rajoittuminen staattisten tyyppien ja ajonaikaisen tyyppitiedon puuttumisen vuoksi. On vaikeaa esimerkiksi toteuttaa turvallinen tulostusfunktio, joka voi ottaa vastaan eri tyyppisiä lukuja tai tietueita. Jotta funktio saadaan edes hyväksymään tällaiset parametrit, tyypit pitää hylätä funktiokutsussa kokonaan ja informaatio tyypeistä on välitettävä jotain kiertotietä. Peruskirjaston printf:ssä ongelma on kierretty luottamalla koodaajan välittämään formaattimerkkijonoon. Jos se on pielessä, suoritus voi keskeytyä ajonaikaiseen virheeseen tai joissain tapauksissa vakavampiin bugeihin. Nykyisissä C-kääntäjissä onkin erityistarkistukset printf:n formaattimerkkijonolle, mutta tämäkään ei auta, jos formaattimerkkijono muodostetaan dynaamisesti ajon aikana.

Tyypin muutokset onnistuvat muistaakseni helposti. Siitä on kyllä 20 v aikaa kun luin C:n alkeet.
Muistaakseni C ei paljoa välitä mitä pistää minkin arvoksi.

Sisäänrakennettujen numeeristen tyyppien muunnokset onnistuvat suoraan. Muut eivät, vaan niihin tarvitaan enemmän muunnoslogiikkaa tai valmiita apufunktioita. Sama kyllä pätee useimpiin muihinkin kieliin.

C on varsin rajallinen ja se käännetään paljolti itsellään. Jos asennan uuden C:n (5) ja minulla
on C 4.x asennettuna. Ensimmäisen käännöksen jälkeen uusi C on käsittääkseni käännetty C 4:llä.
Toisella kertaa osa siitä muuttuu C 5 koodiksi. Vasta kolmas käännös toden sanoo ja uusi
C on kokonaan käännetty itsellään.

Englanninkielinen termi on bootstrapping: https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
Yleinen käytäntö natiiveja binäärejä tuottavissa kääntäjissä.

Jos käännät itse GCC:n, vaiheittainen bootstrappaus kuuluu käännösprosessiin. Asentajana sinun ei tarvitse välittää siitä, eikä käännöstä tarvitse ajaa moneen kertaan riippumatta järjestelmään asennetusta GCC-versiosta. Yksittäisen buildin tuloksena on GCC, joka on käännetty itsellään.

[kamara]

C:tä puolustaa sen keveys, ja konekieliläheisyys.

Yksinkertaisen C-kääntäjän tekeminen on kohtalaisen helppoa sen ilmaisuvoiman puutteista huolimatta.

Lisäksi on paljon mukavampaa ohjelmoida C:llä kuin Assemblerilla, konekielimonitorilla saati binäärieditorilla.

Noloa myöntää, mutta jo vuosikymmen sitten, kun tein ohjelman Assemblerilla, niin se oli hitaampi kuin sama ohjelma minun tekemänä C:llä. 

Edit - Taas meni OffTopic:ksi. 

[Postimies]

Noloa myöntää, mutta jo vuosikymmen sitten, kun tein ohjelman Assemblerilla, niin se oli hitaampi kuin sama ohjelma minun tekemänä C:llä. 

Gcc kääntäjä on tehokas ja tekee hyvää koodia. Ei mikään ihme, että sen tekemä koodi on tehokkaampaa kuin sama Assemblerilla. Gcc:n tekemä koodi on hyvää ja pärjää hyvin kaupallisille kääntäjille.

Aloittelijan kannalta staattinen tyypitys aiheuttaa lisävaivaa, joka tyyppien koodaamiseen ja miettimiseen menee.

Minusta staattinen tyypitys vähentää virheitä. Jos on esim. funktio keskinopeus ja sen parametrit ovat tyyppiä matka ja aika. Niin virheellisten parametrien antamisen mahdollisuus vähenee. Ja jos tyyppiä pitää muuttaa sen voi tehdä yhdessä kohtaa koodia - helpompaa kuin käydä koko koodi läpi. Joissain kielissä tyyppi voidaan välittää myös parametrina. C:ssä parametrit ovat usein mystisiä osoittimia johonkin muistialueeseen. Näin kierretään staattinen tyypitys. Jos muistia menee vapauttamaan väärästä kohtaa niin virheen löytäminen on vaikeaa. Aloittelijan on tietty hankala ymmärtää, miksi eri tyypeille pitää olla omat funktionsa. Aika voi olla merkkijono tai numeerinen arvo. Olisi tietysti helppoa jos moisesta seikasta ei tarvitsisi välittää.

[nm]

Minusta staattinen tyypitys vähentää virheitä. Jos on esim. funktio keskinopeus ja sen parametrit ovat tyyppiä matka ja aika. Niin virheellisten parametrien antamisen mahdollisuus vähenee.

Tällaisia etuja on toki olemassa. Toisaalta dynaamisesti tyypitetyissä kielissä tuollaiset virheet havaitaan helposti ajon aikana ja yksikkötesteissä. Oma kokemukseni dynaamisista tyypeistä mm. Pythonilla on se, ettei niistä johtuvia virhetilanteita tule vastaan ainakaan enempää kuin C:llä/C++:lla, vaikka C on ollut pitkään ykköskieleni ja siitä on huomattavasti enemmän kokemusta.

Ja jos tyyppiä pitää muuttaa sen voi tehdä yhdessä kohtaa koodia - helpompaa kuin käydä koko koodi läpi.

Niin siis dynaamisesti tyypitetyssä kielessä voi onnistua noin. Staattisesti tyypitettyä koodia täytyy yleensä refaktoroida enemmän ja muuttaa tyyppimäärityksiä ja castauksia siellä täällä. IDE toki voi tehdä suuren osan tästä työstä kehittäjän puolesta, mutta riskinä on, että joku yksityiskohta tai oheisvaikutus jää huomaamatta (esimerkiksi tyypin koko ja signed/unsigned vaikuttaa laajasti laskutoimituksiin ja vertailuihin).

Joissain kielissä tyyppi voidaan välittää myös parametrina. C:ssä parametrit ovat usein mystisiä osoittimia johonkin muistialueeseen. Näin kierretään staattinen tyypitys.

Kyllä, mutta tieto tyypeistä täytyy välittää jollain muulla tavalla, ja jotta dataa voidaan hyödyntää laskutoimituksissa tai muissa toimenpiteissä, se on muutettava takaisin staattisesti tyypitetyksi. C:ssä nämä yksityiskohdat ovat pitkälti ohjelmoijan vastuulla. Dynaamisesti tyypitetyissä kielissä kääntäjä/tulkki hoitaa homman ja tarkistaa tyyppien yhteensopivuuden ajon aikana.

Aloittelijan on tietty hankala ymmärtää, miksi eri tyypeille pitää olla omat funktionsa.

Se hankaloittaa myös ammattikoodaajien elämää. C++:ssa ongelmaa kierretään malleilla (templates). Javassa ja C#:ssa on vastaavasti geneeriset tyypit.

[Postimies]

Jos käännät itse GCC:n, vaiheittainen bootstrappaus kuuluu käännösprosessiin. Asentajana sinun ei tarvitse välittää siitä, eikä käännöstä tarvitse ajaa moneen kertaan riippumatta järjestelmään asennetusta GCC-versiosta. Yksittäisen buildin tuloksena on GCC, joka on käännetty itsellään.

Jotenkin tuo C sitten syntyy tyhjästä. Vähän kuin muna ennen kanaa. Tarvitseeko se edes C:tä?

Kokeilin tuota ensimmäistä tekemääni ruby ohjelmaa. ruby kertoma.rb 3000 antaa melkoisen ison luvun. Taitaa mennä jo C:n long int tyypin yli? ruby kertoma.rb 30000 ei enää luonnistanut. 8000 kertoma tuli vielä sukkelasti - sys  0m0.004s. Tuollaisen ruby ohjelman kirjoittaa melko nopeasti. C tekee tuon tietysti nopeammin, mutta jos ruby tekee alle sekunnin onko merkitystä?