Ohjelmointi

[ROOSTER]

Minulla tahtoo mennä hermot kun välillä joutuu ohjelmoimaan hellan kellon.

Lieden kellon säätäminen taas on itse perkeleestä, joten olen tyytynyt siihen, että se on puoli vuotta kerrallaan ympäröivän maailman kanssa samassa ajassa ja sitten taas puolivuotta aika heittää tunnilla johonkin suuntaan, jota nyt en muista. Teen joka ilta polvirukouksia, ettei tule sähkökatkoa, että veisi kellon nollille. On aivan sietämätöntä joutua klikuttelemaan ja yhtä aikaa painelemaan jotain pieniä napukoita, jotta saa numerot kellossa vaihtumaan, etenkin kun käyttöohjeessa ohje on väärin.

Me ollaan tässäkin samiksia. Luultavasti meillä on myös samanmerkkinen hella.   

[a4]

Jos tekee evoluutioalgoritmin pohjalta oppivan tekoälyn, mitkä olisivat hyviä ehdokkaita perintötekijöiksi? Tekoälyn painokertoimet ennen opettelua?

Bing:

Evoluutioalgoritmin pohjalta oppiva tekoäly voi olla hyödyllinen monissa sovelluksissa. Perintötekijät voivat olla esimerkiksi painokertoimia, jotka määrittävät, kuinka paljon kunkin ominaisuuden tulisi vaikuttaa tekoälyn päätöksentekoon. Ennen opettelua painokertoimet voidaan asettaa satunnaisesti tai valita järkevillä oletusarvoilla. Painokertoimien arvot voivat myös muuttua oppimisen aikana, kun tekoäly pyrkii optimoimaan suorituskykyään 1.

On tärkeää huomata, että tekoälyn kehittäminen on monimutkaista ja vaatii huolellista suunnittelua ja testausta. Eettiset kysymykset, kuten tekoälyn etiikka ja algoritmien oikeudenmukaisuus, ovat myös tärkeitä ottaa huomioon 2.

Toivottavasti tämä vastaus auttaa sinua! Kerro minulle, jos voin auttaa sinua jollain muulla tavalla.

ChatGPT:

Evoluutioalgoritmin pohjalta oppivan tekoälyn suunnittelu vaatii tarkkaa harkintaa perintötekijöiden ja alkuperäisten painokertoimien valinnassa. Tässä on muutamia seikkoja, jotka kannattaa ottaa huomioon:

Alkuperäiset painokertoimet: Alkuperäiset painokertoimet voidaan asettaa satunnaisesti tai käyttää jotakin lähtökohtaa, joka liittyy tekoälyn tavoitteisiin. Alkuperäiset painokertoimet voivat vaikuttaa suuresti siihen, kuinka nopeasti ja kuinka hyvin tekoäly oppii, joten niiden valintaan kannattaa panostaa.

Yksilölliset piirteet: Evoluutioalgoritmin avulla voit mukauttaa tekoälyn yksilöllisiä piirteitä. Voit harkita, mitkä tekijät ovat tärkeitä tekoälyn suorituskyvylle ja asettaa niille korkeammat alkuperäiset painokertoimet.

Risteytys ja mutaatio: Evoluutioalgoritmissa risteytyksen ja mutaation avulla luodaan uusia yksilöitä. Voit harkita, miten nämä operaatiot vaikuttavat painokertoimiin. Esimerkiksi voit lisätä mutaation todennäköisyyksiä painokertoimille, jotka ovat epäsuotuisia suorituskyvyn kannalta.

Kohdefunktion määrittely: Sinun on määriteltävä kohdefunktio, joka arvioi tekoälyn suorituskykyä. Tämä voi olla esimerkiksi ennusteen virhe tai muu tavoitearvo, joka halutaan minimoida tai maksimoida. Kohdefunktion määrittely vaikuttaa siihen, miten evoluutioalgoritmi arvioi yksilöiden soveltuvuutta.

Sukupolvien määrä ja koko: Määritä, kuinka monta sukupolvea evoluutioalgoritmi suorittaa ja kuinka monta yksilöä kussakin sukupolvessa on. Liian pieni sukupolvien määrä tai yksilöiden määrä voi hidastaa oppimisprosessia, kun taas liian suuri voi vaatia paljon laskentaresursseja.

Risteytysstrategia: Valitse risteytysstrategia, kuten yhden pisteen risteytys tai tasapainottava risteytys, joka sopii ongelmaan ja yksilöiden representaatioon.

Valintamenetelmä: Päätä, miten valitset yksilöt seuraavaan sukupolveen. Voit käyttää esimerkiksi turnajaisvalintaa, rulettipyörävalintaa tai muita menetelmiä.

Evoluutioalgoritmin parametrit: Säädä evoluutioalgoritmin parametreja, kuten risteytyksen ja mutaation todennäköisyyksiä, sukupolvien määrää ja muita hyperparametreja, kokeilujen perusteella.

On tärkeää huomata, että evoluutioalgoritmin tehokkuus voi vaihdella suuresti ongelman luonteen ja tavoiteltavan suorituskyvyn perusteella. Siksi on suositeltavaa suorittaa kokeita erilaisilla asetuksilla ja hyperparametreilla löytääksesi parhaan mahdollisen kokoonpanon tekoälyn oppimista varten. Evoluutioalgoritmiin perustuva oppiminen vaatii usein paljon resursseja ja aikaa, joten kärsivällisyys ja jatkuva optimointi ovat avainasemassa.

[a4]

^
Ajatus oli tuo, että painokertointen ollessa perintötekijöitä osa niistä mutatoituu seurraavalle sukupolvelle, mikäli mutaatio on hyödyllinen tai ainakaan se ei haittaa. Pikkuhiljaa ympäristössä oikein toimiminen pitäisi parantua, kunhan mutaatiot eivät ole liian suuria.

Tämä sai itseni pohtimaan ajattelun ja evoluution samankaltaisuuksia.

Ajattelu simuloi tapahtumaketjuja joissa tapahtuu toimivuuteen perustuvaa valintaa.
Ajattelussa tapahtuu muutoksia ja ne voivat säilyä muistissa.
Muisti tallentaa ja tuottaa ajattelua.
Ajattelu on jatkuvassa vuorovaikutuksessa aistiympäristön kanssa.
Ajattelu saa ajatuksia toisten ajattelusta.

Siksi kai evoluutiota on sanottu sokeaksi kellosepäksi tai muurahaisia parviälykkäiksi.
Tai toisin sanoin ihmisaivot ovat vain evoluution kautta rakentunutta itsetietoisuuteen yltävää solujen parviälykkyyttä. 
Samoin evoluutioalgoritmeilla ja neuroverkkojen ajattelulla voidaan rakentaa itsetietoisuuteen yltävää koneellista ja algoritmista parviälyä.

[Hippi]

Minulla tahtoo mennä hermot kun välillä joutuu ohjelmoimaan hellan kellon.

Lieden kellon säätäminen taas on itse perkeleestä, joten olen tyytynyt siihen, että se on puoli vuotta kerrallaan ympäröivän maailman kanssa samassa ajassa ja sitten taas puolivuotta aika heittää tunnilla johonkin suuntaan, jota nyt en muista. Teen joka ilta polvirukouksia, ettei tule sähkökatkoa, että veisi kellon nollille. On aivan sietämätöntä joutua klikuttelemaan ja yhtä aikaa painelemaan jotain pieniä napukoita, jotta saa numerot kellossa vaihtumaan, etenkin kun käyttöohjeessa ohje on väärin.

Me ollaan tässäkin samiksia. Luultavasti meillä on myös samanmerkkinen hella.   

Niin taitaa olla monella muullakin

[ROOSTER]

^
Lapsuudessani meillä oli kotona SLEV-merkkinen sähköliesi. Taisi silloin olla kaikilla muillakin, elettiinhän yhtenäiskulttuurin kulta-aikaa. Jos SLEV -keittiönkiukaita vielä valmistettaisiin, niissä tuskin olisi nykyisenkaltaista, vaikeasti ohjelmoitavaa kelloa. Tai ei se oikeasti ole vaikea, pitää vain hoksata logiikka...Toisaalta, hellan käytön ei pitäisi olla asia joka vaatii keskittynyttä miettimistä ja logiikan peruskurssia.

Tuo SLEV on lyhenne sanoista Sähkö-Lämpö-Elektro-Värme ja yhtiön perusti Erik Isomaa 1939.

Isomaan vanhemmat olivat konepajatyöläinen Immanuel Isomaa ja Ida Nikonen. Kolmetoistalapsinen perhe muutti 1918 Pietarsaareen. Isän kuoltua 1923 Isomaa joutui jättämään koulun kesken. Hän meni töihin Junnilan sähköasennusliikkeeseen 13-vuotiaana, missä tutustui myös sähkökojeiden ja laitteiden valmistukseen. Strengbergin tupakkatehtaassa työskennellessään hän hankki kirjekurssien avulla lisätietoja tekniikasta ja toimi vapaa-aikanaan radioasemalla lähestystekniikan hoitajana.

Tuo 13-vuotiaana töihin meno ei ole ehkä niin rankkaa mitä nykyihminen helposti ajattelee. Minäkin menin reippaasti duuniin (vakituiseen koko- ja jokapäivätyöhön) jo 14-vuotiaana keskikoulun jälkeen (sen jälkeen alkoi opiskelu innostaa enemmän). Silloin työtehtävät olivat helpompia oppia, eikä tahti ollut nykypäivän luokkaa. Vaihtoehtoisia töitä oli tarjolla, joten siksikin hyvistä ihmisistä yritettiin pitää kiinni. Kulttuuri oli erilainen, mitähän nykyään sanottaisiin kun 14-vuotias maalari saapuisi sutimaan makuuhuonetta uuteen kuosiin, yksin.

[-:)lauri]

Olen kipuillut laravelin Pool-luokan kanssa ja vasta nyt keksin kysellä ChatGPT:ltä olisiko rinnakkaisten http-pyyntöjen tekemiselle Laravelissa järkeviä vaihtoehtoja. ChatGPT ohjasi laracast-palstan keskusteluun, jossa oli linkki videoon


https://www.youtube.com/watch?v=IJXzc46MFPM

jossa esiteltiin jotain tällaista kirjastoja, joka mahdollistaa asian.

Ennen kuin videolla päästiin kyseisen kirjaston esittelyyn, siinä esiteltiin alkuun muita vastaavia kirjastoja. Kuinka ollakaan, yksi tällainen kirjasto on ilmeisesti Guzzle. Sikäli hassua, että laravelin http-client on rakennettu guzzlen ympärille, eika ChatGPT osannut ottaa asiaa esille, kun kyselin vaihtoehtoja Pool-luokalle.

Haasteena on mulla ollut, miten käsitellä 429 virheet ja 401 virheet kun suoritetaan rinnakkaisia ajoja. 429 virhetyyppi edellyttää mahdollisesti useampia uusintapyyntöjä ja 401 virhe yhtä uusintapyyntöä.

Näiden haasteiden ratkaiseminen php:llä on monimutkaista. Tai siis vain sikäli monimutkaista, että kun olen tuota koodia pyörtiellyt muutaman päivän Pool-luokkaa käyttäen, en saa siitä sellaista, että koodin kulkua olisi vaivatonta seurata, ja tämä jos mikä, on hyvä indikaattori sille, että kummallisia virheilmoituksia on luvassa.

Guzzle kuitenkin näyttäisi tarjoavan mahdollisuuden hoitaa 429 virheet middlewaressaan:

Koodi [Valitse] Laajenna

<?php declare(strict_types=1);
require 'vendor/autoload.php';

use Psr\Http\Message\{RequestInterface, ResponseInterface};
use GuzzleHttp\{Client, HandlerStack, Middleware, RetryMiddleware};

$maxRetries = 3;

$decider = function(int $retries, RequestInterface $request, ResponseInterface $response = null) use ($maxRetries) : bool {
    return 
        $retries < $maxRetries
        && null !== $response 
        && 429 === $response->getStatusCode();
};

$delay = function(int $retries, ResponseInterface $response) : int {
    if (!$response->hasHeader('Retry-After')) {
        return RetryMiddleware::exponentialDelay($retries);
    }

    $retryAfter = $response->getHeaderLine('Retry-After');

    if (!is_numeric($retryAfter)) {
        $retryAfter = (new DateTime($retryAfter))->getTimestamp() - time();
    }

    return (int) $retryAfter * 1000;
};

$stack = HandlerStack::create();
$stack->push(Middleware::retry($decider, $delay));

$client = new Client(['handler'  => $stack]);
Ja guzzle mahdollistaa rinnakkaisajot näin:

Koodi [Valitse] Laajenna

<?php
use GuzzleHttp\Client;
use GuzzleHttp\Promise;

$client = new Client(['base_uri' => 'http://httpbin.org/']);

// Initiate each request but do not block
$promises = [
    'image' => $client->getAsync('/image'),
    'png'   => $client->getAsync('/image/png'),
    'jpeg'  => $client->getAsync('/image/jpeg'),
    'webp'  => $client->getAsync('/image/webp')
];

// Wait on all of the requests to complete. Throws a ConnectException
// if any of the requests fail
$results = Promise\unwrap($promises);

// Wait for the requests to complete, even if some of them fail
$results = Promise\settle($promises)->wait();

// You can access each result using the key provided to the unwrap
// function.
echo $results['image']['value']->getHeader('Content-Length')[0]
echo $results['png']['value']->getHeader('Content-Length')[0]
Ja käyttäen yhtä ja samaa Client objektia näyttäisi homma tältä:

Koodi [Valitse] Laajenna

<?php
// [... 429 virheen käsittelystä vastaava koodi ...]
$client = new Client([
    'base_uri' => 'http://httpbin.org/',
    'handler'  => $stack
]);
// [... rinnakkaisista ajoista vastaava koodi ...]

Tällä konfiguraatiolla enää tarvitsisi minun huolehtia php:llä vain 401 virheen käsittelystä ja guzzle hoitaisi 429 virheen käsittelyn. Homma muuttui kertaheitolla kertaluokkaa paria helpommaksi.

Pitää yrittää vielä etsiä ratkaisua, jossa myös tuo 401 virhe voitaisiin käsitellä Guzzlen $stack-objetissa tai vastaavalla Clientille annattevan config objektin määrittelyllä. ChatGPT 4 ei selvästi osaa oikein auttaa. Hakee vastauksia kysymyksiini jatkuvasti Bingiltä. Ellen osaa kysyä oikeita kysymyksiä ei ChatGPT osaa kysyä Bingiltä oikein.

Nyt kun osasin kysyä suoraan ChatGPT:ltä, miten tokenin vanhentumisesta aiheutunut 401-virhe hoidetaan middlewaressa sieltä se tuli kuin apteekin hyllyltä:

Koodi [Valitse] Laajenna

<?php

use GuzzleHttp\Exception\RequestException;
use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ResponseInterface;
use GuzzleHttp\Middleware;

// Oletetaan, että meillä on funktio, joka hakee uuden tokenin
function getNewToken() {
    // Logiikka uuden tokenin hankkimiseksi
}

$middleware = Middleware::retry(function($retries, RequestInterface $request, ResponseInterface $response = null, RequestException $exception = null) {
    // Tarkistetaan, onko vastaus 401 Unauthorized
    if ($response && $response->getStatusCode() === 401) {
        // Logiikka uuden tokenin hankkimiseksi ja requestin uudelleenasettamiseksi
        $newToken = getNewToken();
        // Asetetaan uusi token pyynnön Authorization-headeriin
        return $request->withHeader('Authorization', 'Bearer ' . $newToken);
    }

    return false; // Ei uudelleenyritystä, jos ei ole 401-virhe
});

$stack = HandlerStack::create();
$stack->push($middleware);

$client = new Client(['handler' => $stack]);

// Tee pyyntöjä Guzzle-clientillä...

ja vielä kun kysyin voiko nuo hoitaa kahdessa erillisessä middlewaressa, jotka molemmat laitetaan stack-objektiin push-komennolla? Niin kyllä se ChatGPT:n mukaan onnistuu.

Neljä päivää pähkäillyt, kuinka hoitaa nuo normaalit virhetilanteet niin kuin ne olisi järkevintä hoitaa, ja nyt vasta selvisi, että miten. Kaiketi olisin voinut kysellä joltain työkaverilta, mutta omilla harrasteluprojekteilla ei oikein kehtaa vaivata työkavereita.

[-:)lauri]

On tuossa kyllä pari mahdollista virhetilannetta mitä tämäkin ratakasisu aiheuttaa. Koska nuo ajot ovat rinnakkaisia niin ajot eivät tiedä toisten ajohen statuksesta mitään ja jos ajot eivät toimi yhtä noipeasti 429 virheiden hoitaminen ei onnistu optimaallisesti. samoin jos yksi joutuu päivittämään tokenin niin mahdollisesti kaikki joutuu sen päivittämään. Tosin kun yksi on jo uusinut tokenin muiden ei tarvitsisi uusia sitä. Tokenin uusimisen voi vielä hallita helposti, mutta 429-onglema on tosiaan se, että serveri palauttaa Retry-After arvona eri lukuja riippuen siitä kuinka kauan yksi ajo kestää ja se ajo joka kestää pisimpään, antaa sen oikean retry arvon. Jos nopein ajo jo odottaa se odottaa liian vähän aikaa.

Ettei vaan pitäisi sittenkin vain käyttää Pool-luokkaa, kun kerran olisi optimaallista että 429 virheen sattuessa odotettaisiin niin kauan kuin on suurin Retry-After arvo sanoo ja ei tarvitsisi kuin luoda kertaalleen uusi token jos edes yksi palautusarvoista on ollut 401... Kylläpä tämä on pulmallista.

[-:)lauri]

Opin juuri, miten Laravelin service providerissa korvataan injektoitu interface oikealla luokalla. Nyt on sitten oma projekti täynnä ratkaisuja

[-:)lauri]

Tietäkö joku, onko keinoa VS Codessa estää Github Copilottia lukemasta projektien ympäristömuuttujatiedostoja?

Omalla koneellani käytän kaikkia mahdollisia VS Coden -tekoälylaajennoksia surutta mutta firman koneella ja siten firman VS Codessa en ole käyttänyt tekoälylaajennoksia. Olen käyttänyt ChatGPT:tä selaimessa ja kysellyt neuvoa sitä kautta, joten se tapa estää tekoälyä pääsemästä käsiksi autentikointitietoihin.

Ilmeisesti voisi kuitenkin olla mahdollista laittaa laajennokset myös suoraan VS Code -koodieditorissa firman konella. Joku kysyi tietoturvaosastolta asiaa, niin kuulemma vasta testailevat tällaisia apureita, mutta että ilmeisesti kunhan noudataa firman tietoturvaohjeistusta, niin voisi käyttää.

Mulla ei ole firmankaan VS Codessa sellaisia asetuksia, että voisin käyttää firman repoja kirjautumatta joka kerta erikseen sisään, joten tuskinpa Github Copilotkaan pääsisi koneeltani käsiksi kaikken arkaluonteisimpiin materiaaleihin, poislukien projekteissani olevat ympäristömuuttujatiedostot.

Vaika noissakaan ympäristömuuttujatiedostoissa ei ole varsineisesti arkaluonteista tietoa, niin niilläkin tiedoilla saa firman yhteiset verkon yli tarjolla olevat testaysympäristöt sekaisin. Ainakin palvelimella olevien projektien, joita kehitän, testausympäristöjen tietokannat voi tyhjentää. Joten ennen kuin uskallan laittaa firman koneeseen noita laajennoksia, olisi hyvä, jos voisi jotenkin määritellä tiedostot, joita Github Copilot ei voi lukea.

[-:)lauri]

ChatGPT ehdottaa, että tekisin PowerShell-skriptin, joka ajaa ympäristömuutujat Windowsin ympäristömuuttujiksi ja toisen skriptin, joka poistaa ne sieltä. Tallentaisin ne projektikansion ulkopuilelle enkä avaisi niitä koodieditorissa, jossa tekoälyapurieita sillä hetkellä päällä.

Eli noiden tekolyapureiden käyttämisen hintana tulisi ehkä tällaisia lisärutiineita.

[-:)lauri]

Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?

[Lenny]

Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?

Tokihan tuo on mahdollista molemmissa luomalla tiedosto, jossa asetetaan "Muuttuja=arvo" ja sitten ajetaan sisään komentoriviltä tarpeen mukaan. Muuttujat ovat sitten voimassa siinä konsolisessiossa josta ne on ajettu. En näe mitään eroa Windowsin ja Linuxin välillä tässä asiassa.

[Hayabusa]

Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?

Tokihan tuo on mahdollista molemmissa luomalla tiedosto, jossa asetetaan "Muuttuja=arvo" ja sitten ajetaan sisään komentoriviltä tarpeen mukaan. Muuttujat ovat sitten voimassa siinä konsolisessiossa josta ne on ajettu. En näe mitään eroa Windowsin ja Linuxin välillä tässä asiassa.

Mietin tätä käydessäni pyyttonilla.

Asiattomuuden jälkeen komppaan asiallisesti Lennyä. Ei noissa pitäisi olla käytännössä mitään eroa. Oletan, että Laurin sovellus pyörii sovelluskerroksessa ja ehkä kutsuu jotain käyttöjärjestelmätason palveluja tarvittaessa. Jälkimmäistä vartenhan ovat asennuksessa paikoilleen pistetyt ympäristökirjastot. Pythonkin on jo niin monennessa versiossa, että aika spesiaalitapaus saa olla, että ei toimisi win/lin vaikka toisessa toimii.

[Lenny]

Guzzle kuitenkin näyttäisi tarjoavan mahdollisuuden hoitaa 429 virheet middlewaressaan

Kysymys liittyen näihin koodiblokkeihin: miten teit nuo? Ihmettelen nimittäin mistä nuo fontin värit tulevat. Tässä tummassa teemassa on pakko pitää valkoista (tai hyvin vaaleaa) tausta blokissa, koska muuten nämä nimeomaiset värit menevät puuroksi. Valkoinen tausta taas sattuu päähän muuten tummassa teemassa.

Onko värit siis bb-koodilla laitettu?

[-:)lauri]

Guzzle kuitenkin näyttäisi tarjoavan mahdollisuuden hoitaa 429 virheet middlewaressaan

Kysymys liittyen näihin koodiblokkeihin: miten teit nuo? Ihmettelen nimittäin mistä nuo fontin värit tulevat. Tässä tummassa teemassa on pakko pitää valkoista (tai hyvin vaaleaa) tausta blokissa, koska muuten nämä nimeomaiset värit menevät puuroksi. Valkoinen tausta taas sattuu päähän muuten tummassa teemassa.

Onko värit siis bb-koodilla laitettu?

En minä värejä laittanut tarkoituksella, mutta kun laittaa koodi-blokin alkuun php-avaustägin "<?php" se näyttäisi värittävän koodin.

Koodi [Valitse] Laajenna

<?php

function jepa() {

}

Koodi [Valitse] Laajenna


function jepa() {

}