-
Fototrend
Új hozzászólás Aktív témák
-
Atlas
csendes tag
Bocs. Nem akartam pofátlannak tűnni. Ne vegyétek személyesen.Bocs.
-
shev7
veterán
azon gondolkodtatok, hogy vajon miert jonnek elo mindig ugyanazok a kerdesek?
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
Zoli14
csendes tag
Hello
Nem tudom, hogy ide tartozik-e, de meg szeretném kérdezni, hogy nem tud-e valaki egy jó könyvet ajánlani C nyelvű programozáshoz kezdőnek.
Előre is kösz. -
windforce
csendes tag
Sziasztok!
Segítségeteket szeretném kérni egy programban. Két file ossze XOR-olásárol lenne szó. Lefut a program, meg is csinálja a kódolt file-t, de a végére beszúr egy oda nem illő karaktert. Ezt mivel lehetne orvosolni?
a forrásfile: [link]
Köszönöm!
[Szerkesztve] -
Zoli14
csendes tag
Kösz a választ.
Pontos könyvcímet nemtudnál adni? -
Jester01
veterán
válasz windforce #2355 üzenetére
Azért van, mert a feof csak azután lesz igaz, hogy megpróbáltad beolvasni az utolsó utáni byteot is. A megoldás pedig az feof helyett az fgetc visszatérési értékének ellenőrzése (EOF konstans lesz).
A kulcs fájl végének ellenőrzése ettől eltekintve is hibás, fölösleges bele a tagadás.Jester
-
Jester01
veterán
válasz windforce #2358 üzenetére
Pl.:
for(chr = fgetc(kodolando); chr != EOF; chr = fgetc(kodolando))
{
chk = fgetc(kulcs);
if (chk == EOF)
{
rewind(kulcs);
chk = fgetc(kulcs);
if (chk == EOF) break; /* ures kulcs, vagy baj van */
}
...
Egyébiránt ellenőrzésképpen próbáld meg dekódolni az eredményt. Ha ezt megtetted volna akkor egyből láttad volna hogy nem csak a plusz karakter a baj.Jester
-
Bazsesz
őstag
Helóháj!
Lenne egy kisebb problémám. Kaptam egy programozási feladatot, szemaforokkal kell két program között szinkronizációt megvalósítani (a program lényege az, hogy egyik progi ír valamit az osztott memóriába, addig a másik várakozik, majd mihelyst vége az írásnak, csere: a másik ír valamit, és az első várakozik).
ANSI C. :S
Nagyon nem értem a lényegét a szemaforoknak, mert itthon próbálkozok, és nem nagoyn akar menni :S
Előre is köszi!
Üdv: Bazsi''Játék a szavakkal mintájára Dúd a betűkkel :d Előadja Bazsesz művészúr :)'' by Esmein
-
Jester01
veterán
válasz Bazsesz #2360 üzenetére
A szemaforok tulajdonképpen számlálók amik általában azt jelentik, hogy valami X dologból rendelkezésre áll valamennyi. A számláló növelése nem várakozik, ez csak azt jelenti, hogy több X áll rendelkezésre. Ha most jön valaki, hogy neki kellene valamennyi X, akkor a rendelkezésre álló mennyiséget az igényelt mennyiséggel csökkenteni kell, illetve ha éppen nincs elegendő, akkor várni kell.
A te feladatodra rátérve: 2 szemaforra lesz szükség, mivel a probléma szimmetrikus. Az egyik jelzi, hogy az A program írt valamit amit a B kiolvashat, illetve fordítva.
A program:
write(); /* írunk valamit */
sem_up(A); /* jelezzük, hogy A írt */
sem_down(B); /* várunk amíg B jelzi, hogy írt */
read(); /* kiolvassuk */
B program:
sem_down(A); /* várunk amíg A jelzi, hogy írt */
read(); /* kiolvassuk */
write(); /* írunk valamit A-nak */
sem_up(B); /* jelezzük, hogy B írt */Jester
-
Robaj
addikt
válasz Bazsesz #2360 üzenetére
Vmi ilyesmi:
#define N 100
typedef int semaphore;
semaphore mutex=1;
semaphore empty=N;
semaphore full=0;
void producer(void)
{ int item;
while (TRUE){
produce_item(&item);
down(&empty);
down(&mutex);
enter_item(item);
up(&mutex);
up(&full);
}
}
void consumer(void)
{
int item;
while (TRUE) {
down(&full);
down(&mutex);
remove_item(&item);
up(&mutex);
up(&empty);
consume_item(item);
}
}
Előadásjegyzetben van/volt, hámozz ki belőle vmit. Nekem nem sikerült. De 2-es megvan. -
Bazsesz
őstag
huhh. ez nekem igen magas
az a poén, hogy ez egy ''koronglopkodó'' játék lenne, ami kétfelhasználós (2 kliens program'' osztott memóriában tárolja az asztalt, és a két program közti szinkronizálás szemaforokkal történik.
Ott tartok, ahol a part szakad, dehát aki ezt kikapta még nem tudta megcsinálni...
gondolom annyi lenne a lényege, hogy A kliens beírja, hogy 7 korongot vesz el, a 100-ból, vagy az aktuális maradékból levonja a 7-et, és a szemaforral a másik programnak átadja, hogy 7-et vett le...
és ez az egész nekem magas, hogy melyik függvény mire hajaz''Játék a szavakkal mintájára Dúd a betűkkel :d Előadja Bazsesz művészúr :)'' by Esmein
-
Forest_roby
őstag
válasz Bazsesz #2360 üzenetére
Hi!
Szemaforok: légyeg, ha egy erőforrást egyszerre két folyamat akar használni, akkor ütköznének a folyamatok, -biztos hogy hibás eredmények születnének. Most cifrázhatnám, hogy milyen sulyos hibák történhetnének, de el tudjátok képzelni... No, első gondolatra válozókkal meglehetne oldani, a problémát ( ezt most nem részletezem ) , de az a probléma, hogy ott ugyanúgy összeakadna a progi, ez nem megoldás. A szemafórok az oprendszer (LINUX) által biztosított olyan változók, amiknél nem fordulhat elő az, hogy egszerre használják ugyanazt az eszközt... ( hogy ezt hogy érik el, az legyen egy okosabb embernek az összefoglalója ).
Szóval ilyen problémák megoldására a szemaforokat kell használni....
Használat:
A szemaforokon két műveletet értelmezünk:
Csökkentés és Növelés
A szemafor értéka 0 és 1 lehet. Ha 0 -akkor blokkolt a folyamat és ha 1 akkor szabad a futás.
Csökkentés:
Amikor a progi belépni akar a kritikus szakaszba akkor fog csökkenteni, ha a szemafor 0 volt akkor várólistára kerűl a folyamat, ha 1 volt akkor a folyamat lefut és a szemafor 1-ről 0-ra csökken.
Növelés:
A folyamat végrehajtása után történik meg. A szemafort 1-re álitja. Ha lenne olyan folyamat, amely e miatt a szemafor miatt volt blokkolt állapotban, arról a Linux gondoskodik, hogy az felszabaduljon a blokkolt állapotból.
(dióhélyban /majd vissza kell olvasnom, hogy mennyi baromságot írtam ide le....)
int semget(...)
int semctl(...)
int semop(...)
fv-eknek érdemes utánna nézni, sajna a progi amit tudnék adni 125 soros és most nincs kedvem begépelni, de google-on biztos sokat találsz....
remélem azért nem volt teljesen hasztalan ezt begépelnem...
Sok sikert!
[Szerkesztve]-=Legyél Laza!=- __ ''Have you tried turning it off and on again?'' __ ''Is it definitely plugged in?'' /o\ :D:D
-
Forest_roby
őstag
Jó reggelt!
program make dist -elésénél, hogy lehet megadni, hogy egy plus mappát is disteljen be(, ahol a program saját header file -jait tárolom) (/src/own/... <-- itt vannak az általam készített header fileok)???
Előre is köszi!-=Legyél Laza!=- __ ''Have you tried turning it off and on again?'' __ ''Is it definitely plugged in?'' /o\ :D:D
-
Jester01
veterán
válasz Forest_roby #2366 üzenetére
Reggel a fenét
Az attól függ milyen build rendszert használsz. De ha belenézel a makefile-be, akkor nyilván magad is megtalálod.Jester
-
Forest_roby
őstag
válasz Jester01 #2367 üzenetére
( kicsit kidőltem )
PACKAGE_CFLAGS = -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2
PACKAGE_LIBS = -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lfontconfig -lXinerama -lXi -lXrandr -lXext -lXcursor -lXfixes -lpango-1.0 -lcairo -lXrender -lX11 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lxml2 -lz -lm
szerintem ezek a fontos részek... Nem tom, vhogy nem egyértelmű... ha egy névvel ellátott libet akarnék hozzáadni az TALÁN menne de ez a saját mappás dolog nem...
-=Legyél Laza!=- __ ''Have you tried turning it off and on again?'' __ ''Is it definitely plugged in?'' /o\ :D:D
-
gaben
aktív tag
CSak alakul a programom,de van egy nagy gondom...
Van 2 dv .c és egy .h állomány. Makefile van.
De amikor a .c állományokban átrrom a kommentet,akkor a make parancs futtatása esetén egy csomó hibát ír ki... és nem egyesíti...
Ez miért van,mi a megoldás? -
bugbear1
csendes tag
Sziasztok.
Egy kérdésem lenne és nagyon örülnék a segítségnek.
Egy beadandó házit kaptam: numerikus integrálás hasábszögekkel.
Elsös egyetemista vagyok és még integrálni se tanultunk. -
KPepe
senior tag
üdv!
A következő feladatot kaptuk: [link]
A mission:
Módosítsuk az alábbi programot úgy, hogy a kommentezett műveletek is legyenek végrehajthatóak! A megoldásban továbbra is tartsuk szem előtt az expression templates előnyös tulajdonságait és használjuk ki azokat a megoldás során!
A gondom az, hogy nem igazán tudok elindulni, mert nem teljesen értem, hogy az eddigiek hogy működnek. Valaki el tudná magyarázni?
köszi!
[Szerkesztve]A tüzérség előtt minden és mindenki egyenlő. A föld színével.
-
Gerghu
csendes tag
Egy gyors kérdés:
kötelező feladat megoldásához muszáj gráfot ábrázolni, és vannak megkötések: időlimit: 0.3 mp, memórialimit 32 MB.(a nyelv: c/cpp)
A gráfban max 200.000 él lehet(max 10000 csúcs).
Melyik marad idő és memóriakorláton belül:
Élmátrix, tehát egy max 200.000 elemű tömb.(inkább ezt csinálnám)
Láncolt lista, amiről el nem tudom képzelni hogy készül el a be.txt-ből.
Köszönöm előre is! -
Jester01
veterán
Ez a kód olyan mintha a haverom írta volna Ész nélkül kihasználja a nyelvben lévõ lehetõségeket, de feláldozza az olvashatóságot és karbantarthatóságot. Kiváló példája annak, hogyan ne használjuk a template-eket, hacsak nem vagyunk zsenik.
Mindenesetre a dolog kb. a következõképpen mûködik:
Vektorokkal végez mûveleteket, ez gondolom nyilvánvaló. A Vector<T, N> N darab T típusú elemet tartalmaz. A VectorSum osztály az összeadás mûveletet reprezentálja.
Az elsõ összeadás operátor azt írja le, hogy két azonos elemtípusú és méretû vektor összeadható, és az eredménye ugyancsak ilyen tulajdonságú vektor lesz.
A második összeadás operátor azt mondja, hogy egy vektorösszeghez jobbról még hozzá lehet adni egy másik vektort is.
Az init és print függvények gondolom világosak.
A megvalósítandó mûveletek:
vektor + vektorösszeg: a vektorösszeg + vektor mûvelet párja, a jobb és bal oldal felcserélésével.
vektorösszeg + vektorösszeg: mint az elõzõ, csak most mindkét oldal vektorösszeg
számmal szorzás jobbról és balról: be kell vezetni egy új alapmûveletet a VectorSum mintájára, pl. így:
template<class T, long N, class V>
class ScaledVector
{
long factor;
const V &vector;
public:
ScaledVector(long f, const V &v) : factor(f), vector(v) {}
T operator[](long i) const {
return factor * vector[ i ];
}
};
Igényesebb kollegák a faktor típusát beadhatják template paraméternek, akkor majd pl. double típussal is lehet szorozni.
A Vector osztályba fel kell venni egy újabb overloadot az = operátorra, hogy ilyen ScaledVector osztályt is tudjon fogadni (ugyanúgy sima elemmásolás van benne).
Ezután már csak a szorzás operátorra kell egy overload, pl. így:
template<class T, long N>
inline ScaledVector<T,N,Vector<T,N> >
operator*(int f, const Vector<T,N> &v) {
return ScaledVector<T,N,Vector<T,N> >(f,v);
}
Illetve hasonlóképpen jobbról való szorzáshoz is.
És mivel ilyen ScaledVector objektumokat még össze is akarunk adni, hát ahhoz rá kell engedni a VectorSum-ot két ScaledVector-ra, imígyen:
template<class T, long N, class Left, class Right>
inline VectorSum<T,N,ScaledVector<T,N,Left>,ScaledVector<T,N,Right> >
operator+(const ScaledVector<T,N,Left> &l, const ScaledVector<T,N,Right> &r) {
return VectorSum<T,N,ScaledVector<T,N,Left>,ScaledVector<T,N,Right> >(l,r);
}
Egyszerû, nem igaz?
[Szerkesztve]Jester
-
Jester01
veterán
Hacsak egyéb ok nincs rá akkor a gráfot egyszerûen csomópontokkal és belõlük induló élekkel ábrázoljuk:
class Node
{
public:
vector<Node*> Edges;
};
Ez nálam mérve 12 byte csomópontonként, az kemény 120kB. A 200000 pointer az 800kB. A legrosszabb vector overhead-del számolva is belefér 2 megába az egész (64 bites gépen max. dupla ennyi).
Ha valami egyéb információt is el kell tárolni a csomópontokról/élekrõl akkor az persze erre még rájön, de azt semmiképp nem úszod meg.
(Az éleknek az egyszerûség kedvéért nem csináltam külön osztályt.)Jester
-
cucka
addikt
c-ben gondolkozva:
a 10ezer csúcs miatt célszerű éllistával ábrázolni, ott pedig nem probléma a memórialimit.
csúcsoknak lefoglalod előre a memóriát, akkor ugye tömbként kezeled, és a tömb indexe fogja megmutatni az illető csúcs ''nevét''. minden csúcsból kiindul egy lista, ami tartalmazza az éleket. egy élnek van végpontja, ami egy int és rákövetkező csúcsa, ami egy csúcsra mutató pointer, vagyis egy csúcs mérete nagyjából 12byte, össszes csúcs így 240kbyte-ot foglal. ha nagyon szorít az időlimit, akkor eltárolhatod minden csúcsnál az utolsó élre mutató pointert, így a beszúrás n idő helyett 1 idő alatt megtörténik.
az élmátrix az egyébként micsoda? én csak a csúcsmátrixot és az éllistát ismerem/használtam.
listákról minden könyvben olvashatsz, de a gúgle is sok hasznos találatot dob, főleg ha angolul keresel. ennek fényében nem értem, mi a probléma a file-ból való lista felépítéssel. (kulcsszó: linked list). -
Gerghu
csendes tag
Köszönöm a segítséget, de nem hitegetem magam tovább: nem tudom megirni a programomat... a dinamikus programozással nem volt gond, de ez a gráf algoritmusos kötprog ez meghaladja a tudásomat.
Ha valamelyikőtöket érdekel, akkor tudok ennek megirásáért pénzt ajánlani. Nem ismerem a tarifákat (már ha van), de hátha...
Dühítő ez a rendszer: benntvoltam az előadásokon, ugyanis kötelező; megirtam a 2 nagyZH-t amiből elegendő pontot szereztem; megirtam a 12 kisZH-t amiből szintén elegendő pontot szereztem; megírtam az első kötprogit max pontosra. És ha ez nem sikerül akkor bukta minden amit fent soroltam..., persze egy robot ellenőrzi, igy vagy tökéletes vagy 0 pont ergo bukás.
sorry az OFF miatt -
Gerghu
csendes tag
Okay elárulom, eddig azért nem tettem mert tartok tőle hogy az előadó szeme mindent meglát.
A feladat: egy irányított gráfban megkeresni azokat a csúcsokat amelyek legalább egy körnek a részei.
Tudom hogy kellene megcsinálni csak implementálni nem tudom: egy éllistába be kell olvasni a gráfot, azon futtatni egy erősen összefüggő komponensek(EOK) keresést és ennyi.
C és Java között gondolkodom, Javaban megvan az algoritmus, meg ugy látom ott van eleve láncolt lista, mig C-ben az algoritmust ujra fel kellene épiteni.
Az éllistát ugy kell csinálni, hogy létrehozok egy tömböt aminek az indexei a csúcsok sorszámai? és minden tömbelem egy LinkedList? mert ha igen akkor a beolvasás nem lehet gond Java alatt... csak utána hogy hozzam össze a kezembe adott algoritmussal? vagy a irjam meg a mélységi keresést az éllistámhoz? (2 mélységi keresés kell az EOK-hez)
Köszönöm -
bpx
őstag
válasz bugbear1 #2371 üzenetére
Szia!
Nem tudom mi az a hasábszöges integrálás , de sztem itt a téglalapos módszerre gondolnak. (erre nagyon egyszerű programot írni)
Van egy függvény + egy intervallum, amin integrálni kell + osztópontok. Ezek után az intervallumot felosztjuk az osztópontokkal egyenlő hosszú szakaszokra, majd ezen kis szakaszokhoz tégalapokat rajzolunk egyszer a szakasz bal oldali végpontjában vett függvényérték magasságáig, másodszor pedig ugyanez a jobboldali végpontnál vett függvényértékig. (mondhatni először a függvény ''alá'', utána a függvény ''fölé'')
No még képet is kerestem hozzá Google-ben , az 1. és 3. kép pont ezt mutatja (a középső(2.) képpel ne foglalkozz): [link]
Az integrálással a függvény alatti területet kapod meg, de ugye a téglalapok nem pontosan fedik a függvényt, szóval, ha összeadod a téglalapok területét, akkor az egyik összeg alulról, a másik pedig felülről fogja közelíteni a tényleges értéket. (Nyilván minél több osztóponttal csinálod, annál pontosabb lesz az eredmény)
Erre pedig így néz ki egy abszolút alap program: (azt persze nem írtad miben kell, így C++ lett belőle)
#include <iostream>
using namespace std;
int main() {
int a, b, op;
float da, db, dx;
float alsoosszeg = 0;
float felsoosszeg = 0;
cout<< ''Az intervallum ket vegpontja:\n'';
cin >> a >> b; // b>a
cout<< ''Az osztopontok szama: '';
cin >> op;
dx = (float)(b-a)/op;
for (int i=0; i<op; i++) {
da = a + (i*dx);
db = a + ((i+1)*dx);
alsoosszeg+= dx*da*da; // itt szamolja a fuggvenyerteket
felsoosszeg+= dx*db*db; // ez most epp az x^2 fuggveny
}
cout<< ''Az also kozelito osszeg:''<< alsoosszeg << endl;
cout<< ''A felso kozelito osszeg:''<< felsoosszeg << endl;
cin>>a;
} -
Joooe
tag
Én inkább egy bitmátrixot tartanék megfelelőnek erre a feladatra.
A memóriában az is elfér (10000^2/8 = kb. 12 MB)
Bár elgondolkodtató, hogy ez a megközelítés nem használja ki az élek relatíve alacsony számát.
Ami gyorssá teheti a megvalósítást, hogy ha a mátrix azt mutatja, hogy az i-edik csúcsból elérhető a j-edik, akkor a j-edik sort hozzá VAGY-oljuk az i-edik sorhoz, ezzel tovább bővítve az i-ből elérhető csúcsok listáját, azokkal ami j-n keresztül elérhető.
Ez mindenféle implementációban elvégzendő művelet, hogy megvizsgáljuk, hogy mi van ha arra megyünk, de azt hiszem így tudjuk leggyorsabban megtenni. Így processzortól függően egyetlen művelet során nagyon sok (64?) csúcsra történik meg a vizsgálat.
Az még egy kicsit elgondolkodtató, hogy mikor végeztünk, hiszen ezt többször el kell végezni, de ha végeztünk, akkor azokat a csúcsokat listázzuk amire mátrix[i,i]=1, azaz elérhető magából maga, azaz tagja valamely irányított körnek.
[Szerkesztve]
[Szerkesztve]Hogy mit gondolok a nyugati civilizációról? Azt hiszem, jó ötlet lenne.
-
k.t.a.
senior tag
Hali!
Egy kis segítséget szeretnék kérni. Bitműveletekről lenne szó C-ben. 8-al akarok osztani egy egész számot, de nem emléxem melyik az a művelet, amivel három bittel el tudom úgy tolni a számot, hogy nullákkal töltse ki a maradék helyet, és ne körbeforogjon, bár az is megfelelne, ha amit kishifteltem az a másik végén visszajönne. Talán a >> és << operátorok azok? -
k.t.a.
senior tag
Lehet hogy valamit rosszul csinálok, mert nem egészen az történik amit szeretnék. Két 8 bites előjel nélküli egészből csinálnék egy darab 16 bites szintén előjel nélküli egészet. Valahogy így:
void assign16(unsigned char *LD, unsigned char *HD, unsigned int *D)
{
*D = 0x0000;
*D = *HD;
*D << 8;
*D = *LD;
PORTAbits.RA6 = 1;
}
Ha egy int-et egyenlővé teszek egy char-al, akkor nem lehet hogy elveszik felső bájt? -
k.t.a.
senior tag
Megoldottam a problémám. Kicsit összetett volt. Ha valakit esetleg érdekel, ez lett a függvény. Illetve ha valakinek van ötlete, hogyan lehet még egyszerüsíteni, az jöhet.
unsigned int assign16(unsigned char LD, unsigned char HD)
{
unsigned int L = 0x0000,H = 0x0000,D;
L += LD;
H += HD;
D = (H << 8)+L;
return (D >> 3);
} -
Radíros
csendes tag
És (#2385) Joooe üzenetére...
Ez a bitmátrix egy csúcs-szomszédsági mátrix,
amely azt mondja meg az M[i,j] elemben, hogy
az i-edik csúcsból vezet-e él a j-edik csúcsba.
(Pl. ha igen: magas a bit, ha nem, akkor alacsony)
Ha ezt érted élmátrix alatt, akkor a szkópban lehet
a következő megoldás is:
1. állítsd elő a mátrix tranzitív lezártját
2. a tranzitív lezártból könnyen jönnek
az erős komponensek egy rendezésre
visszavezethető halmaz-osztályozással
Sajnos a tranzitív lezárt számítása n^3 * log n műveletigényű,
viszont könnyen párhuzamosítható és a hw-be épített
bitműveleteket is jól kihasználja.
(Az én logikám szerint ezt a legegyszerűbb implementálni.)
Ha valaki felcsigázódott szívesen részletezem... -
-
Joooe
tag
nem tudom hogy működik ez a kód egyes fordítók lelkivilága szerint, meg most így hirtelen a szabványt sem hasítom, de nekem gyanús, hogy a kifejezés egyik oldala az unsigned char marad a kiértékelés során, és így a 256-tal szorzás mondjuk úgy egy kisebb túlcsordulást okoz
Én még nem találkoztam olyan implementációval (tudom hogy van) ahol az int ne 32 bit lenneHogy mit gondolok a nyugati civilizációról? Azt hiszem, jó ötlet lenne.
-
k.t.a.
senior tag
Mindenkinek:
Az int itt 16bit, mert PIC18F452-re lesz fordítva C18-al. Éppen a PIC miatt akarom elkerülni a szorzásokat, osztásokat, mert nem tudom biztosan, hogy a fordító mit optimalizál és mit nem. Az hogy 8-al eltolom vagy szorzom 256-al, elvilag mindegy, sőt ha nem optimalizál a fordító akkor a tologatás még jobb is. A többi meg csak a típus különbségek miatt volt.
Szerk.: és a végén az 3-al való eltolás, az nem ide tartozik, az más miatt van.
[Szerkesztve] -
Joooe
tag
Most gyorsan átlapoztam a K&R-t de nem látom annak garanciáját, hogy ez így működni fog. Ilyen méretekben valószínűleg működik, mert a hardver adottságaiból adódóan defaultból int-ként végzi el a számolást és aztán annak ''int-té castolásakor'' ugye nem történik semmi, tehát marad a helyes eredmény.
De ha ugyanezt az elvet követjük amit alkalmaztál, és ugyanakkor kevésbé vasbarát méretekig növeljük a dolgot:
unsigned __int64 mix32(unsigned __int32 h, unsigned __int32 l)
{
return (h << 32) + l;
}
esetben már túlcsordul.
unsigned __int64 mix32(unsigned __int32 h, unsigned __int32 l)
{
return ((__int64)h << 32) + l;
}
Így viszont jó.
Lehet hogy működik, de én biztosabbnak érzem mindig explicit módon castolni ilyen bites játszadozásoknál:
unsigned int assign16(unsigned char LD, unsigned char HD)
{
return ((unsigned int)HD << 8 | (unsigned int)LD) >> 3;
}
De ha ez csak az én ''szám íze'' szerint van így akkor bocsi
[Szerkesztve]Hogy mit gondolok a nyugati civilizációról? Azt hiszem, jó ötlet lenne.
-
Joooe
tag
válasz Radíros #2395 üzenetére
''Visszavonom!!!
10000 csúcssal és 64 bit gépi szószélességgel számolva:
157 * 10^8 * 14 ~ 300 GHz-es proci kellene 1mp futásidőhöz
(szekvenciálisan, csővezeték és cimzésműveletek elhanyagolva)''
Valószínűleg pontatlanul idézte a feladatot a kérdező, és csak egy konkrét csúcson átmenő köröket kell vizsgálni.Így nincs szükség a teljes tranzitív lezárt meghatározására.
Ezt azért gonodlom, mert én is egy hasonló feladatot csináltam (na nem magamnak, hál'isten az alga csak a távoli múltból dereng már nekem )
Az algoritmus érdemi részének futási idejét sikerült olyan 0,015 s-re csökkenteni ezzel a módszerrel még a leghúzósabb inputokon is. (AMD 3200 procin, párhuzamosítás nélkül)
Ami viszont iskolai szivatás a dologban: bizonyos teszt inputok esetén ha semmi mást nem csinál a program, csak kb. be >> szam; módszerrel standard folyamműveletekkel végigolvassa az inputot (De ezen kívül tényleg semmit nem csinál, nem konstruál gráfot, nem vizsgál feltételeket, stb.) már az kifut a futási időlimitből az inputok egy részén
[Szerkesztve]Hogy mit gondolok a nyugati civilizációról? Azt hiszem, jó ötlet lenne.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!