Hogy tudom megvizsgálni, hogy egy szám egész-e?

#8:

Ügyes, és profi!

Csak a magam kedvéért tegnap én is csináltam egy hasonló, millió ciklusos tesztet, bár kicsit eltérő eredmények jöttek ki (valószínűleg a gyengébb celeron proci miatt), de azért beírom:

- round 69ms

- int 79ms

- trunc 109ms

- frac 109ms

Az első hozzászólásban az Int-et akartam beleírni, de mivel a kérdező a trunc-ot említette, így átírtam, csak az első sort felejtettem kitörölni...

18:15

Pascalban nem az a modulo operátor és nem is olyan "okos".

Az egyenlő e vizsgálat sem "==".

> Ha olyan okos gyerek vagy akkor tudhatnád, hogy pascalban nincs return.

Nem, valóban nem tudom, 8 éve nem foglalkoztam pascal alapú nyelvekkel. De örülök, hogy így sikerült kicsapnom nálad a biztosítékot ezzel.

> Továbbá Double értéket vár a függvényed és boolean értéket próbálsz átadni neki

Valóban, elírtam.

> ez nem gyenge típusos mint a C hogy elfogadja, ez erősen típusos nyelv

Ki kell, hogy ábrándítsalak; a C is erősen típusos nyelv. Az "elfogadja" alatt pedig jó szándékból feltételezem, hogy a kasztolást értetted.

> Kipróbáltam 1 millió trunc, frac és round hívást külön külön.

Kipróbáltál 3 módszert - amiből az egyik (round) eleve baromság -, és persze az én megoldásom eleve rossz, tehát az minek is mérnéd le. Kijelented, hogy az egyik király, meg amúgy sem ezen múlik mert a képernyőre írás még több idő.

Én lemértem neked a round-ot és 10sec jött ki, igaz kortyoltam egyet a kávémból közben, de hát ez úgy sem számít a multitaszk miatt, meg hát a kávé lefőzése amúgy is több időt vett el jóval. Ezt jobb ha elhiszed nekem, kódot, referenciát úgy sem teszek közzé...

De még mielőtt még egy script-kiddie leméri itt nekem a round()-ot:

[link]

> if (szam%1==0) then write("egész") else write("tört")

Made my day

[link] egy Delphi-ben írt szösszenet, 10 000 000 !!! függvényhívással:

function Trunc_e(const szam : real): boolean;

begin

Result := szam - Trunc(szam) = 0;

end;

function Frac_e(const szam : real): boolean;

begin

Result := Frac(szam) = 0;

end;

function Int_e(const szam : real): boolean;

begin

Result := szam - Int(szam) = 0;

end;

function Round_e(const szam : real): boolean;

begin

Result := szam - Round(szam) = 0;

end;

egész és törtszámra, négyszer egymás után. Egy régi P4-en sem megy 1000 ms felé.

Nem tudom te mit írtál és min futtatad :)

"Nem, valóban nem tudom, 8 éve nem foglalkoztam pascal alapú nyelvekkel. De örülök, hogy így sikerült kicsapnom nálad a biztosítékot ezzel."

"> Továbbá Double értéket vár a függvényed és boolean értéket próbálsz átadni neki

Valóban, elírtam. "

Az értékelem, hogy bevallod, hogy tévedtél, de most csaptad ki a biztosítékot nem akkor.

"Ki kell, hogy ábrándítsalak; a C is erősen típusos nyelv. Az "elfogadja" alatt pedig jó szándékból feltételezem, hogy a kasztolást értetted."

A pascalhoz képest gyenge típusos.

Pascalban : [link] Fordítási, hiba, de ha "function f(n:double):double;" helyett "function f(n:double):boolean;"-t írunk egyből semmi fordítási hiba.

C-ben : [link] Még csak warning-ot sem ír rá.

"Kipróbáltál 3 módszert - amiből az egyik (round) eleve baromság"

Létezik olyan , hogy round, nem én találtam ki: [link]

Miért lenne baromság? Jó szándékból feltételezem, bele akartál kötni valakibe ec pec kimehetsz legyen ez a roundos válaszadó.

"és persze az én megoldásom eleve rossz, tehát az minek is mérnéd le."

Pascalban nem fordul le és pascalról volt szó, ami le sem fordul azon nincs mit mérni. Most lemértem le c-ben az is 10 milisec körül van mint a round.

"Kijelented, hogy az egyik király, meg amúgy sem ezen múlik mert a képernyőre írás még több idő."

Nem azon múlik, azért írtam hogy ha te is véletlenül olyan elmebeteg lennél mint akiről írtam akkor legalább kellemesen csalódsz a roundban.

"Én lemértem neked a round-ot és 10sec jött ki, igaz kortyoltam ..."

No komment :(

"Delphi-ben írt szösszenet, 10 000 000 !!! függvényhívással: ... egész és törtszámra, négyszer egymás után. Egy régi P4-en sem megy 1000 ms felé.

Nem tudom te mit írtál és min futtatad :)"

Elhiszem.

> A pascalhoz képest gyenge típusos.

Egyáltalán nem. Valamit félre/nem értettél.

Ennek igazán utána nézhettél volna; Pascalban nincs implicit kasztolás, csak explicit. C-ben viszont van mindkettő. Ettől még erősen típusos, hiszen konverzió történik.

Nem tudom, hogy honnan szedted, hogy a C gyengén típusos nyelv, de ez borzalmas nagy sületlenség. Remélem sikerült megértetni veled miért.

> Pascalban : Fordítási, hiba

> C-ben : Még csak warning-ot sem ír rá.

Valójában ír rá warning-ot, de a ideone ezeket nem írja ki. Gyakorlatilag azért szól, a fordító, hogy implicit konverzió történik. Ami természetesen nem számít hibának, ellentétben egyes kevésbé korszerű nyelvekben.

> Létezik olyan, hogy round ... Miért lenne baromság?

*Sóhaj* A round(x) függvény nem más mint egy trunc(x + 0.5), ha nem hiszed nézd meg disassembly-vel. A következő dolog miatt tartom baromságnak: Míg az

n - trunc(n) < epsilon

logikai kifejezés helyes és adott epsilon-ra stabil, a

n - round(n) < epsilon

helytelen. Vegyük csak a 3.9-et példának: 3.9 - 4 = -0.1, ami kisebb mint nulla; tehát a visszatérési érték igaz lesz, ami ebben az esetben helytelen.

inb4 Miért nem egyelőégjelet használsz?

Mert azzal nem lenne stabil az algoritmus; Vegyük a következő példát: A 10E+11 számra (ami ugye egész) a te megoldásod hamissal tér vissza.

Ajánlom figyelmedbe a IEEE754-ös szabványt.

> ha te is véletlenül olyan elmebeteg lennél mint akiről írtam

Ha elmebetegségnek számít, hogy 3x gyorsabb, stabil és mellesleg HELYES megoldást adtam, akkor igen az vagyok. Legalábbis számodra...

> Pascalban nem fordul le és pascalról volt szó, ami le sem fordul azon nincs mit mérni.

8 év után vétettem 2 szintaktikai hibát. Egyszerűbb lett volna, ha azt mondod, hogy nem értetted.

"> A pascalhoz képest gyenge típusos.

Egyáltalán nem. Valamit félre/nem értettél.

Ennek igazán utána nézhettél volna; Pascalban nincs implicit kasztolás, csak explicit. C-ben viszont van mindkettő. Ettől még erősen típusos, hiszen konverzió történik. "

Az "f" függvény pont, hogy működne pascalban is akkor ha ugyanannyira lenne külön logikai típus mint c-ben, ugyanis c-ben nincs. C-ben egy int-et kasztol double, pascalban is lehet int-et rakni double-be (csak ott épp integer-nek vagy logint-nak hívják, de ez részletkérdés).

Csak egy példát mondok: Pascalban lehet byte tömböt csinálni aminek az elemei byte típusúak (a típus neve byte), lehet char tömböt is csinálni. Ez 2 féle tömb. C-ben is meg lehet csinálni, de ott nem kétféle hanem egyféle. Önmagában nem derül ki, hogy karaktereket vagy kis egész számokat akarok tárolni. Gyengén típusus nyelvben fontos megfelölni a VÁLTOZÓ NEVÉBEN, hogy milyen típusúnak használod. Legyen egy c nevű változónk tömb helyett ami c nyelven c='A'; és c=45; mindkettőt elfogadja a fordító. Pascalban c:='A'; és c:=54; egyszerre nem fogadja el a változó egyazon c változóra, az erős típusrendszer miatt. Nem akarok belemenni de az Ada nyelv azaz igazán erőssen típusos ahhoz képest a pascal is gyengén típusos. Gépi kódba ugyanolyan byte a char és a byte, de nyelvi szinten mégsem.

"Valójában ír rá warning-ot, de a ideone ezeket nem írja ki. "...

Nekem nem ír ki, de oké mondjuk hogy ír. Ez attól függ egyébként, hogy mi az alapértelemzett beállítás vagy milyen kapcsolókkal fordítjuk.

"*Sóhaj* A round(x) függvény nem más mint egy trunc(x + 0.5), ha nem hiszed nézd meg disassembly-vel."

Nem az történik, a futási időből látszik anélkül, hogy megnézném. Ha meghívná a trunc-ot és hozzáadna 0.5-öt akkor futási időben rosszabb lenne. Teszt : [link] Azért használtam külön r1 és r2 változót, hogy olyan típusú változóba rakjam bele a visszatérési értéket amilyen a visszatérési érték típusa, ne legyen pluszba típuskonverzió. Hozzáraktam egy myRound függvényt ami úgy működik mint ahogy mondtad. Eredetileg egyébként a time paranccsal mértem le, de megírtam hogy ne kelljen hozzá a time parancs, hogy bárki kipróbálhassa vagy láthassa.

"...Ezt jobb ha elhiszed nekem, kódot, referenciát úgy sem teszek közzé..."

Ezt meg tudod ki hiszi el, még ha külön nem írtad volna oda, hogy nem teszed közzé még hihetőbb lenne. Így ráadásul ez a mondat egy igazi kötekedő, szemétláda hatását kelti.

"Miért nem egyelőégjelet használsz?

Mert azzal nem lenne stabil az algoritmus; "

Így sem stabil, kellőnen nagy számoknál a lebegőpontos ábrázolás miatt teljes egészében elveszlik a szám tört értéke, sőt nagyobb helyi értékek is elveszhetnek. Stabil akkor lenne ha fixpontos számba olvasnám be vagy a standard inputról jővő byteokat stringként feldolgozva eldöntöm , hogy egész e.

"Ajánlom figyelmedbe a IEEE754-ös szabványt. "

Ne is feltételezd, hogy nem ismerem.

"Ha elmebetegségnek számít, hogy 3x gyorsabb, stabil és mellesleg HELYES megoldást adtam, akkor igen az vagyok. Legalábbis számodra..."

Az mese, hogy gyorsabb. Ha gyorsabb is lenne akkor is olyan sok az overhead, hogy semmit nem számít egy szerencsétlen szám eldöntésénél, hogy egész e.

Helyesnek nem helyes, az enyém sem helyes, de nem túl nagy számokra helyes megoldást ad a tied is. Tudtam előre , hogy nem helyes , de nem számít a kérsés szempontjából. A kérdezőnek adtam választ eredetileg az első válaszommal nem neked kedves dr. prof. Kötekedő Úr.

"Vegyük a következő példát: A 10E+11 számra (ami ugye egész) a te megoldásod hamissal tér vissza. "

Hozzáírtam inputnak 10E+11 számot : [link]

Semmi érdemi hozzászólást nem írtál, jobb lett volna ha hozzá sem szólsz. Az, hogy legelőször hozzászóltál az még oké. Utána zsinórba látszik, hogy engem akarsz kioktatni, amikor bárki megmondja rajtad kívül hogy eredménytelül és mindig mellélősz. Ha tévedek akkor azt elismerem, de ha nem akkor nem.

Ha maradt benned némi bölcsesség akkor nem folytatod a kötekedést. Bölcsebb maradtál volna ,ha csendbe maradtál volna a mondás is tartja, de folytasd csak nyugodtan akkor legalább meg van örökítve , hogy milyen kötekedő, okoskodó vagy. NEM FOGOK válaszolni ha ismét kitalálsz valami kötekedni valót. Nem akarok lesüllyedni a te szintedre. Teljes egészében semmibe fogom venni ,ha folytatod. Egyébként is egy OFF topic már, ha még OFF-olni akarod akkor rajta, én nem fogom.