Ohjelmointi

[a4]

^
Olisiko tässä mitään ideaa, tai sisältyikö tämä jo kokeiluihisi?: ..at the position of each of these points we simply draw a circle of a given radius (20 pixels in my case).
https://bitesofcode.wordpress.com/2020/04/09/procedural-racetrack-generation/

[-:)lauri]

^
kiitos. Pitääpä tutustua.

[-:)lauri]

^^
Stana! Tuohan vaikuttaa loistavalta. Kuten jo alunperin hieman ounastelinkin, joku on ajatellut saman asian paljon paremmin kuin minä. Ainakin kuvien peusteella tuo näyttää lupaavalta. Tuo on vieläpä tehty pyyttonilla jo valmiiksi. Ei tarvitsisi erikseen konvertoida javascriptistä pyyttoniksi, jos ihan tuolla pohjalla onnistuu myös testaus pysyykö auto radallaan.

Olen tosin vielä kokonaan ylenkatsonut vaihtoehtoa, jossa testataan pikselin värin perusteella, ollaanko ajoradalla vai sen ulkopuolella. Se olisi varmaankin helpoin toteutttaa sillä ei tarvitsi pohtia sitä kuinka rata määriteltäisiin vektoreissa vaan voisi piirrellä ajoradan miten huvittaa vaikkapa Paintilla, ladata kuva sisään ohjelmaan ja sitten vaan katsoa pikseleiden värien perusteella, ollaanko radalla vai sen ulkopuolella.

[-:)lauri]

^
Samaten tuo pikselien värien lukeminen mahdollistaisi varmasti myös radan vektorisoimisen.

EDIT tosin ainut juttu vektorisoimisesta, jonka nopeasti löysin, ehdottaa tuon marching squaresin käyttöä siihen. Ja ilmeisesti löytyy valmis kirjasto tuota varten: https://github.com/OSUblake/msqr

[-:)lauri]

Vaikuttaa siltä, että homma etenee. Tässä on tarvinnut tehdä hieman kompromissiä sen suhteen, kuinka tarkkaan viivaa seurataan ja kuinka pehmeä viiva rakennetaan. Mun tarttee kyllä tota jotenkin vielä hioa, mutta periaatteessa tämä alkaa riittämään: https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB. En keksinyt keinoa tehdä tuota interpolaatiota, joten jouduin turvautumaan viivan pyöristäjään se vie nyt saatanasti aikaa että se muodostaa tuon viivan. Pitää tutkia vielä, miten saan tähän interpolaation. Se lienee nopeampia tapa pyöristää rosoisuus kuin tuo käyttämäni viivan pyöristäjä.

^
Nyt on ongelma. Molemmat ääriviivat koostuvat nyt siis pienistä viivoista, jotka ovat keskenään sekaisin samassa listassa. Jotenkin pitäisi nyt kyetä järjestää ääriviivat, omiin listoihinsa ja vieläpä sinä järjestyksessä, kuin ne näyttävät olevan kuvaruudulla.  Kellään ideoita miten?

Meni saatanasti aikaa, että sain ratkottua tämän pulman. Jos tuota ei olisi ratkaissut, nyt käyttämääni viivan pyöristysfunktiota ei olisi voinut käyttää kun se ei olisi osannut yhdistää oikeita pisteitä toisiinsa kun ne eivät olleet järjestyksessä.

Edit: eivät ne kaikki ole järkässä vieläkään mutta riittävän hyvin kuitenkin.

Tätä voisi kehittää. Ongelmana on nyt se, että jos haluaa interpoloida noita pisteitä, joiden kautta viiva piirretään ja ilman tuota raskasta laskentaa olemassaolevian pisteiden pehmentämiseksi, pitää piirtää reunoilta burrattu viiva ja interopoloida marching squares -viivoja. Ongelma on nyt, että sitä ei voi laskea piirretyn kuvion vektorigrafiikasta suoraan koska pisteet eivät ole tasaisin välimatkoin eivätkä riitävän lähellä toisiaan. Tämän voisi ehkä kiertää niin, että piirtäisi viivan viivatyökaluilla pikseligrafiikaksi, generoisi siitä kuvan ja laskisi tuon kuvan pikselien perusteella, mikä on minkäkin ruudukon pisteen opasitetti. Näin viiva olisi yhtenäinen marching squaresin laskettavaksi sen lisäksi, että nyt noiota pisteitä voisi mahdollisesti myös interpoloida.

[-:)lauri]

Sitten olisi ajatus kokeilla evoluutioalgoritmia, josko jo pelkästään se riittäisi opettamaan tietokonetta ajamaan rata läpi ilman, että se törmäisi seinään.

Tämä edellyttää nyt ainakin että:
- auto pystyy mittaamaan etäisyytensä seinään
- auto pystyy perimään voimavektorin, joka määrää auton liikkeen suunnan suhteessa tuohon etäisyyteen.

Pitäisi vaan keksiä, miten tuon käytännössä toteuttaa. Ideaalitilanteessa suhtautuminen olisi portaaton. Eli mitä lähempänä seinää ollaan, sitä päinvastaisemmaksi suhteessa seinän normaaliin voimavektorin on muututtava ja taas toisin päin, jotta voimat, jotka ajavat autoa radalla eteenpäin vaikuttaisivat, sitä kauempana seinien etäisyyden aiheuttama voimavektori saa vaikuttaa.

Eli mikä tai mitkä olisi tässä se periytyvä komponentti? Monissa internetin evoluutioalgoritmiesimerkeissä, joissa liikkuminen on jonkun evoluutio-objektin perityvä ominaisuus, peritään kylmästi vain vakiokokoinen voimavektori, mutta voiko se olla vakio myös tässä tapauksessa? Jotenkin ajattelisi että sen voimakkuuden pitäisi elää sitä mukaan, mitä lähempänä tai kauempana seinästä ollaan.

Luonnonvalinnan perusteella kelpoisin auto voisi olla sellainen, jonka kulkema matka lyhimmässä ajassa on suurin eli nopeus olisi suurin, eli sellaisten yksilöiden jälkeläisiä syntyisi eniten. Toisin ei varmaan ihan tällä selviä, sillä nopeasti seinään ajavat olisivat tällä perusteella myös kelpoisia, mitä emme luonnollisesti halua.

Mulla on algoritmi kasassa täällä: https://editor.p5js.org/lazydistribution/sketches/dRyjs1clO. Nyt tuo ratkoo nk. Knapsack-ongelmaa. Knapsack-ongelma on lasekennallisesti NP-ongelma, eli ongelma, jossa kaikkien ratkaisujen järjestelmällinen läpikäyminen on usein mahdotonta, ja jossa siksi oppiva systeemi todennäköisesti löyttää parhaimman kombinaation nopeammin. Mutta kyseinen koodi on taivutettavissa muidenkin ongelmien evolutiiviseen ratkomiseen. Evoluutioalgoritmi on pääpiirteiltään seuraava:

Koodi [Valitse] Laajenna


1: list of solutions. In this example they can be either 1 or 0

2. function to generate new population

3: fitness function to evaluate results

4: selection function to select next generation to generated

5: crossover function

6: mutation function

[-:)lauri]

^
jos tossa perityviä tekijöitä olisi kaksi. Ensimmäinen kokonaisuus koskisi randomeita voimavektoreita ja toinen kokonaisuus, mille indeksille osuvaa voimavektoria milloinkin käytetään riippuen etäisyydestä seinään.

Ei kun tekoäly. Mikä tekoäly löytää fiksuimman tavan suhtatua seiniin ja eteenpäin kuljettuun matkaan on kelpoisin. Eli kyllä tämä edellyttää tekoälyn luomista. Tuo aiempi olisi karvalakkiversio tästä koska siinä arvot ovat muuttumattomia. Tekoäly voisi ehkä päätellä tarvittavat voimavektorit itsenäisesti. Tosin en ole varma onnistuuko tämä. Pitäisi olla itseoppiva tekoäly. Tähän asti olen tutustunut vasta opetettavan tekoälyn algoritmeihin.

[-:)lauri]

Googlella on tarjolla ainakin Colaboratory Notebooks -lisäosa Google driven kylkeen pyyttonia varten, jossa pääsee ilmatteeksi käyttämään ainakin jonkun verran Googlen GPU tai TPU laskentatehoa.

[-:)lauri]

...
Keijon sivusto on viime vuodet ollut Googlen käyttöön tarjoamassa kotisivutekniikassa. Googlen oman informaationsa julkaisemiseen hankkima kotisivutekniikka on yrityspuolelle käytettävissä nimellä G Suite ja henkilöpuolelle Google Sivustot (Google Sites). ...

Google vaihtelee kaiken aikaa palveluidensa nimiä. Nyt G Suiten nimeksi on vaihtumassa  Google Work Space. Kumpikaan ei ole pelkkä sivustotekniikka vaan maksullinen kokoelma Googlen palveluita - joista Sivustot on yksi - jotka ovat suppeampina tarjolla ilmaiseksi myös kuluttajille

Oletko tutustunut githubin tarjoamaan ilmaiseen verkkosivu-vaihtoehtoon? Osoite on siellä muotoa: username.github.io

Github on tarttunut mulla mukaan sen vuoksi, että työn puolesta meillä on gitissä vesionhallinta. Vaikka meillä ei ole työnpuolesta sivuja githubissa hostattuina, sen kuitenkin saa myös hostaamaan ja ainakin yhden ilmaisen verkko-osoitteen per käyttäjä.

[Jaska]

Keijon sivuja ajatellen Googlen sivustojen tekniikanvaihdossa riesana on
- tekniikanvaihdon oleellinen pyrkimys oli tehdä sivuja jotka mukautuvat eri laitteille. Esimerkiksi isoa määrää leveitä sanataulukoita ei helposti saa kännykän ruudulla katsottavaksi. Koko taulukon tukikin on poistettu uudesta tekniikasta
- ulkoasun mahdollisuuksia on karsittu rajusti joten Googlen muunnos ei edes voi tuottaa entisen näköistä sivustoa
- käytännössä tarvittaisiin hyvä webbisivujen rakentamisen osaaminen html:llä vaikka se ollaan piilottavinaan (minulla ei kehuttava)
- javaskriptiä voi periaattteessa upottaa sivuihin frameissa, mutta en ole onnistunut. Framessa ei nähdä sivussa kehyksen ulkopuolelle
- sivun rakentaminen on aikamoista "yritä ja epäonnistu" puuhaa, kun sivunrakennuskone ei toimi virheettä
- minulla on niukasti aikaa tuohon askarointiin enkä ole motivoitunutkaan Google Siteen perehtymiseen. Dokumentointi ja ohjeistus lähinnä puuttuu
- toiseen tekniikkaan vaihto ei myöskään kiinnosta. Tämä on ollut ihan harrastelua vain

[-:)lauri]

Tarjoaako muuten noi Googlen sivustot myös tietokannan?

En ole tutustunut Githubin spekseihin riittävän hyvin tietääkseni, tarjoavatko ne, mutta mikäli olen oiken ymmärtänyt, Github ei ylläpidä tietokantaratkaisuja. Sivusto kun on ylipäätään rakentunut versionhallinnan ympärille ja kun sivun houstaus on sekin vasta varsin tuore lisä en näe tietokantaratkaisujen oikein palvelevan alkuperäistä ideaa. Mutta kuten todettu, en tiedä mikä Githubilla on asiassa politiikka.

[Jaska]

Tarjoaako muuten noi Googlen sivustot myös tietokannan?

Ehei, ei mitään niin konstikasta. Sivu koostuu otsikko-osasta ja osastoista, joissa on kuvia ja tekstejä. Fontti- ja värivalikoima on minimaalinen. Voidaan upottaa kehyksiä. joihin  tehdään HTML:llä konstikkaampaa sisältöä. Systeemi tekee sivusta omat esitysmuodot tietokoneelle, tabletille ja puhelimelle.

[-:)lauri]

Mulla on tässä joku ~50 Mbps -nettiliittymä. Haluaisin gigan nettiliittymän. Taloyhtiön kaapelia pitkin vaikuttaisi olevan tilattavissa kuitenkin vain max 300 Mbps. Kannattaako hommata gigan mobiililiittymä ja siihen sopiva mobiilireititin? Onko tuollainen gigan mobiiliyhteys kuinka hyvä sijoitus vai kannattaako idea kuopata alkuunsa?

Kolmas päivä kun olen ladannut ilmaisia soitinääniä. Noita on ollut useampi giga. Nyt olisi ollut nopeammasta nettiliittymästä hyötyä. Latausnopeus mulla on - kun kuuntelen samalla musiikkia ja surffailen somessa - joku 30-34 Mbps. Tietenkään yksittäistä pakettia harvoin saa ladattua muutenkaan nopeammin kuin ehkä korkeintaan sen 4-5 Mbps, mutta kun kovin montaa pakettia ei voi samanaikaisesti laittaa lataukseen mun kaistaleveydellä, ettei mene netiyhteys täysin tilttiin.

Tosin noita ääniä on nyt ensinnäkin ihan perkeleesti ja toisekseen samantyyppisiä ääniä löytyy ties minkälaisiin kansiorakenteisiin jemmattuina.

Ainakin osa äänitiedostojen nimistä sisältää soittimen nimen, että ehkäpä jonkinlainen ohjelma olisi mahdollista kirjoittaa, joka keräisi ja sijoittaisi noiden soittimien nimien perusteella äänet omiin kansioihinsa.

Koska en tunne kaikkia alan termejä, pitäisi varmaan ensiksi kirjoittaa ohjelma, joka luokittelee samanlaisen kirjoitusasun perusteella äänitiedostot ryhmiksi. Näin minun ei tarvitsisi opiskella kaikkia alan termejä itse ainakaan vielä tässä vaiheessa musiikkiharrastustani.

Tuo luokitteluohjelma on kyllä tällä hetkellä minulle liian vaikea taski repästä stetsonistani. Löytyiköhän jokin tuollainen luokittelualgoritmi jostain valmiiksi, jonka voisi kopioida omalle koneelle, jotta ei tarvitsisi tuhlata niin paljon aikaa asiaan?

Toisaalta tämä olisi kyllä oiva paikka harjoitella luokittelutekoälysovelluksen kirjoittamista. En kuitenkaan ole tekoälyopinnoissani niissäkään vielä niin pitkällä, että tällaiset luokittelualgoritmit olisivat tulleet käsitellyiksi. Mutta mulla on kyllä käsittääkseni ostettu Udemystä yksi tekoälykurssi, jonka aikana uskoakseni käydään luokittelualgoritmi(t) läpi. Tai jos ei löydy kyseisestä kurssismateriaalista, ei se kamalan kallista (yleensä) ole ostaa kurssia Udemystä, jossa asia käydään läpi.

Jos otan tästä itselleni tekoäly-taskin nyt, ja jos algoritmin kirjoittaminen/tekoälyn opettaminen ei käy käden käänteessä, musan tekemisen harjoittelu siirtyy hamaan tulevaisuuteen. Kaiken rehellisyyden nimissä tilanne on kuitenkin se, että käytännössä musiikin tekemisesssä pitäisi opetella noiden virtuaalisoittimien käyttö, jotta ei olisi riippuvainen näistä valmiista soittimien äänistä. Mulla on muutenkin ideoita päässä, miltä kappale tai jotkin sen äänet voisivat kuulostaa, mutta kun ei löydy prikulleen oikelanlaisia ääniä tai efektejä näistä valmiskirjastoista. Tai oikeamamin vaikka löytyisikin, mistä vitusta noviisi pelkän randomin tiedostonimen perusteella tietäisi, että kappas' tätä olenkin etsinyt. Että ennemmin tai myöhemmin on ryhdyttävä joka tapauksessa opetteleman noiden virtuasalisoittimien käyttöä ihan tosissaan, sikäli jos musiikkiharrastukselle haluaa tulevaisuuden.

Mutta tämä luokittelualgoritmi olisi kyllä ihan mielenkiintoinen haaste. Extrana voisi sitten joskus kirjoittaa luokitteluohjelman, joka kävisi tiedostojen musiikkidatan läpi ja luokittelisi tiedostot äänen tyylin perusteella omiin ryhmiinsä. Sellainen luokittelutapa olisi siis se ideaali tässä. Mutta koska laskentatehoa taikka taitoja ei ole riittävästi, äänidatan analysointiin kykenevä tekoäly jää tällä erää tulevaisuuden haasteeksi.

Tai hetkinen, ehkäpä löytyy joku kaupallinen palvelu jostain, joka tarjoaisi tällaisen äänen tyylilajin perusteella tapahtuvan luokittelun kohtuuhintaan? Toi löytyyköhän sittenkään? Muistelen nimittäin, että varsinkin jos äänitiedosto on pitkä, laskentateho ei yksinkertaisesti vielä nykymaailmassa riitä millään tietokoneella tekoälyn harjaannuttamiseksi tehtävään. Sama ongelma tekstin analysoinnin kanssa; onelinerit on helppo luokitella, mutta twiitti alkaa jo olla siinä rajoilla, että onnistuuko luokittelu enää. Tosin nää soittimien äänet ovat muutaman sekunnin pätkiä korkeintaan, että näihin saattaisi jonkun tehokkaan koneen laskentateho jo nykyään riittääkin.

[-:)lauri]

^

https://moises.ai/ periaatteessa tekee tuon tai ainakin jonkinlaisen luokittelun ja ainakin normisoittimien osalta. Pitäisi vaan saada käyttöön versio, jolle syötetään yhden äänitiedoston - jossa kaikki äänet sekaisin - sijaan lukuisia ääniä omissa tiedostoissaan takaisin ja ohjelma kertoisi, mikä äänitiedosto sisältää minkäkin instrumentin/äänen.

[-:)lauri]

^
tässä on ainakin lupaava otsikko: Sound Classification with TensorFlow (Tensorflow on googlen käyttämä tekoälykirjasto, joka on tekoälykirjastoista yksi suosituimmista)