Tee ohjelma, joka tulostaa mahdollisimman vähillä iteraatioilla kaikki kellonajat, jotka ovat numeroiden perusteella samat päinvastoin esitettynä muodossa:
TT:MM:SS
jossa TT tarkoittaa tunteja (0-23), MM minuutteja (0-59) ja SS sekunteja (0-59).
Lisähaaste on, että tunneissa ei tarvitse käyttää etunollia käänteisenäkään kuten minuuteissa ja sekunneissa.
Esimerkki:
- puoliyö 0:00:00 -> päinvastoin 0:00:00
- keskipäivä 12:00:00 -> päinvastoin 0:00:12
TT:MM:SS
jossa TT tarkoittaa tunteja (0-23), MM minuutteja (0-59) ja SS sekunteja (0-59).
Lisähaaste on, että tunneissa ei tarvitse käyttää etunollia käänteisenäkään kuten minuuteissa ja sekunneissa.
Esimerkki:
- puoliyö 0:00:00 -> päinvastoin 0:00:00
- keskipäivä 12:00:00 -> päinvastoin 0:00:12
Vastaukset 42
Vanhimmat
Siitä vaan koodaamaan...
Olisko jotain hyödyllisempää koodattavaa?
Aika hankala tuolla tavalla. Pitää ainakin ensin tsekata onko 5 vai 6 numeroa.
Ei välttämättä. Voi kattoa vain tuntiarvon. Jos on on alle 10, niin käsittelee viisinumeroisena, muutoin kuudella. Toinen tapa tietysti mennä merkkijonoilla. Splittaa vaan kaksoispisteiden kohdalta, ja jos ensimmäinen siivu on pituudeltaan 2, niin mukana on etunolla.
Kuuluu ehdottomasti, kuukauden 10 parasta aloitusta, ryhmään.
Tämä esimerkki etunollien kera, näin se helpompi jokaisen ymmärtää.
https://s6.gifyu.com/images/palindromi-date.bash----media-ramdisk---Geanyuusi-tapahtuma_001.png
En muistanut mainita että esimerkki on Bash Shell skripti, eikä lyhene vaikka muuttaisi python skriptiksi.
Ajatellaanpas ettei timestampin tarvitse olla validi, ja näin ollen muutetaan esimerkin rivi 14 tällaiseksi:
d1="$t:$m:$s"
Nyt timestampit jotka eivät muutu takaperin käännettäessäkään löytyy jo peräti 270 kpl ja aikaa menee (real 5m11,120s), joka on melkein puolet vähemmän.
Näpyttelin putkeen sen enempää ajattelematta javascriptillä käyttämällä silmukoita. Voi olla ettei ole oikein, mutta pikavilkaisulla näyttäisi olevan "sinne päin", ja yhteensä vaihtoehtoja 684 kpl.
https://pastebin.com/dDnUGkia
Tuo tuolostaa siis vaihtoehdot ja kokonaismäärän tyyliin
0:00:00
0:01:00
.
.
.
23:44:32
23:55:32
Yhteensä 684
Hyvähän se on, tuossa on siis yksittäiset luvut käännetty, kun minä tein tuon käänsin koko ajan yhtenä merkkijonona, ja siksi sain 10 kertaa vähemmän. Tuotahan siinä vissiin tarkoitettiin.
Tämä+oli+siis+hieman+väärin.+Jälkimmäiseen+tuntisilmukkaan+piti+lisätä+heti+alkuun
++if+(h+%+10+>+5)+continue;
joka+jätti+silmukan+lopun+suorittamatta,+kun+tuntiarvon+toinen+numero+on+yli+5.+Sekuntien+kymmenethän+eivät+voi+olla+kuin+00...59.
Tein+apufunktiot+aika-arvon+tarkastukselle,+joka+käyttää+Date-objektia+validointiin.+Tein+myös+käännösfunktion+aika-arvolle,+jonka+avulla+voidaan+tarkastaa+onko+H:mm:ss+muodossa+oleva+merkkijono+sama+myös+käännettynä,+eli+palindromiaika.
Lisäksi+tein+silmukan,+joka+samoja+apufunktioita+hyödyntäen+käy+läpi+kaikki+86 400+sekuntia.
Lopputulos+oli+molemmilla+tavoilla+660+erilaista+palindromiaikaa.
Koodi:+https://pastebin.com/6SWCqtVd
tapa1:
0:00:00
0:01:00
.
.
23:44:32
23:55:32
Yhteensä:+660+kelvolliset:+660+epäkelvot:+0+palindromeja:+660
tapa2:
0:00:00
0:01:00
.
.
23:44:32
23:55:32
Yhteensä:+86400+kelvolliset:+86400+epäkelvot:+0+palindromeja:+660
"Sekuntien kymmenethän eivät voi olla kuin 00...59."
Jaahans, taas sekoilua. Siis 0...5 piti kirjoittaa, mutta sormet halusivat julkaista kaikki mahdolliset sekunnit.
Lisää näitä!
Ajatellaanpa että tehtävä olisi ollut aito palindromi timestamppien poiminta tehtävä. Silloin olisi noussut seuraavat komennot merkitykselliseksi:
JavaScript
function reverse(s){
return s.split("").reverse().join("");
}
console.log( reverse("123") )
Bash Shell
echo "123" | rev
Python
print( "123"[::-1] )
Halusi nostaa nuo pöydälle siksi, että JavaScript ei sisällä suoraa komentoa merkkijonon kääntämiseen, vai mitä JavaScript taituri.
JavaScriptistä kieltämättä puuttuu tuollainen perustason funktio. Merkkijonon pilkkominen, kääntäminen ja yhdistäminen ei tosin ole ketjuttamisen ansiosta iso tehtävä.
Jopa C-kielen string.h -kirjastosta löytyy valmis strrev() -funktio kääntämiselle.
Tämä on juuri sellainen kompakysymystehtävä jonka tyyppinen voi tulla työhaastattelussakin esiin kun katsovat että pelääko kaverilla hoksottiment lainkaan vai ei, sillä tämä tehtävä vaatii enemmän loogista ajattelukykyä ja matemaattista taitoa kuin ohjelmointitaitoa.
Ensimmäisenä tulee huomioida, että aika on, tai sen kannattaa olla muodossa HH:MM:SS, niin hommasta tulee yksinkertaisempi, kun näin saadaan 6 numeroa, niin tiedetään siitä sitten jo että 2 keskimmäistä numeroa tulee aina olla samat, koska muuten palindromia ei muodostu lainkaan.
Ja kun tiedestään että 2 keskimmäistä numeroa tulee olla samat, niin saadaan numerovälillä 0-5 pyöräytettävä silmukka, joka kuvaa minuutteja.
Tämä minuuttisilmukka laitetaan tuntisilmukan sisään, ja käännetään tunnin arvo päinvastaiseen järjestykseen, ja jos arvo on pienempi kuin 60, niin sitten kyseessä on laillinen arvo, ja samalla myös aika:
#!/bin/bash
for t in {00..23}
do
for m in {0..5}
do
s=`echo $t | rev`
if [ $s -lt 60 ]
then
echo "$t:$m$m:$s"
fi
done
done
Jos haluaa käyttää muotoa H:MM:SS, eli vaikka aikaan 0:01:01, niin se saadaan tekemällä kolme sisäistä silmukkaa joilla iteroidaan tunnit 0-23, minuutit 00-59, ja sekunnit 00-59, jonka jälkeen niistä voi muodostaa yhtenäisen merkkijonon (string) muuttujaan a, että kääntää tämän merkkijonon käänteiseen järjestykseen merkkijonoon b, ja verrata näitä toisiinsa.
Jos vertailuoperaation tulos on tosi, niin kyseessä on palindromiaika, ja se voidaan tulostaa, mutta vain jos sekunti <= tunti, koska muuten kyseessä ei ole laillinen aika:
#!/bin/bash
for t in {0..23}
do
for m in {00..59}
do
for s in {00..59}
do
a=$( echo $t$m$s )
b=$( echo $a | rev )
if ([ "$a" == "$b" ] && [ $t -le $s ] )
then
echo "$t:$m:$s"
fi
done
done
done
Itse sain tällä jälkimmäisellä vain 642 palindromiaikaa kun edeltäjä sai javascriptillään 684, eli AP voi nyt selvittää että kumpi bugaa,,,
Noi koodit vielä nätimmin luettavassa / käytettävässä muodossa; https://pastebin.com/RfYH1ZrM
Minulla on siinä javascriptiräpellyksessä virhe, jossa kymmenet sekunnit karkaa yli vitosen. Tein tarkastusfunktion käyttämällä Date-kikkaretta. Nyt tippui 660:een. Pitää ensin korjata kyseinen virhe, ja sen jälkeen tehdä vielä palindromitarkastus.
16:00:61 ei kelvollinen
.
.
.
19:55:91 ei kelvollinen
Yhteensä 684 kelvolliset 660 epäkelvot 24
a,b = b,a :
Vaihtaa muuttujiin luetut päinvastaisiksi Pythonissa.
Ja eikös tuolla ylempänä ollut että kuinka se tehdään myös merkkijonolle:
Python
print( "123"[::-1] )
Enkä myöskään näe estettä tehdä se bashillä näin:
a=$( echo $t$m$s )
b=$( echo $a | rev ) #muutetaankin muotoon: b=$( echo $s$m$t )
En muista enää mutta eikös Pythonissa muuttujaan syötetty sisältö määrää sen muuttujan tyypin?
Näin on.
Yleensä skriptikielissä on näin. Muuttujaan vaan arvo, ei väliä onko string, integer, jne...
Kätevä toiminto. Miksiköhän esim c ei ole vastaavaa vaan ensin pitää esitellä muuttujat? Saattaa liityä siihen että Python on tulkkaava kieli?
C yms. kielissä muuttujien määrittely pitää tehdä syystä että sitten kääntäjä tietää että kuinka paljon tilaa (muistia) pitää muuttujalle varata, että kuinka sitä tullaan käsittelemään varsinaisessa lopullisessa käännetyssä binäärimuodon ajettavassa ohjelmassa.
Esim, skriptauskieli perl varaa aina käytännössä saman määrän muistia, riippumatta siitä että kuinka pieni ohjelma on kysessä, koska mm. siinä ei ole tällaista optiomointia lainkaan, koska sitä ei käännetä binääriksi, vaan sitä tulkataan koko ajan ohjelman edetessä...
Kiitos.
Tuossa tuleekin se heikkous esiin, kuten
===
Python 3.8.5 (default, Jan 27 2021, 15:41:15)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a=1;b=2;c="1";d="2"
>>> a b
3
>>> a c
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for : 'int' and 'str'
>>> c d
'12'
>>> int(c) int(d)
3
>>>
Mikä heikkous, ei int ja str muuttujaa voi laskea yhteen, ilman tarvittavia muutoksia.
En nyt kutsuisi tätä heikkoudeksi, koska muuttujalle c on selkeästi kerrottu että kyseessä ei ole numeerinen arvo, vaan että se tulee käsitellä merkkinä tai merkkijonona.
Muussa tapauksessa ei voisi käsitellä merkkijonoja lainkaan, sillä jos ajateltaisiin että annetaan muuttujalle c arvoksi Matti, eli c=Matti, niin virhe tulee koska/jos muuttujalle Matti ei ole määriteltu arvoa.... [Edellyttäen siis että python ei tulkitse arvotonta muuttujaa automaattisesti nollaksi, jolloin virhettä ei tietenkään tule, jolloin c saakin arvoksi 0, vain jos/koska Matti -muuttujaa ei ole määritelty...]
C -kielessä pelkkiä numeroita sisältävän merkkijonon voi muuttaa nmeerikseksi funktiokutsulla 'atoi' (ascii-to-integer) että päinvastoin 'itoa':lla...
Ohjelmointi on loogista, eikä mitään saivartelua...
Heikkous on siinä, ettei etukäteen voi tietää minkä tyyppistä tietoa muuttuja pitää sisällään.
Tervesin nimimerkki joskus debugannut saatanaa.
Siis oletuksena. Voihan kaikenmaalilman typeof-operaattoreilla selvitellä niitä, mutta ennaltamääritellyt muuttujatyypit on ihan hyvä juttu.
Muuttujien alustaminen vain tyypin määrittelemiseksi on turhaa vaivaa.
Ja toisaalta kertoa tyyppi ja antaa sisältö tuntuu myös turhalta, koska sisältö kuitenkin jo kertoo tyypin.
Ei suinkaan.
>>> luku=input("Kirjoita luku mikä kerrotaan kahdella:")
Kirjoita luku mikä kerrotaan kahdella:2
>>> print("Luku",luku,"kerrottuna kahdella on",luku*2)
Luku 2 kerrottuna kahdella on 22
>>>
POINTTERIT ovat asia erikseen, jolloin todellakin olisi hyvä tietää että minkä tyyppiseen tietoon tai tietotyyppiin POINTTERI osoittaa...
Ja toistaalta, jos DOKUMENTAATIO on ihan pebasta, niin kuin se yleensä, on niin ei siinä sitten kukaan koondaa niin maan yhtään mitään!
Sisältö ei todellakaan kerro tyyppiä.
Mikä mielestäsi on tyyppi näissä tapauksissa:
a=1
b="2"
c=123.45
d=000000Z
Tämä on itse asiassa aivan käsittämättömän hyvä esimerkki; 2 x 2 on normaalilogiikalla 4, mutta tässä esimerkissä siitä tuleekin 22...
Juuri tämäntyyppisiä bugeja niissä softissa on, kun vaan "oletetaan" että "kaikki kuitenkin tietää", tai sitten tulee vaan inhimillnen virhe...
On näiden kanssa tosiaan joskus tapeltu.... Kannattaa pariin otteeseen tosiaan miettiä että haluaako koodariksi vai ei.... Liksa voi olla hyvä, mutta niin on myös vastuu, ja jos kenkää tulee oleellisten lapsellisten virheiden johdosta, niin vaikea on saada hommia enää sen jälkeen...
Tosin ei noihin hommiin edes pääse ennen kuin on ensin päntännyt muutaman vuoden polilla tai laitoksella...
Tuohan on väärin tehty kysely, jos vastaus on oltava kokonaisluku.
OIKEIN
luku=int(input("Kirjoita luku mikä kerrotaan kahdella:"))
Ja jos haluat vastaan ottaa liukuluvun, niin näin:
luku=float(input("Kirjoita luku mikä kerrotaan kahdella:"))
Oletusarvoisesti vastaus on string -tyyppinen. Kyllä kaikissa kielissä on osattavat säännöt, ei siitä muutoin mitään tule.
No niin, tuossa BASH -skriptissä tosiaan on virhe, mikä selittää miksi saatujen kellonaikojen määrä on eri tuon javascriptin kanssa.
Rivi:
if ([ "$a" == "$b" ] && [ $t -le $s ] )
tulee olle muotoa:
if (([ $t -le $s ] || [ $s -le $t ]) && ([ "$a" == "$b" ]))
Eli siis tunnin pitää olla <= sekunti TAI sekunnin <= tunti sekä, tottakai, ajan sama kuin käänteisen ajan. eli tästä oli tosiaan jäänyt yksi vertailuoperaatio välistä, joka johti tilanteeseen jossa mm. palindromiaika 20:00:02 jäi tulostumatta.
Nyt tällä saa 660 palindromiaikaa, aivan kuten tuolla javascriptilläkin.
Tuon 'echo | rev' voi korvata laittamalla kaikki arvot ensin taulukkoon, ja sitten silmukalla verrata aina taulukon ensimmäistä arvoa viimeiseen, aina kasvattamalla laskuria joka osoittaa talukon alkupäähän, että pienentämällä laskuria joka osoittaa talukon loppupäähän, aina siihen asti kunnes alkupään laskuri on pienempi kuin loppupään laskuri, jolloin se soveltuu sekä parittomiin kellonaikoihin H:MM:SS, että parillisiin HH:MM:SS. Tällainen menettely on välttämätön oikeassa ohjelmoinnissa jossa ei voi (lue: saa) käyttää kutsuja ulkoisiin komentoihin, joka tuo 'rev' on...
Parillisen ajan kyseessä ollessa verrataan siis keskenään taulukon arvoja
p,s
0,5
1,4
2,3 ja vertailu loppuu tähän koska pienin kasvaa suuremmaksi kuin suuri, 3,2
Ja parittoman:
0,4
1,3
2,2 ja vertailu loppuu tähän koska pienin kasvaa suuremmaksi kuin suuri, 3,1
Taulkon elementit alkavat pääsääntlisesti aina arvosta 0, eli taulokon ensimmäinen elementti on aina 0, eikä 1.
Parittoman kellonajan kyseessä ollessa siis esim. 1:01:01 olisi taulukossa arvot;
10101, ja näiden parit 0,4 = 1,1, 1,3 = 0,0, 2,2 = 1,1,
Jossa siis on 'hassua', että parittoman taulukon kyseessä ollessa on sekä pienimmän että suurimman laskurin arvo sama kun ollaan keskellä taulukkoa, ja vertailu voidaan suorittaa sillä se on merkityksetön, sillä jos aika ei ole palindromi niin silmukassa ei edes päästä näin pitkälle.
Parillisessa taas vastaavasti esim. 23:55:32 olisi taulukossa arvot
235532, ja parit näin ollen 0,5 = 2,2, 1,4 = 3,3, 2,3 = 5,5
Kummassakin tapauksessa vertailuja pitää, tai siis kannattaa tehdä kolme, mikä tarkoittaa että kummakin vertailun voi niin halutessa suorittaa vaikka yhdessä erillisessä yksittäisessä funktiossa.
Tällaista se koodaminen siis on, ja näin niitä bugeja aina silloin tällöin tulee... Onko nyt ihan varma että joku ihan oikeasti haluaa koodaajaksi?
Bashin skriptissä voi muuten kätevästi katsoa arvosta $? palauttiko komento virheen vai ei. Esimerkiksi jos haluaa testata onko kellonaika kelvollinen, niin date-komennon paluuarvon pitää olla 0, jos on virheellinen, niin jotain muuta.
user@ubuntu2004:~$ date -d "0:32:23"
N 10 juuni 2021 00:32:23 EEST
user@ubuntu2004:~$ echo $?
0
user@ubuntu2004:~$ date -d "24:32:23"
date: invalid date ‘24:32:23’
user@ubuntu2004:~$ echo $?
1
Kyllä, tämä on aivan totta, kuten ohjelmointikielissäkin voi asettaa funktion palauttamaan arvon, joka voi myös olla jotain muutakin kuin totuusarvo...
Näinhän se on.
Hyvä, sinä tuntematon suuruus, olet täysin oikeassa.