- Képernyőmentes aktivitáskövetőt mutatott be a Google, ez a Fitbit Air
- Google Pixel topik
- Yettel topik
- Milyen okostelefont vegyek?
- Samsung Galaxy A72 - kicsit király
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Android szakmai topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
-
Mobilarena
Mobilarena
Új hozzászólás Aktív témák
-
Üdv!
Akkor nincs egyszerűbb megoldás, végig kell zongorázni a karaktereken?
Erre jutottam:
int line_count = 0, byte_count = 0;
byte[] TXBuffer = new byte[262144];
byte[] hex_data = new byte[262144];
string text = System.IO.File.ReadAllText(@"L:\stk500.hex");
string[] textSplit = text.Split(':');
foreach (string line in textSplit)
{
line_count++;
foreach (byte character in line)
{
TXBuffer[byte_count++] = character;
}
}
for (int i = 0, x = 0, temp; i < byte_count; )
{
if(TXBuffer[i] <= 0x39)
{
temp = (TXBuffer[i] - 0x30)*16;
hex_data[x] += (byte)temp;
}
else if (TXBuffer[i] >= 0x41)
{
temp = (TXBuffer[i] - 0x37) * 16;
hex_data[x] += (byte)temp;
}
i++;
if (TXBuffer[i] <= 0x39)
{
temp = (TXBuffer[i] - 0x30);
hex_data[x] += (byte)temp;
}
else if (TXBuffer[i] >= 0x41)
{
temp = (TXBuffer[i] - 0x37);
hex_data[x] += (byte)temp;
}
i++; x++;
}Este még nem működött, mert ezek hex_data[x] += (byte)temp; helyett ezt hex_data[x] = (byte)temp; írtam... Jól éreztem, hogy rá kellett aludni egyet.
bucsupeti: köszönöm a segítséget!
GA
-
végigiterálsz a sztringen karakterenként. a karaktert átalakítod 0-15 közti számértékké (ascii tábla tanulmányozása után egy egyszerű kivonás lesz az átalakítás) megszorzod 16-al, majd beolvasod a következőt számmá alakítod és az előző értékhez hozzáadod. ez lesz a tömböd első eleme. ezt a metódust folytatod amíg a végére nem érsz a sztringnek.
-
-
-
Fire/SOUL/CD
félisten
-
Reinkz
senior tag
-
Ereshkigal
őstag
-
Isten hozott a lebegőpontos számok világában!
Alapvetően két csúnya dolog van velük:
1. a pontosságuk korlátozott, vagyis előbb-utóbb lesznek kerekítési hibák
2. nem tizes, hanem kettes számrendszert használnak, így a tizes számrendszerben kevés tizedesjegyből álló számok simán lehetnek végtelen tizedestörtekHa kiíratnád a MAXP*0.57 értékét, akkor valószínűleg valami olyasmit látnál, hogy 0,57000001. Emiatt lebegőpontos számoknál számolni kell azzal, hogy az egyenlőség nem fog működni és nem egzakt egyenlőséget vizsgálni, hanem azt, hogy az adott szám benne van-e valamilyen tartományban.
...amely tartomány méretét érdemes igazítani a számábrázolás pontosságához és az összehasonlított számok nagyságrendjéhez, de kis számoknál sem túl alacsonyra menni.
-
A C Példatár alapján írtam egy programot: link
0-100ig megadsz egy egész számot és megkapod az értékelést. (tudom, hogy a szám nincs vizsgálva hogy biztosan 0 és 100 közé esik-e, de tegyük fel, hogy igen)
Minden értékre jól működik, kivéve az 57-re.
MAXP = 100
MAXP*0.57 = 57Ha beírom simán a feltételnek, hogy 57 működik, ha MAXP*0.57-et adok meg, akkor viszont az 57 pontot "közepesnek" értékeli! Miért?
Isten hozott a lebegőpontos számok világában!
Alapvetően két csúnya dolog van velük:
1. a pontosságuk korlátozott, vagyis előbb-utóbb lesznek kerekítési hibák
2. nem tizes, hanem kettes számrendszert használnak, így a tizes számrendszerben kevés tizedesjegyből álló számok simán lehetnek végtelen tizedestörtekHa kiíratnád a MAXP*0.57 értékét, akkor valószínűleg valami olyasmit látnál, hogy 0,57000001. Emiatt lebegőpontos számoknál számolni kell azzal, hogy az egyenlőség nem fog működni és nem egzakt egyenlőséget vizsgálni, hanem azt, hogy az adott szám benne van-e valamilyen tartományban.
-
Szerintem mehet.
Feltéve persze, hogy nem elvárás az, hogy bármilyen valós számok lehessenek az együtthatók - akkor az inteket le kellene cserélned double-re.
Elvárás volt - és le is cseréltem őket már.
Köszi a segítséget!Mi a gyakorlati különbség a float és a double között? Annyit tudok, hogy a float memóriafoglalási mérete kisebb, mint a double-nek.
-
-
Sziasztok!
Ezzel a kóddal kapcsolatban kérnék segítséget!
Az a része jól működik, hogy megmondja a program, hány megoldása van az egyenletnek, viszont csak 0.0000-kat ad vissza eredményül.
Gondolom a "double" - "int" részek kavarodnak, de már egy ideje görcsölök rajta és sehogy se jön össze. Valaki ki tudná javítani? Tanulnék belőle.
Ha nagyon nagy logikai hibák vannak a kódomban, akkor ne javítsátok ki, csak írjátok meg és megpróbálom összerakni máshogyan!!! -
(#5274) zka67
Igen, tudom, és az adatlapban is olvastam. A 750 ms az csak akkor szükséges, ha 12 biten ábrázoltatom vele a hőmérsékletet. Próbáltam belerakni 750 ms késleltetést __delay_ms(750);-el illetve szétdarabolva, pl. 200-200-as csoportokban. Le se fut ez a függvény(halmaz). Egyszerűen csak (mintha) átugorja, és küldi a többi mért adatot. Továbbá 16 C-nál magasabb hőmérsékleten tökéletesen működik a várakozás nélkül is. Szóval nem gondolnám, de persze lehetni LEHET!
(#5273) emvy
Erre én is gondoltam, hogy ez itt nagyon gyanús, hogy amikor 15-öt (00001111)-t kéne kijelezni, akkor 127 (11111111) jön helyette. De nem jutottam semmire se. Valami konkrét(abb) ötleted van?
-
(#5274) zka67
Igen, tudom, és az adatlapban is olvastam. A 750 ms az csak akkor szükséges, ha 12 biten ábrázoltatom vele a hőmérsékletet. Próbáltam belerakni 750 ms késleltetést __delay_ms(750);-el illetve szétdarabolva, pl. 200-200-as csoportokban. Le se fut ez a függvény(halmaz). Egyszerűen csak (mintha) átugorja, és küldi a többi mért adatot. Továbbá 16 C-nál magasabb hőmérsékleten tökéletesen működik a várakozás nélkül is. Szóval nem gondolnám, de persze lehetni LEHET!
(#5273) emvy
Erre én is gondoltam, hogy ez itt nagyon gyanús, hogy amikor 15-öt (00001111)-t kéne kijelezni, akkor 127 (11111111) jön helyette. De nem jutottam semmire se. Valami konkrét(abb) ötleted van?
-
Sziasztok!
Írtam egy DS1820 hőmérő IC-hez C-ben programot PIC-re, de sajnos nem úgy működik, ahogy kéne neki.
DS1820 kód. Jól és viszonylag pontosan mér, de 16 Celsius foknál kisebb hőmérsékleteknél 127 C-t jelez ki a putty egy USB-RS485 konverteren keresztül. Más, mért adatot is küldök ugyanezen a csatornán keresztül ugyanazzal a függvénnyel, így azt nem gondolnám rossznak. Valami ötlet?
-
Sziasztok!
Írtam egy DS1820 hőmérő IC-hez C-ben programot PIC-re, de sajnos nem úgy működik, ahogy kéne neki.
DS1820 kód. Jól és viszonylag pontosan mér, de 16 Celsius foknál kisebb hőmérsékleteknél 127 C-t jelez ki a putty egy USB-RS485 konverteren keresztül. Más, mért adatot is küldök ugyanezen a csatornán keresztül ugyanazzal a függvénnyel, így azt nem gondolnám rossznak. Valami ötlet? -
fraba
aktív tag
Sziasztok!
Írtam egy DS1820 hőmérő IC-hez C-ben programot PIC-re, de sajnos nem úgy működik, ahogy kéne neki.
DS1820 kód. Jól és viszonylag pontosan mér, de 16 Celsius foknál kisebb hőmérsékleteknél 127 C-t jelez ki a putty egy USB-RS485 konverteren keresztül. Más, mért adatot is küldök ugyanezen a csatornán keresztül ugyanazzal a függvénnyel, így azt nem gondolnám rossznak. Valami ötlet? -
A szivatas arra vonatkozott, hogy tenyleg nem ismerted fel a homecomputeres BASIC-et? Mert az kb. annyira mindenki altal ismert dolog, mint Kudlik Julia.
Ki az a Kudlik Júlia?
Főiskolás koromig egyáltalán nem foglalkoztam programozással. A BASIC-hez pedig elég fiatal vagyok (24). No, most már ezt is tudom . Viszont az off-ot befejezem, mert kezd sok lenni a topicban. -
-
-
"Goto-t igazából a C korszakban igyekeztek nagyon írtani"
Valójában Dijkstra ismert cikke '68-as, a C-n meg '69-ben kezdtek el dolgozni Ritchie-ék, szóval a goto utálata megelőzi a C-t és igazából az a fajta vallásos utálat, ami bizonyos körökben megvolt a gotoval kapcsolatban, nem igazán volt indokolt.
-
"Goto-t igazából a C korszakban igyekeztek nagyon írtani"
Valójában Dijkstra ismert cikke '68-as, a C-n meg '69-ben kezdtek el dolgozni Ritchie-ék, szóval a goto utálata megelőzi a C-t és igazából az a fajta vallásos utálat, ami bizonyos körökben megvolt a gotoval kapcsolatban, nem igazán volt indokolt.
-
"Goto-t igazából a C korszakban igyekeztek nagyon írtani"
Valójában Dijkstra ismert cikke '68-as, a C-n meg '69-ben kezdtek el dolgozni Ritchie-ék, szóval a goto utálata megelőzi a C-t és igazából az a fajta vallásos utálat, ami bizonyos körökben megvolt a gotoval kapcsolatban, nem igazán volt indokolt.
-
Ettől a filetól átlag editor kiakad.
Goto-t igazából a C korszakban igyekeztek nagyon írtani, c++ esetén viszont tényleg nem nagyon van értelme leírni sem.
-
Ahogy irtam, generalt kod(kent indult).
Egyebkent meg a goto-val az a baj, hogy nagyon konnyu rosszul hasznalni. Maga a goto utasitas nem egy bun, alapvetoen. [link] (Egyebkent meg a compiler okossagatol fuggoen a while-continue lehet egy utasitassal lassabb, mint a goto..)
-
Sk8erPeter
nagyúr
Jólvan, ezt a hozzászólást már csak Lezsonak kell belinkelned, hogy c++ kulcsszóra miért nem találja meg a kereső.
Netán valaki elfelejtett escape-elni?"ezt a hozzászólást már csak Lezsonak kell belinkelned, hogy c++ kulcsszóra miért nem találja meg a kereső"
Idézőjelek közé téve a keresőszót már megtalálja a kereső a topicot: [link]. A legtöbbször így kell itt kutatni a pontosság kedvéért (legalábbis ilyen jellegű keresőszavaknál biztosan), különben elég sok fura "valami hasonló" találat jöhet ki, ami valójában nem is hasonlít (mint pl. itt az idézőjelek nélküli változat).
-
Fuggvenybe olyan funkcionalitast celszeru kiszervezni, amiket a kod tobb pontjan is hasznalsz. Az, hogy feldarabolsz egy adott funkciot tobb reszre, eleg ertelmetlen (bar sokan azt valljak, hogy egy fuggveny ne legyen hosszabb X sornal, de ez szerintem butasag).
Majd amikor egy 3000 soros legacy fgv kell 100%san lefedve le UT-znod, akkor biztos nem fogod azt mondani, hogy milyen jó, hogy nincsen szétbontva.
-
"APL(-szeru) nyelven neztem bazi hosszu, teljesen strukturalatlan kodokat - ott ugye nem jellemzoek a fuggvenyek, viszont az sem, hogy regesreg krealt ertekeket hasznalsz sokkal-sokkal kesobb; inkabb sok-sok egymas utan kovetkezo es egymasra epulo lepest irnak le."
Azert ott is joval olvashatobb es kovethetobb lesz a kod, ha ugy nez ki, hogy van egy fuggvenyed, hogy
do_something_complex()
{
do_something_simple();
do_something_even_simpler();
// ...
}es az egyes lepeseket kirakod sajat fuggvenybe. A fordito meg ugyis inline-olja a fuggvenyeket, szoval meg csak lassabb se lesz.
A k/q write only, akarhogy strukturalsz
Ha meg van code folding, akkor
#region Do something complex
do_something_simple();
do_something_even_simpler();
#endregionDe ha sima C-rol van szo, akkor igazabol nincs gyakorlati tapasztalatom real life, szoval elfogadom, ami mondasz.
-
C/C++-ban tenyleg nem (amikor azzal dolgoztam, akkor maniakus overengineering ment a fejlesztes soran, es az kod nagy resze pure virtual osztalyokbol epult fel
), mas nyelvekben lattam hasonlot, de nem volt extra szenvedes, ez teny. (Es 40 agas switch/case szerkezetekkel se sokat talalkoztam, ez is teny; nem tudom, hogy ez szerencse, vagy tapasztalatlansag 
.)Mondjuk azert masrol beszelunk. En azt mondtam, hogy onmagaban a fuggveny hossza nem problemas, te meg azzal jossz, hogy ha nagyon bonyolult switch/case szerkezetek vannak, vagy a valtozok deklaracioja/ertekadasa es felhasznalasa kozott van 40 kepernyonyi kod, az problemas. Ezt elfogadom/elhiszem, de ugye itt nem a kod hosszaval van a gond -- a kod hossza az kovetkezmenye a problemanak, de nem az oka.
APL(-szeru) nyelven neztem bazi hosszu, teljesen strukturalatlan kodokat - ott ugye nem jellemzoek a fuggvenyek, viszont az sem, hogy regesreg krealt ertekeket hasznalsz sokkal-sokkal kesobb; inkabb sok-sok egymas utan kovetkezo es egymasra epulo lepest irnak le. Peldaul ilyen esetben semmi problema nincs a hosszu koddal.
De tenyleg nem tudok az erveddel vitatkozni
-
"Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio."
Nem csak a navigacio, hanem a fuggveny atlathatosaga is: ugyanis ilyen szerkezetnel siman elofordul, hogy olyan valtozokra hivatkoznak, aminek par szaz sorral korabban adtak valami erteket. (Ami IDE-kkel eddig talalkoztam, azok csak a komplett switchet tudtak osszehajtogatni, az egyes case agakat nem)
Bocs, de most tenyleg nagyon latszik, hogy soha az eletben nem kellett ilyenekkel szenvedned, azert nem gondolod ezt problemasnak
C/C++-ban tenyleg nem (amikor azzal dolgoztam, akkor maniakus overengineering ment a fejlesztes soran, es az kod nagy resze pure virtual osztalyokbol epult fel
), mas nyelvekben lattam hasonlot, de nem volt extra szenvedes, ez teny. (Es 40 agas switch/case szerkezetekkel se sokat talalkoztam, ez is teny; nem tudom, hogy ez szerencse, vagy tapasztalatlansag .)Mondjuk azert masrol beszelunk. En azt mondtam, hogy onmagaban a fuggveny hossza nem problemas, te meg azzal jossz, hogy ha nagyon bonyolult switch/case szerkezetek vannak, vagy a valtozok deklaracioja/ertekadasa es felhasznalasa kozott van 40 kepernyonyi kod, az problemas. Ezt elfogadom/elhiszem, de ugye itt nem a kod hosszaval van a gond -- a kod hossza az kovetkezmenye a problemanak, de nem az oka.
APL(-szeru) nyelven neztem bazi hosszu, teljesen strukturalatlan kodokat - ott ugye nem jellemzoek a fuggvenyek, viszont az sem, hogy regesreg krealt ertekeket hasznalsz sokkal-sokkal kesobb; inkabb sok-sok egymas utan kovetkezo es egymasra epulo lepest irnak le. Peldaul ilyen esetben semmi problema nincs a hosszu koddal.
De tenyleg nem tudok az erveddel vitatkozni
-
Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio. Ennek a megkonnyitese szerintem az IDE dolga lenne, nem a programszervezese, es a modern IDEk mar szoktak tudni fold/collapse funkciot C++-ra is, ha jol gondolom. .Net-ben ott a #region pragma, ami pont erre valo; Java-ban a sok patternhuszar ugyis haromsoros classokba szervez mindent (
![;]](//cdn.rios.hu/dl/s/v1.gif)
), funkc. nyelvek meg altalaban tul tomorek ahhoz, hogy ilyen hosszu fuggvenyeket irjon az ember."Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio."
Nem csak a navigacio, hanem a fuggveny atlathatosaga is: ugyanis ilyen szerkezetnel siman elofordul, hogy olyan valtozokra hivatkoznak, aminek par szaz sorral korabban adtak valami erteket. (Ami IDE-kkel eddig talalkoztam, azok csak a komplett switchet tudtak osszehajtogatni, az egyes case agakat nem)
Bocs, de most tenyleg nagyon latszik, hogy soha az eletben nem kellett ilyenekkel szenvedned, azert nem gondolod ezt problemasnak
-
"bar sokan azt valljak, hogy egy fuggveny ne legyen hosszabb X sornal, de ez szerintem butasag"
Ezt csak azert mondod, mert meg nem kellett olyan fuggvenyeket kibogoznod, amikor tobb ezer sor hosszuak voltak, bennuk tobbszorosen egymasba agyazott switchekkel, ami azt eredmenyezi, hogy a "hol vagyok a kodban?" kerdesre a valaszt tobb perces scrollozgatas adja meg.
Igazabol ha egy fuggveny kezd hosszu lenni (mittomen, tobb, mint szaz soros), akkor erdemes eltoprengeni azon, hogy nem lenne-e erdemes megis szetszedni. Erre persze lehet az is a valasz, hogy "nem", de azert toprengeni erdemes.
Tehat vegulis az ok, amiert szet akarod szedni, az a konnyebb navigacio. Ennek a megkonnyitese szerintem az IDE dolga lenne, nem a programszervezese, es a modern IDEk mar szoktak tudni fold/collapse funkciot C++-ra is, ha jol gondolom. .Net-ben ott a #region pragma, ami pont erre valo; Java-ban a sok patternhuszar ugyis haromsoros classokba szervez mindent (
), funkc. nyelvek meg altalaban tul tomorek ahhoz, hogy ilyen hosszu fuggvenyeket irjon az ember. -
Helyes. Azt hittem, hogy már senki nem foglalkozik ezzel
. Ennek a megoldásnak az a lényege, hogy olyan függvényt használjunk, aminek van valamilyen visszatérési értéke (printf-el is lehetett volna), és hogy egy ciklus vagy elágazás kiértekélésekor hi'vjuk meg ezt a bizonyos függvényt.Másik? [link] (cask vessző helyett pontos vesszővel, és lefordi'tani nem illik)
Hát nekem elsőre gyanús volt a nulla, de a biztonság kedvéért csak megpróbáltam lefordítani is
-
"bar sokan azt valljak, hogy egy fuggveny ne legyen hosszabb X sornal, de ez szerintem butasag"
Ezt csak azert mondod, mert meg nem kellett olyan fuggvenyeket kibogoznod, amikor tobb ezer sor hosszuak voltak, bennuk tobbszorosen egymasba agyazott switchekkel, ami azt eredmenyezi, hogy a "hol vagyok a kodban?" kerdesre a valaszt tobb perces scrollozgatas adja meg.
Igazabol ha egy fuggveny kezd hosszu lenni (mittomen, tobb, mint szaz soros), akkor erdemes eltoprengeni azon, hogy nem lenne-e erdemes megis szetszedni. Erre persze lehet az is a valasz, hogy "nem", de azert toprengeni erdemes.
-
-
Fuggvenybe olyan funkcionalitast celszeru kiszervezni, amiket a kod tobb pontjan is hasznalsz. Az, hogy feldarabolsz egy adott funkciot tobb reszre, eleg ertelmetlen (bar sokan azt valljak, hogy egy fuggveny ne legyen hosszabb X sornal, de ez szerintem butasag).
Értem, köszi a választ. Ettől függetlenül egyelőre nekem már az is nagy előrelépés lenne, ha ki tudnám szervezni magamtól! Ha legalább az egyiket megkaphatnám, az alapján megcsinálnám a másikat. Tanulni szeretnék belőle!
-
Helyes. Azt hittem, hogy már senki nem foglalkozik ezzel
. Ennek a megoldásnak az a lényege, hogy olyan függvényt használjunk, aminek van valamilyen visszatérési értéke (printf-el is lehetett volna), és hogy egy ciklus vagy elágazás kiértekélésekor hi'vjuk meg ezt a bizonyos függvényt.Másik? [link] (cask vessző helyett pontos vesszővel, és lefordi'tani nem illik)
-
-
Vetnétek egy pillantást a kódomra?
Itt a tutorial videó és itt az én kódom.
A kérdésem az volna ezzel kapcsolatban, hogy mi a különbség az egyszerű "if" és az "else-if" között? A fenti tutorial alapján készítettem el a kódot, de a srác az összes állítást külön "if"-ekként kezelte, én pedig egyetlen "if"-nek az "else" ágán mentem tovább.
Esetleg valamelyik gyorsabban lefut? A Microsoft Visual Studio-t használom, hol találom benne a program gyorsaságát? Mi a véleményetek a kódom tagoltságáról? (építő jellegű kritikát szeretnék kapni)
"A kérdésem az volna ezzel kapcsolatban, hogy mi a különbség az egyszerű "if" és az "else-if" között?"
Az, hogy sima if-eknél (megfelelő feltételek esetén) a program akár az összes if-be belemehet, if-else-eknél viszont legfeljebb csak egybe. Neked itt pont az else-if kell, mert egymást kölcsönösen kizáró feltételeid vannak.
"Esetleg valamelyik gyorsabban lefut?"
Ez is benne van, ha if-else-eknél belemegy valamelyik ágba, akkor utána a komplett blokk végére ugrik, nem nézi meg a többi feltételt. Mondjuk ez olyan különbség, ami tipikusan olyan kicsi, hogy mérések sem mutatják ki.
"A Microsoft Visual Studio-t használom, hol találom benne a program gyorsaságát?"
VS 2013-ban van profiler, de őszintén szólva nem hiszem, hogy jelenleg neked erre bármi szükséged lenne. Az ekkora programok futási ideje bőven mérési hibán belül van.
"Mi a véleményetek a kódom tagoltságáról?"
Így azért jóval olvashatóbb (ez az else-if szokásos írásmódja):
int main(void)
{
float num1, num2;
printf("Enter two numbers\nFirst: "); scanf("%f", &num1);
printf("Second: "); scanf("%f", &num2);
if (num1 == num2)
{
printf("They are equal: %f = %f", num1, num2);
}
else if (num1 > num2)
{
printf("They are not equal, %f > %f", num1, num2);
}
else
{
printf("They are not equal, %f < %f", num1, num2);
}
getch();
return 0;
}Ezen túlmenően ekkora kódnál azért különösebb tagoltságról nem lehet beszélni
ÁLtalános megjegyzésként még annyi, hogy lebegőpontos számoknál a == csak nagyon korlátozottan használható (itt mondjuk pont igen), mert ott a kerekítési hibák miatt előfordulhat, hogy két érték, aminek elméletben azonosnak kellene lennie, mégsem lesz pont ugyanannyi.
-
Ereshkigal
őstag
Vetnétek egy pillantást a kódomra?
Itt a tutorial videó és itt az én kódom.
A kérdésem az volna ezzel kapcsolatban, hogy mi a különbség az egyszerű "if" és az "else-if" között? A fenti tutorial alapján készítettem el a kódot, de a srác az összes állítást külön "if"-ekként kezelte, én pedig egyetlen "if"-nek az "else" ágán mentem tovább.
Esetleg valamelyik gyorsabban lefut? A Microsoft Visual Studio-t használom, hol találom benne a program gyorsaságát? Mi a véleményetek a kódom tagoltságáról? (építő jellegű kritikát szeretnék kapni)
-
Ereshkigal
őstag
-
Ejj, ha!
No, akkor okítsunk.
Először is: osztóJa!
Másodszor: szájbaszexuálnád a nevemben, aki arra nevel, hogy magyar változóneveket és függvényneveket használjatok?
Harmadszor: Optimalizáljunk:
-Ha a megadott szám kisebb, mint 1000, akkor elég a megadott számig menni. Tehát a ciklusfeltétel: i<min(n,1000). Illetve ennek is elég a feléig menni, mert különben ugyanazokat a számokat találod meg fordítva. Tehát i<=min(n,1000)/2. Azért kisebbegyenlő, mert kihasználtam gonoszul az egész osztást.
-Gondolkodjunk is: a második ciklus tök felesleges. Minden számhoz csak egy másik olyan tartozik, amivel összeadva az öszeg n lesz. Tehát, amit vizsgálnod kell: prime(i) && prime(n-i). Ezzel kész is vagy.Tehát:
for(i=1;i<=min(n,1000)/2;i++)
{
if(prime(i) && prime(n-i))
{
printf(...);
}
}No, ez már így nem is lenne rossz, most már cak a prímtesztelést kell kicsit okosítani. Maradjunk a primitív módszereknél, de ennél azért kicsit okosabban. Ha egy szám nem prím, akkor előáll két szám szorzataként. Ebből a kettőből az egyik kisebb, vagy egyenlő, mint a gyöke, tehát elég addig nézni.
Osztókat számolni tök felesleges, az első osztónál ugyanis biztosan nem lehet prím.Tehát:
for(i=2;i<=sqrt(n);i++)
{
if(!n%i) //csalok: ez akkor igaz, ha a maradékos osztás maradéka 0 - tehát osztható
{
return false; //van osztója, ami nem egy és nem önmaga
}
}
return true; //ha a gyökéig nem volt osztója, biztos prím.Máris mennyivel szebb, ugye?
Köszi, nem tudom, miért ly-t irtam
Nem tanitjak, hogy magyar valtozoneveket hasznaljunk, csak "beszedeseket", ez mar az en hulyesegem, hogy itt magyarul irtam
.A tobbit is koszonom, vegul ez lett belole, igy mar normalisan megy
-
Tenyleg belekavarodtal.
A negativ hatvanyok (amit egy gyors Google-kereses is megmond
) osztast jelentenek. A negativ szamokat C-ben kettes komplemenssel abrazoljak, olvasd el ezt.Egy kicsit magas nekem ez a számábrázolás... mennyire kell ezt vágni így a "programozói karrierem" hajnalán?
-
Ejj, ha!
No, akkor okítsunk.
Először is: osztóJa!
Másodszor: szájbaszexuálnád a nevemben, aki arra nevel, hogy magyar változóneveket és függvényneveket használjatok?
Harmadszor: Optimalizáljunk:
-Ha a megadott szám kisebb, mint 1000, akkor elég a megadott számig menni. Tehát a ciklusfeltétel: i<min(n,1000). Illetve ennek is elég a feléig menni, mert különben ugyanazokat a számokat találod meg fordítva. Tehát i<=min(n,1000)/2. Azért kisebbegyenlő, mert kihasználtam gonoszul az egész osztást.
-Gondolkodjunk is: a második ciklus tök felesleges. Minden számhoz csak egy másik olyan tartozik, amivel összeadva az öszeg n lesz. Tehát, amit vizsgálnod kell: prime(i) && prime(n-i). Ezzel kész is vagy.Tehát:
for(i=1;i<=min(n,1000)/2;i++)
{
if(prime(i) && prime(n-i))
{
printf(...);
}
}No, ez már így nem is lenne rossz, most már cak a prímtesztelést kell kicsit okosítani. Maradjunk a primitív módszereknél, de ennél azért kicsit okosabban. Ha egy szám nem prím, akkor előáll két szám szorzataként. Ebből a kettőből az egyik kisebb, vagy egyenlő, mint a gyöke, tehát elég addig nézni.
Osztókat számolni tök felesleges, az első osztónál ugyanis biztosan nem lehet prím.Tehát:
for(i=2;i<=sqrt(n);i++)
{
if(!n%i) //csalok: ez akkor igaz, ha a maradékos osztás maradéka 0 - tehát osztható
{
return false; //van osztója, ami nem egy és nem önmaga
}
}
return true; //ha a gyökéig nem volt osztója, biztos prím.Máris mennyivel szebb, ugye?
Gondolkodjunk is: a második ciklus tök felesleges. Minden számhoz csak egy másik olyan tartozik, amivel összeadva az öszeg n lesz.
Jogos!
-
Ejj, ha!
No, akkor okítsunk.
Először is: osztóJa!
Másodszor: szájbaszexuálnád a nevemben, aki arra nevel, hogy magyar változóneveket és függvényneveket használjatok?
Harmadszor: Optimalizáljunk:
-Ha a megadott szám kisebb, mint 1000, akkor elég a megadott számig menni. Tehát a ciklusfeltétel: i<min(n,1000). Illetve ennek is elég a feléig menni, mert különben ugyanazokat a számokat találod meg fordítva. Tehát i<=min(n,1000)/2. Azért kisebbegyenlő, mert kihasználtam gonoszul az egész osztást.
-Gondolkodjunk is: a második ciklus tök felesleges. Minden számhoz csak egy másik olyan tartozik, amivel összeadva az öszeg n lesz. Tehát, amit vizsgálnod kell: prime(i) && prime(n-i). Ezzel kész is vagy.Tehát:
for(i=1;i<=min(n,1000)/2;i++)
{
if(prime(i) && prime(n-i))
{
printf(...);
}
}No, ez már így nem is lenne rossz, most már cak a prímtesztelést kell kicsit okosítani. Maradjunk a primitív módszereknél, de ennél azért kicsit okosabban. Ha egy szám nem prím, akkor előáll két szám szorzataként. Ebből a kettőből az egyik kisebb, vagy egyenlő, mint a gyöke, tehát elég addig nézni.
Osztókat számolni tök felesleges, az első osztónál ugyanis biztosan nem lehet prím.Tehát:
for(i=2;i<=sqrt(n);i++)
{
if(!n%i) //csalok: ez akkor igaz, ha a maradékos osztás maradéka 0 - tehát osztható
{
return false; //van osztója, ami nem egy és nem önmaga
}
}
return true; //ha a gyökéig nem volt osztója, biztos prím.Máris mennyivel szebb, ugye?
-
-
-
Nem, nem fér el, lásd: [link].
(#5216) EQMontoya: Tényleg pontos vessző kellett volna. Elég régen kellett már bitfield-el mókolni, így nem voltam biztos, hogy vessző vagy pontos vessző kell. Ebben igazat adok, viszont a feladat továbbra is adott. Mennyi a mérete a bitfield-nek?
-
Tenyleg belekavarodtal.
A negativ hatvanyok (amit egy gyors Google-kereses is megmond
) osztast jelentenek. A negativ szamokat C-ben kettes komplemenssel abrazoljak, olvasd el ezt.Köszönöm szépen! Ahogy elolvastam a hozzászólásodat, rögtön beugrott a negatív hatványozás is... 2^-1 = 1/2^1, stimmel már!!! A számábrázolásról szóló Wiki cikket pedig átolvasom!
-
Sziasztok!
Most kezdem a C programozást és beleütköztem néhány (feltételezem bagatell) problémába a változók értéktartományaival kapcsolatban. A kérdéseimet összeírtam és szemléltettem egy táblázatban! Lennétek szívesek válaszolni rájuk? Szívesen fogadok olvasnivalót is!
Itt megtaláljátok a PDF állományt!
Köszönöm előre is!
Tenyleg belekavarodtal.
A negativ hatvanyok (amit egy gyors Google-kereses is megmond
) osztast jelentenek. A negativ szamokat C-ben kettes komplemenssel abrazoljak, olvasd el ezt. -
Te is létrehozhatod...
Egy másik érdekesség:
typedef struct
{
int a : 4,
int b : 0,
int c : 6,
} struct_s;Mennyi lesz a sizeof(struct_s) visszatérési értéke, ha int 32 bit hosszú? Miért?
Ebben a formában semmit, mert nem fordul le.
program.cc:6:1: error: expected unqualified-id before ‘int’
int b : 0,De ha kicseréli az ember pontosvesszőre...
Na, akkor sem fordul le, de a hibaüzi sokat elmond arra vonatkozóan, amit kérdezni akartál:program.cc:6:13: error: zero width for bit-field ‘<anonymous struct>::b’
int b : 0;De ha a b értékét 1-re módosítod ez után, akkor már egész jó a feladat.
-
Ez C topic és nem C++. Kéretik tiszteletben tartani.
Viszont, ha már itt tartunk, akkor egy feladvány:
Irasd ki a Hello world! szöveget C porgram segítségével úgy, hogy nincs a programban egy pontos vessző sem. Nem fordítás alatt, hanem bináris futtatással.Oke, linkeld be pls a c++ topicot!
-
enum E
{
E1,
};
struct P
{
P(unsigned int x) {}
};struct A
{
P p1;
A(const P& pr): p1(pr){};
};struct B
{
A a1;
B(const A& ar): a1(ar){};
};int main()
{
A a1(P(0 ));
B b1(a1);A a2(P(E1 ));
B b2(a2);
return 0;
}O bazz, X perce nezem mar, hogy ez mi a fene.
Az enum-ot meg az unsigned parametert ki is hagyhatnad a trukkbol, csak elvonja a figyelmet Hint, ha mas se latja meg elsore: ket karakterrel meg lehet fixalni.
-
-
"Egy okosan megírt gettert miért ne tudnál inline-olni?"
Azért, mert mivel függvénypointerről van szó, fordításkor ki se derül, hogy pont mit is kellene inline-olni.
Egyébként nagyon szórakoztató ez a "hogyan jussunk el Óbudáról Békásmegyerre - űrrepülővel" társalgás
Bringaval mindenki el tud, az nem erdekes
-
"Egy okosan megírt gettert miért ne tudnál inline-olni?"
Azért, mert mivel függvénypointerről van szó, fordításkor ki se derül, hogy pont mit is kellene inline-olni.
Egyébként nagyon szórakoztató ez a "hogyan jussunk el Óbudáról Békásmegyerre - űrrepülővel" társalgás
Func ptr-t nyilván nem, nem is arra értettem.
Azért tegyük fel, hogy legalább minimálisab objektum-orientáltan kódolunk mátrixot, és annak műveleteit. Ott simán lehet írni inline-olt gettert.Egyébként teljesen jogos, de muszáj volt beletrollkodnom. Mint láthatod, nem csak bennem merült fel.
Illetve, ha már itt észt osztok, mai c++ lecke: egy argumentumos, POT-ot váró konstruktor legyen explicit, ha lehet.
Ha nem az, akkor olyan mókásságokba futhat bele a zember fia, mint egy rossz copy-paste után leforduló bool paraméterrel meghívott függvény, mint egy saját, file system path osztályt vár paraméterül. -
Egy okosan megírt gettert miért ne tudnál inline-olni?
Egy jó iterátor sem lesz lassabb a transzponáltra, mint a simára, csak a ++ operátora lesz más."Egy okosan megírt gettert miért ne tudnál inline-olni?"
Azért, mert mivel függvénypointerről van szó, fordításkor ki se derül, hogy pont mit is kellene inline-olni.
Egyébként nagyon szórakoztató ez a "hogyan jussunk el Óbudáról Békásmegyerre - űrrepülővel" társalgás
-
Viszont ez minden elem elérésnél egy indirekt függvényhívás amit nem tud a fordító inline beágyazni. Bizonyos mennyiség fölött garantáltan sokkal lassabb lesz, mintha ténylegesen transzponáltad volna.
A másik, hogy a cache hatékonyságát nagyban befolyásolja a bejárás. Egy sorfolytonos bejárás sokkal gyorsabb lehet mint egy oszlopok szerinti. Az algoritmust ennek megfelelően választhattad meg, de ha a hívó egy függvénypointeresen transzponált mátrixot ad be, akkor amire a kód azt hiszi, hogy hatékony sorfolytonos az valójában nem az. Ugye bizonyos műveleteknél ezért éri meg ténylegesen transzponálni a mátrixot, a bejárás megváltoztatása helyett, még akkor is ha amúgy nincs függvénypointeres trükközés. Lásd még What every programmer should know about memory: "Through the simple transformation of the matrix we can achieve a 76.6% speed-up! The copy operation is more than made up. The 1000 non-sequential accesses really hurt. "
Virtuális mátrixokhoz viszont kétségkívül jó megoldás lehet.
-
> "Bizonyos mennyiség fölött garantáltan sokkal lassabb lesz, mintha ténylegesen transzponáltad volna."
Algoritmustol fugg. Ha kevesszer transzponalsz, de sokszor olvasol, akkor igen. Ha sokszor transzponalsz, es kevesszer olvasol, akkor a te megoldasod lehet drasztikusan lassabb. Ha pl. marha nagy matrixokkal dolgozol, de a transzponalt matrixot felhasznalo fel minden matrixbol csak nehany elemet vesz ki, akkor a lazy megoldas a jobb.
-
Viszont ez minden elem elérésnél egy indirekt függvényhívás amit nem tud a fordító inline beágyazni. Bizonyos mennyiség fölött garantáltan sokkal lassabb lesz, mintha ténylegesen transzponáltad volna.
A másik, hogy a cache hatékonyságát nagyban befolyásolja a bejárás. Egy sorfolytonos bejárás sokkal gyorsabb lehet mint egy oszlopok szerinti. Az algoritmust ennek megfelelően választhattad meg, de ha a hívó egy függvénypointeresen transzponált mátrixot ad be, akkor amire a kód azt hiszi, hogy hatékony sorfolytonos az valójában nem az. Ugye bizonyos műveleteknél ezért éri meg ténylegesen transzponálni a mátrixot, a bejárás megváltoztatása helyett, még akkor is ha amúgy nincs függvénypointeres trükközés. Lásd még What every programmer should know about memory: "Through the simple transformation of the matrix we can achieve a 76.6% speed-up! The copy operation is more than made up. The 1000 non-sequential accesses really hurt. "
Virtuális mátrixokhoz viszont kétségkívül jó megoldás lehet.
Főiskolás koromig egyáltalán nem foglalkoztam programozással. A BASIC-hez pedig elég fiatal vagyok (24). No, most már ezt is tudom 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), mas nyelvekben lattam hasonlot, de nem volt extra szenvedes, ez teny. (Es 40 agas switch/case szerkezetekkel se sokat talalkoztam, ez is teny; nem tudom, hogy ez szerencse, vagy tapasztalatlansag 
.)
.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Luck Dragon: Asszociációs játék. :)
- Robot fűnyírók
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Kazy Computers - Fehérvár - Megbízható?
- Képernyőmentes aktivitáskövetőt mutatott be a Google, ez a Fitbit Air
- Bundle topik
- Google Pixel topik
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Óra topik
- Nintendo Switch
- További aktív témák...
- Garanciális samsung galaxy watch 8 classic
- Samsung QVO 870 SSD (1 TB) 100/100%
- Új, bontatlan - Apple MacBook Air 13 M4 16/256GB - Sky Blue
- Új Dobozos ASUS VivoBook Go 15 Laptop 15,6" -20% Ryzen 5 7520U 16/512 Radeon Graphics FHD OLED
- Új HP ZBook Firefly 16 G10 Profi Tervező Vágó Laptop -50% i7-1355U 16/1TB FHD+ RTX A500 4GB
- Apple Mac mini M1 2020 - 16GB/256GB SSD - Erősebb verzió! - Szép/Megkímélt állapotban
- HP EliteBook 845 G7 14" Ryzen 5 pro 4650U, 8-16GB RAM, 256-512GB SSD, jó akku, számla, 6 hó gar
- Telefon felvásárlás!! Honor Magic8 Lite / Honor Magic8 Pro
- Apple iPhone SE 2020 64GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Latitude 5290, 2 az 1 ben,12.5",FHD,i5-8350U,8GB DDR4,256GB SSD,WIN11
Állásajánlatok
Cég: aiMotive Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest