- D1Rect: Nagy "hülyétkapokazapróktól" topik
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- GoodSpeed: ASUS ROG STRIX B650E-F GAMING WIFI - Memory Context Restory (MCR)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- sziku69: Fűzzük össze a szavakat :)
-
Fototrend
Új hozzászólás Aktív témák
-
vz12
tag
Hali!
Anno amikor a DOS-os Pascalból (TP) átírtam egy progimat D3-ba én is találkoztam ezzel a problémával. Input + output célból volt egy rekordokból álló tipusos fájlom ami TP alatt tökéletes volt, de D3-ban nekem is elcsúszott beolvasáskor. Én magamtól rátaláltam a megoldásra, csak most kapásból nem emlékeztem hogy mi volt az.
De egy kis keresgélés után megtaláltam hogy melyik volt az a progi, és mivel szerencsére kommentelni sem felejtettem el (!) így az én megoldásomat most el tudom mondani. Fordítási direktívákkal (!!!) kellett játszani, na nem sokat de célirányosan.Én ezt a kettőt állítottam be a program elején, lehet később is de legkésőbb a fájlkezelés előtt:
{$H-} // default is ShortString
{$A-} // NOT Aligned record fieldsA Project Options/Compiler menüpontban is le lehet szedni a 2 pipát a checkboxból, de így a programból kiadott utasításként hosszabb távon biztosabb a siker ...
A {$H-} sem árt, de főleg a {$A-} a lényeges, mert az alapértelmezett "+" valami automatikus szóhatárra illesztést végez, tehát 4 byte-os határra "tol" adatokat a rekordban (igazából nem tudom hogy mi célból), kikapcsolva meg nem tologat semmit, nekem így megszűnt az elcsúszás. Sajnos a "+" a default. Nekem gyanús hogy ez lesz a megoldás Nálad is, tehát ez(eke)t ki kellene kapcsolni.
Egy próbát megér.[ Szerkesztve ]
-
vz12
tag
Tartok tőle hogy nem egyforma négyzeteket kellene elhelyezni. Tény hogy ez nincs leírva, de enélkül nem lenne feladat ... Ezzel együtt viszont már nagyon is nehéz, de még mindig könnyebb mint ha mondjuk téglalap lenne, amit így is lehet forgatni meg úgy is. Többféle síkidommal meg egyenesen szörnyű.
Legalábbis ha valódi optimumot akarnánk keresni, és nem érjük be valami optimumhoz hasonlító értékkel.Ez egy gyakorlati probléma, gondolok itt a fa - vagy üvegtáblák darabolására minél kevesebb anyagveszteséggel, az ilyen programokat ritkán szoktak barátságból írni. A felhasználónak tudnia kell hogy a futásoknak az adatoktól függően számottevő időigénye is lehet.
-
vz12
tag
válasz
tamas60
#5149
üzenetére
Pontatlanság, hát igen ...
Akár egy szó is nagyon durván megváltoztathatja a feladat megoldhatóságát, mint jelen esetben is ..., ez egy ilyen dolog. Utólagosan kimagyarázni nem szerencsés, illene megelőzni, pl. a részletek felfedésével, a pontatlanság kerülésével.
Így téglalapokkal jelentkezőt találni nehezebb lesz, mert a feladat is jóval nehezebb. De gyakorlati probléma lévén gondolom csinált már ilyet néhány ember ebben az országban is, persze nem biztos hogy C++ -ban, és nem biztos hogy ezen fórum olvasói közül (vagy ha igen akkor sem biztos hogy könnyen odaadja). Nem szándékom rontani a "boltot", de az 1600-as szám se kevés, a programnak végülis mindegy, csak akinek ki kell várni az eredményt annak nem. És mielőtt megkérdeznéd elárulom hogy nekem nincs ilyen programom, és a megírását sem vállalnám el. Pedig nagyon szép, érdekes és gyakorlatias a probléma, de nagyon nehéz is. -
vz12
tag
válasz
doboka98
#7399
üzenetére
Hali!
Nincs kezdőértéke a szam3-nak, és elvileg előfordulhat hogy nem megy bele a vezérlés a while-ba, hogy szam3 értéket kapjon, így pedig nem lehet szam3 értéket felhasználni az utolsó sorban. Ez elvi hiba.
Mondjuk a while elé írd be: szam3 = szam1;Amúgy van még mit csiszolni a módszereden is, mert ha szam1 és szam2 nem egyforma, akkor ez így még végtelen ciklus lesz !
[ Szerkesztve ]
-
vz12
tag
válasz
sztanozs
#14001
üzenetére
- az "exit" mellett a "begin ... end" is hiányzott, mert az kell, ha több utasítás van a blokkban
- amúgy az "exit" nem igazán szép
- nem kellene kipróbálni, hogy működik-e, mielőtt kiadjuk a kezünkből?Én kipróbáltam, így működik:
program ermek_demo;const n = 2;type ermek_tipus = array [1..n] of integer;const ermek:ermek_tipus = (1,2);function f_kombok(ermek:ermek_tipus; osszeg,temp_index:integer):integer;var i, tmp_kombok:integer;beginif (osszeg=0) thentmp_kombok:=1elseif (osszeg<0) thentmp_kombok:=0else begintmp_kombok:=0;for i:=temp_index to n dotmp_kombok:=tmp_kombok+f_kombok(ermek, osszeg-ermek[i], i);end;f_kombok:=tmp_kombok;end;beginwriteln(f_kombok(ermek,4,1));end.[ Szerkesztve ]
-
vz12
tag
válasz
sztanozs
#14006
üzenetére
En is online próbáltam ki, ma reggel kerestem egy ilyen oldalt.
[link]Az "exit"-ről nem azt mondtam, hogy nem lehet, vagy nem működik, csak azt hogy nem igazán szép. Te is azt írtad, hogy célszerű az amit én írtam, tehát nincs is vita kettőnk között.
Exit nélkül kaotikusabb a vezérlés, meg nálatok a függvény többször kapott értéket (!), ezért nem szép, de persze működik.
A plusz változóval semmi probléma, azt célozza, hogy a függvény csak egyszer kapjon értéket. Ráadásul az a plusz változó a ti megoldásotokban is ott van, de csak az egyik ágban a 3 közül.
Amúgy mindenki csinálja úgy ahogy gondolja, nekem ez szép, én így csinálom.
Attól hogy szép valami, még nem biztos hogy működik, és attól hogy működik, attól még lehet csúnya ...
Én a működő ÉS szép megoldásokat szeretem, attól lesz jobb a világ.[ Szerkesztve ]
-
vz12
tag
válasz
janos1988
#14151
üzenetére
Az első megoldás (is) majdnem jó, teljesen végigmegy a mondaton, a "pont" is megvan a végén, csak éppen nem írja ki az utolsó szót. A szg. ugye nem a kívánságaink, hanem az utasításaink szerint működik, tehát ha nem írja ki a gép, akkor az azért van, mert nem lett megmondva neki.
Nos, akkor mondjuk meg neki, az első megoldást egészítsd ki a for ciklus után, az "end." előtt a következővel:if (s2<>'') then writeln(s2);
-
vz12
tag
válasz
janos1988
#14175
üzenetére
Én valahogy így csinálnám.
Extra feature: a szóközök száma akár több is lehet a szavak között.
A "+1" és "-1" dolgokra nagyon oda kell figyelni.program szoveg_bontas;
const N=100;
type tomb_type=array[1..N] of string;
var tomb:tomb_type; i,db:byte; s:string;
procedure bontas(s:string; var tomb:tomb_type; var db:byte);
var i,pos1:integer; tmp,szo:string;
begin
tmp:=s;
for i:=1 to N do tomb[i]:='';
db:=0;
while tmp<>'' do begin
pos1:=pos(' ',tmp);
if (pos1>0) then szo:=copy(tmp,1,pos1-1) else szo:=tmp;
if (szo<>'') then begin
db:=db+1;
tomb[db]:=szo;
end;
delete(tmp,1,length(szo)+1);
end;
end;
begin
s:=' Ez egy ronda mondat. ';
bontas(s,tomb,db);
for i:=1 to db do
writeln(tomb[i]);
end.[ Szerkesztve ]
-
vz12
tag
válasz
janos1988
#14178
üzenetére
A "+1", "-1' nem fétis, hanem fontos eleme a működésnek, nevezhetjük trükknek, de igazából ez szükségszerű. Ha belegondolsz és megérted a miértjét, szerintem el fogod ezt ismerni.
A programom ugye alapvetően nem karakterenként, hanem szavanként szeleteli le az input szöveget, pontosabban szóköztől szóközig. Minden lépésben megkeresi a következő szóközt, viszont a megtalált szónak ez a szóköz már nem része, ezért van a "-1". A "szeletelésnél" (delete) viszont nem csak tisztán a szót, hanem a megtalált szóközt is le kell szedni a szöveg elejéről, ezért van a "+1".
Ezt nem úgy kell nézni, hogy 1-1 = 0 és ennyi, nem. A folyamat (ciklusmag) végén 1-1 = 0, ez rendben van, de ez nem azt jelenti, hogy működés közben a "mikrokörnyezetben" ez végig így van.
Csak a végén.
Közel kell menni a részletekhez hogy megértsük a dolgokat, a működést nem (mindig) lehet "távolról" nézni, vagy átlagolni, ahol már összemosódnak a részletek. Pl. ha fociban egy játékos egy meccsen rúgott 2 db gólt tizenegyesből, az ugyanaz, mint ha az egyiket a kapu mellé rúgta balról 1 méterrel, a másikat a kapu mellé rúgta jobbról 1 méterrel, vagyis átlagban 2 gólt rúgott a kapu közepébe ... (?)A "tmp" változó a függvényemben a jelen esetben nem szükségszerű, mert az eredeti input szövegre menet közben nincs szükség, de más esetben előfordulhatna hogy szükség van rá, ezért én szeretem így csinálni. De itt, most ez valóban tűnhet feleslegesnek.
A tömböket én mindig nullázom induláskor, régebben ez szükségszerű volt (mert nem lehetett arra számítani, hogy 0-val indulnak), az "újabb" pascal verziókban (TP 7.0-tól kezdve) úgy tudom hogy ez a probléma már nincs meg, ez is csak egy (jó) szokásom. Persze az is lehet hogy nem 0 a tömbelemek kezdeti értéke, akkor mindenképpen inicializálni kell, én ezt inkább rutinszerűvé tettem, ennyi.
A "delete(tmp,1,pos1)" az általam írt szóköz végű inputtal jó (mondjuk rá), de ha nem szóközre végződik (azaz normális esetben) NEM JÓ, úgy kell ahogy én csináltam. Próbáld ki az én programomat olyan input szöveggel, aminek a végén nincsenek szóközök (egy sem). Sőt, a "delete(tmp,1,pos1+1)" sem jó. Meg lehet érteni, hogy miért van ez így, de ezt az olvasóra bízom.
[ Szerkesztve ]
-
vz12
tag
válasz
janos1988
#14181
üzenetére
Köszi.
Örülök, ha mostanra már magától értetődő, van néhány "apróság" amiről nem is beszéltünk, pedig kell a hibátlan működéshez, de nyilván felfigyeltél rá és érted.
Egyébként lehet, hogy a Te programod gyorsabb az enyémnél (de ez ennél a feladatnál nem igazán számít), viszont kacifántosabb (bonyolultabb) is, ami viszont nem előny.A nagy kapkodásban nálam bent maradt egy "var i,pos1:integer;", ami ugyan hibát nem okoz, de elpazaroltam 2 byte-ot feleslegesen a memóriából.
A "var i,pos1:byte;" jobb lett volna.
A stringek a "normál" pascal-ban max. 255 hosszúak lehetnek, amihez elég a "byte" típus.Mostanában már nemigen pascal-ozok, de régebben sok példa volt rá.
A tömb 0-záson annyit pontosítanék, hogy string típusú tömb esetén természetesen nem 0, hanem "üres string" van (ezt így is csináltam, csak félrebeszéltem), a többi stimel, tehát a TP 7.0 előtt ez is probléma volt, azóta valószínűleg az üres string a kezdőérték. De ha én beállítom az üres stringet kezdőértéknek, akkor tuti hogy az üres lesz, javaslom ezt mindenkinek.
[ Szerkesztve ]
-
vz12
tag
válasz
bandi0000
#14927
üzenetére
TEMP tábla ugye használható?
Az alábbi ötletem van, a szintaktikát a környezetedre kell majd konkretizálni.(1) CREATE TABLE temp AS(SELECT MIN(pld,rpld) pld, MAX(pld,rpld) rpld, qtt FROM input_table)(2) CREATE TABLE celtabla AS(SELECT pld, rpld, SUM(qtt) qtt FROM temp GROUP BY pld,rpld ORDER BY pld, rpld)(3) DROP TABLE temp -
vz12
tag
válasz
bandi0000
#14932
üzenetére
Igen, valami "NVL"-féleség akkor megoldás lehet.
A NULL az az eset, amikor csak 1 sor van? (nincs 2 összetartozó sor?)
Akkor a végén a "-1"-et és a "nagy" számot majd vissza kell alakítani NULL-nak.Vagy esetleg lehet "+1" lépésben is:
(1) az első SELECT-be kell egy WHERE: "rpld IS NOT NULL"
(4) "celtabla"-hoz hozzá kell INSERT-elni az "input_table"-ból az "rpld IS NULL" sorokat is a végén, persze azt nem árt figyelni / tudni, hogy a "celtabla" létrejött-e egyáltalán, mert nem létező táblába nem lehet INSERT-elni (illetve ekkor az eredeti tábla egyben a céltábla, nem kell csinálni "semmit")[ Szerkesztve ]
De egy kis keresgélés után megtaláltam hogy melyik volt az a progi, és mivel szerencsére kommentelni sem felejtettem el (!) így az én megoldásomat most el tudom mondani. Fordítási direktívákkal (!!!) kellett játszani, na nem sokat de célirányosan.
Legalábbis ha valódi optimumot akarnánk keresni, és nem érjük be valami optimumhoz hasonlító értékkel.
Csak a végén.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Politika
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- TCL LCD és LED TV-k
- Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
- Kupon kunyeráló
- EA Sports WRC '23
- Milyen belső merevlemezt vegyek?
- Autós topik
- Skoda, VW, Audi, Seat topik
- exHWSW - Értünk mindenhez IS
- További aktív témák...
- Commlite CM-EF-NEX Auto-Focus Adapter (Canon EF - Sony E)
- Üzletből, garanciával, legújabb Asus Vivobook 17" i7-1355U 10 mag 5GHz/16RAM/1TBSSD/17,3"FULLHD
- Üzletből, garanciával DeLL XPS 15 9500 i7-10750H 32GBRAM 1TBSSD/GTX1650Ti 15,6"4KTOUCH
- i5 12400f 3070 gamer pc
- DeLL Precision 7740 workstation, üzletből, I7-9850H/32RAM/512GBSSD/NVIDIA QuadroRTX3000/17,3"FULLHD
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest