Hyvä valikoima voisi olla C++, Java, JavaScript, Python

Osiossa 15.3 voisi mielestäni mainita approksimointialgoritmit yhtenä lähestymistapana, ja olla mainitsematta satunnaisalgoritmeja, koska satunnaisuus on algoritmisuunnittelutekniikka jota käytetään hyödyksi kaikissa mainituissa lähestymistavoissa, ja satunnaisuudella ei ole mitenkään erityisen suuri rooli P vs NP asioissa (huom. konjektuurit että ZPP = BPP = P).

Pseudokoodia voi olla vaikea lukea, jos on kokemusta vain Java-koodista. Olisi hyvä olla selkeä vertailu näiden välillä.

Nykyinen selitys ei ole riittävän selkeä.

Hajautusta esitettäessä voisi mainita tilanteen jossa hajautustaulussa on tai siihen kerätään n indeksoitavaa alkiota jolloin pelkkä n-pituinen taulukko on käytännössä huomattavasti nopeampi. Näin vältetään ehkä tulevaisuudessa turha hajautusrakenteiden viljely.

Sanalla "virtaus" tuntuu olevan monta merkitystä: virtaus kaarta pitkin, funktio joka antaa virtauksen joka kaarelle tai yhteisvirtaus verkossa. Tätä olisi hyvä selventää.

Tulisi olla log(m) <= log(n^2) eikä log(m) = log(n^2)

Taulukossa 4.1 taulukkolista tarkoittaa kaksipäistä listaa. Usein kuitenkin opiskelijat ajattelevat, että taulukkolista on sama kuin ArrayList tai Pythonin list. Pitäisi miettiä tähän yhtenäinen terminologia, koska nyt laskari- ja tenttitehtävissä pitää aikavaativuuksia kysyessä aina selittää, millaista taulukkolistaa tarkoitetaan, ja silti aina joku opiskelija ymmärtää väärin.

Sivun 53 alalaidassa "luokkaa n/N" on myös vähän hankala. Avoimessa osoitteenmuodostuksessa n/N on aina korkeintaan 1, ja ketjutuksessakin kai yleensä (esim. Javassa oletusarvoisesti). Tässä toisaalta ei tarkoiteta skaalautumista hyvin pienillä n (kun n voi olla paljon pienempi kuin N).

Muuten huomasin nyt, että Tirakirjassa puhutaan avoimesta hajautuksesta. Itse olen yrittänyt käyttää sanasta sanaan käännöstä avoin osoitteenmuodostus, koska joidenkin lähteiden (esim. Wikipedian) mukaan "open hashing" tarkoittaa ketjutusta (mikä tietysti on sekavaa suomensi miten vain).

Lukijalle oli epäselvää, mitä tämä tarkoittaa.

Sivulla 32 compareTo ei välttämättä toimi jos on suuria lukuja

Olisi hyvä muistuttaa, että n on verkon solmujen määrä.

Otetaanko jakojäännös vai ei? Tämän voisi esittää selkeämmin.

"Ihmettelen tuossa TiRa-kirjassa lukua 6.5. Siellä lopputulos on, että O(n log n)-algoritmi (ratkaisu 3) on nopeampi kuin O(n)-algoritmi (ratkaisu 2). Tätä ei kuitenkaan ole yhtään selitetty, että miksi näin on. Olisiko tähän joku selkeä syy?"

Java- ja Python-koodien tulisi seurata kielien tyyliohjeita, jos se on mielekkäästi mahdollista.

On epäselvää, mikä on avaimen "biisoni" rooli ja mikä esimerkissä on ideana.

@pllk : This book can reach out to more audience.

Parempi toteutus olisi silmukka, joka jatkuu niin monta kierrosta kuin tulee muutoksia.

Järkevämpi teema luvulle 8 voisi olla rekursio ongelmanratkaisussa (peruuttava haku jne.). Nämä asiat ovat liian vaikeita luvussa 1, jossa voisi olla vain pieni esimerkki rekursiosta.

Hello,
Just want to check, will there be English version available for the book?

Can you please update the English version as frequently as the Finnish version?

I would really be helpful for the rest of the world.

Thanks and regards.

PS: Your English book is one of the best latex programming books I have seen

Tirakirjaa voisi hostata GitHub Pagesilla staattisesti esim. malliin näin: https://akirataguchi115.github.io/tirakirja/tirakirja.pdf

Näin kurssilaisten ei tarvitsisi ladata tirakirjaa aina koneelle lukeakseen kirjaa tai tarkistaakseen päivityksiä.

Kirjan lopussa voisi olla aikajana, joka esittelee algoritmien historiaa.

Kirjassa käytetään mjono.length()-tyyppistä notaatiota. Myös tyyli length(mjono) on hyvin yleinen. Voisi esitellä molemmat ja lisätä huomion siitä että notaatiot ovat ekvivalentteja ja kyse on vain abstraktiosta. Kunhan valitsee tyylinsä ja pitäytyy siinä.

Luvussa 1 olisi hyvä käydä enemmän ohjelmointitekniikkaa, kuten:

• taulukon käyttötapoja
• syntaksi a ? b : c
• muuttujan tyypin valinta, int vs. long
• muuta ohjelmointityyliin liittyvää

Luku 15.3: "Ideana on laskea tarkastella osaongelmia..." pitäisi varmaankin olla "Ideana on tarkastella osaongelmia...".

Voisi olla jotain tällaista:

The pdf downloadable from Github (and distributed by my teacher for our course) has issues with Nordic letter (Ä. Ö, Å) representation.
When opening the pdf in chrome the letters render fine. However, highlighting the letters and trying to copy paste out of the pdf is problematic. For example the second sentence from foreword "Alkusanat" comes out looking like this "Ensimm¨ainen vaihe on oppia ohjelmoinnin perustaidot, kuten miten k¨aytet¨a¨an muuttujia, ehtoja, silmukoita ja taulukoita."

This has some unsavory consequences for TTS (text-to-speech): the apps typically fail to recognize the words because of this erroneous representation and default to spelling out the word letter by letter. This makes the pdf borderline unusable for both blind people and people who just wish to review chapters in public transit or such. Especially modern deeplearning TTS solutions (such as Google's WaveNet) are capable of a very natural audiobook like narration, so it is quite a shame that the pdf doesn't work for this.

In my testing importing the github pdf to Microsoft Word also breaks all the nordic letters, however replacing them and then re-exporting as pdf generates a pdf that is copy-paste'able and works with TTS. It might just be export setting related issue? For the Word exported one PDF/A compliant and Document structure tags for accessibility were enabled but it is hard to say if this alone is the reason. (Word also defaults to Cambria when importing the pdf so font might also play a part)

Would be interesting to hear if other people can verify similar behaviour with copy pasting from the pdf and TTS.

Nykyinen Dijkstran algoritmin selitys (erityisesti pseudokoodi) on liian vaikeatajuinen

Olisi hyvä mainita myös englanninkielinen termi, jos se ei ole ilmeinen

Hei, hyvää työtä kirjan kanssa!

Selatessani PDF:ää löysin virheen sivulta 124.

Kuva 11.6:

• Olen siinä käsityksessä että Floydin-Warshallin algoritmi alustaa aluksi solmun etäisyyden itseensä dist[x][x] = 0.
• Tämän lisäksi lyhin polku 1 -> 4 on 6 eikä 8. Tämä olisi pitänyt päivittyä kierroksella 3.

Kirjassa kuvattu esimerkki ei vastaa pseudokoodin toimintaa

Esimerkissä puhutaan lyhyimmän reitin löytämisestä A ja B välillä, mutta pseudokoodi-esimerkki on syvyyshaulle, jolla ei välttämättä löydy lyhin reitti. Tähän olisi hyvä lisätä esimerkiksi pseudokoodi myös leveyshaulle, tai vaihtoehtoisesti muuttaa esimerkkiä siten, että siinä ei haeta lyhintä reittiä.

Voiko verkossa olla kahta samanlaista kaarta jne. Kirja ei nyt ota tähän kantaa.