Pascal-ban miként lehet olyan programot írni, amely nagyobb számrendszerekbe is képes váltani? Gondolok itt akár háromjegyű számrendszerbe történő váltásra is.
Olyan módon lenne jó, hogy az oda-vissza váltás is működjön.
Ebben a kérdésben:
http://www.gyakorikerdesek.hu/szamitastechnika__programozas_..
SimkoL válaszában ismertetett nagyszerű programot lehet bővíteni, akkor 70-es számrendszerbe tud váltani (ASCII 126 fölé nem hiszem hogy szerencsés menni, azért csak ennyivel tud számolni, ha bővítem), de már a visszaalakítást ekkor sem tudom megoldani...
Milyen megközelítést kell alkalmazni és hogyan kell nekiállni, hogy háromjegyű számrendszerekbe váltson oda-vissza?
Az algoritmus hasonló, de hogy jelölöd a számokat?
Nagybetűérzéketlenül 36-ig használhatod a betűket is, nagybetűérzékenyen 62-ig, aztán más jelölésrendszer kell, például a "számjegyeket" leírod 10-es számrendszerben, és zárójelekkel különíted el őket egymástól. Példa: (76)(434)(38)_521.
Maga az algoritmus nem sokat változik, csak a be- vagy kimenet nem egy szám, hanem egy string.
Haha!
Lepontozni azt tudtok, egy számrendszerek közötti átváltó algoritmus már meghaladja a képességeteket. :) gimiben kb első héten volt tananyag számteken. :):):):)
Delphi - Pascal színek: 2^24 lehetséges szín bár nem tudom ez hogyan jött a témához.
Mint előttem is elmondták a kis és nagybetű érzékenység miatt kicsit kötöttebb a dolog. Pascal-nál maradva akkor marad 0..9, A..Z ami ugye 36 karakter. De mivel a 36 nem hatványa kettőnek így sokat nem érünk el vele később, mert amit nyerünk a tároláson azt elvesztjük az ide-oda konvertáláson, tehát marad a 32 ami a legideálisabb, bár nem látom értelmét. Az ASCII kódtábla egységesen értelmezhető - vizuálisan is, programozástechnikailag is - része 32-126 közötti intervallumot foglal el, így ebből is látható hogy a 94-es számrendszer fölé menni nem biztonságos. A konvertálások rengeteg processzoridőt vennének el úgymond értelmetlenül és szerintem a string felépítése is értelmetlen - esetleg nagyon érdekes, elsőre nem értelmezhető - lenne. A linkelt kis programom egyszerűen átírható 36-osra
jegyek : array[0..15] of char; helyett
jegyek : array[0..35] of char; és
for i := 10 to 15 do jegyek[i] := chr(55 + i); helyett
for i := 10 to 35 do jegyek[i] := chr(55 + i); kicserélésével.
Persze a hibakezeléshez tartozó if not (alap in [2..16]) then ... és többit is illik kicserélni.
Nagyon köszönöm a válaszokat.
A feladat a bonyolultsága miatt érdekelt, hogy ilyen nagy számrendszerre (>100) csak nekem nehéz -e az adott dolog, vagy tényleg bonyolult.
Egy darabig ez is megoldás lehet:
A1 = 10
B1 = 20
C1 = 30
...
Z1 = 270
Mint írtam is a 'számjegyek' egységes tárolása okozza a legnagyobb gondot. Nem véletlenül találták ki, terjedt el a Base64 kódolás.
'Egy darabig ez is megoldás lehet:
A1 = 10
B1 = 20
C1 = 30
...
Z1 = 270'
Hát két bájton tárolni, ábrázolni egy viszonylag kis számot nem valami gazdaságos. Ugye 2^16-on kicsit nagyobb min 270. Valószínűleg ha értelme lenne már rég elterjedtek volna a hexa számrendszertől nagyobbak is, de miatta nem fogják megreformálni a számítástechnikát, programozást. A 32-es talán még ésszerűen beleférne, de ezt sem erőlteti senki. Az oktális számrendszert is csak néhány helyen alkalmazzák.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!