Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
#8374
Jester01
veterán
beleszólok
#8372
Jester01
veterán
válasz
beleszólok
#8372
üzenetére
A for ciklusos változat nálam gyorsabb mint a python.
-
#8365
Jester01
veterán
beleszólok
#8364
Jester01
veterán
válasz
beleszólok
#8364
üzenetére
Igen, a hibát akkor kapod ha nem választod ki a project options->general->c#->main class segítségével, hogy melyiket is akarod használni. Ez egyébként visual studioban is így van: To resolve this error, you can either delete all Main methods in your code, except one, or you can use the /main compiler option to specify which Main method you want to use.
Mondjuk továbbra sem látom ennek mi értelme van. Ha különböző programokat akarsz csinálni akkor tedd őket külön projektbe.
-
Jester01
veterán
válasz
Alexios
#8361
üzenetére
Sőt, akárhány solutiont is be tud tölteni egyszerre
Nem értem a problémád, akárhány Main lehet (nyilván egy osztályban csak egy). Ha egy projektben több van, akkor ki kell választani melyiket is akarod. De szerintem ez visual studioban is így van (már ha egyáltalán engedi a több Main-t).
-
#8359
Jester01
veterán
beleszólok
#8355
Jester01
veterán
válasz
beleszólok
#8355
üzenetére
Az IndexOf vagy a for ciklus? Mert az előbbi nekem is lassabb mint a python.
Monodeveloppal mi bajod? -
#8352
Jester01
veterán
beleszólok
#8351
Jester01
veterán
válasz
beleszólok
#8351
üzenetére
linux+mono persze (a pingvinből azért lehetett sejteni
)
Egy szálon a mono így "csak" kétszer lassabb, többszálúsítva utoléri.Hehe, az IndexOf-nál sokkal gyorsabb ha simán ciklusban végignézzük:
for(int pos = 0; pos < got; pos += 1)
{
if (buf[pos] == 10) n += 1;
}Ez már egy szálon is ráver a pythonra így.
-
#8350
Jester01
veterán
beleszólok
#8349
Jester01
veterán
válasz
beleszólok
#8349
üzenetére
A háttérben zajló karakterkészlet konverzió és memóriaműveletek lassítják a dolgot, ezek elkerülhetők némi kézi mókolással:
public static void Main(string[] argv)
{
int n = 0;
byte[] buf = new byte[4096];
using (Stream s = File.OpenRead("kern.log"))
{
int got;
while ((got = s.Read(buf, 0, buf.Length)) > 0)
{
int pos = 0;
while (pos < got && (pos = Array.IndexOf(buf, (byte)10, pos)) >= 0)
{
n += 1;
pos += 1;
}
}
}
Console.WriteLine (n);
}Ez nálam nagyjából fele olyan gyors mint a python változat.
Többszálúsítva sikerül beérni sebességben. -
#7523
Jester01
veterán
hunterrop8
#7522
Jester01
veterán
válasz
hunterrop8
#7522
üzenetére
Leginkább azt felejtetted el megmondani, hogy milyen architektúrán vagy. A regiszter nevekből valamilyen AVR-re tippelek. A megfelelő adatlapot (datasheet) kell jól elolvasni, hogy megtudd hová mit kell írni.
Általánosságban célszerű normál felfelé számoló auto-reload módban használni az időzítőt, olyan értékkel és órajellel, hogy a periódus 1mp vagy annak valamely egész osztója legyen.
-
#7500
Jester01
veterán
hunterrop8
#7499
Jester01
veterán
válasz
hunterrop8
#7499
üzenetére
Pl. a 36. sorba teszel egy breakpointot és megnézed minden bevitel jó-e addig. Utána meg már lehet léptetni.
-
#7498
Jester01
veterán
hunterrop8
#7497
Jester01
veterán
válasz
hunterrop8
#7497
üzenetére
Pl. t1[2] de te 4 elemet raksz bele.
Egyébként meg léptesd a szimulátorban és figyeld mi történik. -
Jester01
veterán
Kevésbé favágó módszer valami backtrack-es keresés lehetne.
1. Választani kell 3 nem egy vonalba eső pontot.
2. Választani a maradékból egyet (ha már nincs maradék akkor készen vagyunk)
3. Végignézni, hogy a létező gyűrűbe bárhol beilleszthető-e keresztezés nélkül. Ha igen, akkor beszúrjuk és vissza a 2. lépéshez
4. Ha nem, akkor az aktuális pontot visszatesszük a maradék halmazba és választunk másikat ha még van és azzal vissza a 3. lépéshez
5. Ha már nincs több beszúrható pont, akkor a legutoljára hozzáadott pontnak keresünk új helyet a 3. lépéssel. Ha így visszaérünk a kiindulási háromszöghöz, akkor mindent kipróbáltunk, nincs megoldás. -
Jester01
veterán
Illetve getline függvény helyett használhatod simán a cin >> szoveg; -et is.
Itt a kiírás szerint valóban egy szót kell csak olvasni, de általában a getline kifejezetten ajánlott a cin >> helyett, mivel az egész sort olvassa. Azon túl, hogy néha valóban ezt akarjuk, azért is jó mert nem marad a pufferben semmi ami később meglepetést okozhat. Tehát még 1 szót is érdemes így olvasni, majd később kivágni.
A szöveges adatbevitel témakör egyszerűnek tűnik de nem az
-
Jester01
veterán
Amihez persze nem kell floor, tekintve, hogy az egész osztás az automatikusan trunkál. A floor meg lebegőpontosra van egyébként is.
Illetve ha a ciklust két változóval írod akkor az i < j feltétel ezt rögtön adja is.
Aki magyar kiosztással akar programozni az meg is érdemli
-
Jester01
veterán
válasz
Orton96
#6829
üzenetére
Valószínűleg nincs python a gépen, vagy máshogy hívják. Nézd meg mi a which python parancs eredménye. Esetleg az env parancs hiányzik. Az első sor szerkesztésével lehet ezeket orvosolni.
Ja és futtatni ./hello.py módon kell, ha csak simán hello.py-t írsz akkor nem fogja megtalálni.
-
Jester01
veterán
válasz
zserrbo
#6772
üzenetére
A lebegőpontos számok már csak ilyenek, főleg kettes számrendszerben.
Éppen ezért kell összehasonlításnál mindig valami toleranciát használni, kiírásnál meg értelmes kerekítést. Ja és fontos számításoknál tudni, hogy hol mennyi hiba gyűlik össze vagy kerülni a lebegőpontos számokat.
-
Jester01
veterán
válasz
Phausto
#6751
üzenetére
Szerintem nincs ilyen.
The types of both operands of the less-than operator must be arithmetic types, or a compile-time error occurs.
Továbbá:
If either operand is not-a-number (NaN), the comparison produces false.
Negative infinity is the most negative value. If the left operand is negative infinity, the comparison produces true, unless the right operand is also negative infinity, in which case the comparison produces false.
Positive infinity is the most positive value. If the right operand is positive infinity, the comparison produces true, unless the left operand is also positive infinity, in which case the comparison produces false.
Positive and negative zero are treated as equal, so -0.0 < 0.0 produces false.
A másik két operátorra hasonlóan. Tehát NaN használatával lehetne olyat csinálni, hogy mind a három reláció hamis, de olyat nem, hogy mind a három igaz.
-
#6709
Jester01
veterán
sirszevenap
#6706
Jester01
veterán
válasz
sirszevenap
#6706
üzenetére
Persze, csak éppen a feladatkiírással ellentétben használ egy segédváltozót.
kingabo már írt egy megoldást illetve korábban én is linkeltem. -
#6704
Jester01
veterán
sirszevenap
#6703
Jester01
veterán
válasz
sirszevenap
#6703
üzenetére
A másodiknál favágó módon felsorolod a 6 lehetséges esetet.
A harmadikhoz még mindig nincs meg a függvény.
Az ötödik meg aztán végképp egyszerű, csak 1 feltétel.Mutasd meg mire jutottál!
-
#6702
Jester01
veterán
sirszevenap
#6701
Jester01
veterán
válasz
sirszevenap
#6701
üzenetére
Beolvasást, kiírást, if-et, változókat és alapműveleteket azért csak tudsz már használni, nem?
Például a 4.
double min = a;
double absmax = fabs(a);
if (b < min) min = b;
if (c < min) min = c;
if (fabs(b) > absmax) absmax = fabs(b);
if (fabs(c) > absmax) absmax = fabs(c);Az elsőt kivéve a többi is ilyen, csak egy halom egyszerű feltétel.
-
#6700
Jester01
veterán
sirszevenap
#6698
Jester01
veterán
válasz
sirszevenap
#6698
üzenetére
1. XOR swap
3. lemaradt a függvény, de gondolom osztás van benne. Először nézd meg az osztó nulla-e.A többi pofon egyszerű, mit nem tudsz megoldani?
-
Jester01
veterán
válasz
zserrbo
#6654
üzenetére
Az xmlns miatt nem megy. Ugye ha namespace-be teszed az elemeket akkor már nem az a neve, hogy "body" ...
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />
<xsl:template match="xhtml:body" xmlns:xhtml="http://www.w3.org/1999/xhtml">
<!-- first div -->
<xsl:variable name="root" select="xhtml:div" />
<xsl:element name="entity">
<xsl:attribute name="id">
<xsl:value-of select="$root/@id" />
</xsl:attribute>
<xsl:attribute name="type">
<xsl:value-of select="substring-before(substring($root/@class, 3), ' ')" />
</xsl:attribute>
<xsl:attribute name="top">
<xsl:value-of select="substring-before(substring-after($root/@style, 'top:'), 'px;')" />
</xsl:attribute>
<xsl:attribute name="left">
<xsl:value-of select="substring-before(substring-after($root/@style, 'left:'), 'px;')" />
</xsl:attribute>
<xsl:value-of select="normalize-space(string($root))" />
<xsl:for-each select="$root/following-sibling::xhtml:div">
<xsl:element name="property">
<xsl:attribute name="id">
<xsl:value-of select="@id" />
</xsl:attribute>
<xsl:attribute name="type">kulcs</xsl:attribute>
<xsl:attribute name="top">
<xsl:value-of select="substring-before(substring-after(@style, 'top:'), 'px;')" />
</xsl:attribute>
<xsl:attribute name="left">
<xsl:value-of select="substring-before(substring-after(@style, 'left:'), 'px;')" />
</xsl:attribute>
<xsl:value-of select="normalize-space(string(.))" />
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
</xsl:stylesheet> -
Jester01
veterán
válasz
zserrbo
#6650
üzenetére
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />
<xsl:template match="/body">
<!-- first div -->
<xsl:variable name="root" select="div" />
<xsl:element name="entity">
<xsl:attribute name="id">
<xsl:value-of select="$root/@id" />
</xsl:attribute>
<xsl:attribute name="type">
<xsl:value-of select="substring-before(substring($root/@class, 3), ' ')" />
</xsl:attribute>
<xsl:attribute name="top">
<xsl:value-of select="substring-before(substring-after($root/@style, 'top:'), 'px;')" />
</xsl:attribute>
<xsl:attribute name="left">
<xsl:value-of select="substring-before(substring-after($root/@style, 'left:'), 'px;')" />
</xsl:attribute>
<xsl:value-of select="normalize-space(string($root))" />
<xsl:for-each select="$root/following-sibling::div">
<xsl:element name="property">
<xsl:attribute name="id">
<xsl:value-of select="@id" />
</xsl:attribute>
<xsl:attribute name="type">kulcs</xsl:attribute>
<xsl:attribute name="top">
<xsl:value-of select="substring-before(substring-after(@style, 'top:'), 'px;')" />
</xsl:attribute>
<xsl:attribute name="left">
<xsl:value-of select="substring-before(substring-after(@style, 'left:'), 'px;')" />
</xsl:attribute>
<xsl:value-of select="normalize-space(string(.))" />
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
</xsl:stylesheet> -
-
#6595
Jester01
veterán
Peter Kiss
#6594
Jester01
veterán
válasz
Peter Kiss
#6594
üzenetére
Az is igaz
MOD: De sokkal inkább fix blokkokban mert byteonként meg lassú. -
#6593
Jester01
veterán
Peter Kiss
#6590
Jester01
veterán
válasz
Peter Kiss
#6590
üzenetére
Néhány észrevétel:
1. általában a különböző EOF ellenőrzések helyett célszerűbb az olvasás eredményét megnézni
2. Console.WriteLine(Environment.NewLine); nyilván kettő üres sort szúr be
3. bár itt nincs különösebb jelentősége, de az osztást optimalizációs okok miatt kerüljük
4. var i = 1 csak olvashatatlanná teszi a kódot és semmivel sem jobb vagy éppen kevesebb gépelés mint az int i = 1 -
Jester01
veterán
válasz
pittbaba
#6561
üzenetére
A legtöbb adatbáziskezelőhöz van import eszköz ami CSV-t egyből tud olvasni (és gyorsan). Ilyen cserélgetéssel és regexp-pel sose fogsz rendesen működő eszközt írni (csak ha tudod, hogy bizonyos szerkezetek nem fordulnak elő a bemenetben, például mezőn belüli idézőjel vagy sortörés).
Mellesleg a CSV az eredetileg Comma Separated Values, tehát a vessző az "igazi". Ez olyannyira hasonlít a CSV-hez, hogy az
-
#6527
Jester01
veterán
Sk8erPeter
#6526
Jester01
veterán
válasz
Sk8erPeter
#6526
üzenetére
Nem tudjuk mit kell lekezelni
Ez nem valami szuperáltalános megoldás akart lenni, hanem a minimális.Például lehet, hogy nem is egy sorban van a title, vagy kisbetű-nagybetű eltérés van, vagy fájlnévnek illegális karakter van benne, stb.
-
#6525
Jester01
veterán
DiabloCorsa
#6519
Jester01
veterán
válasz
DiabloCorsa
#6519
üzenetére
Erősen függ attól, pontosan milyen a html szerkezete. Ha mindegyikben mondjuk egy sorban, kisbetűvel van <title>foo.html</title> az a legkönnyebb eset, erre például egy pár soros bash script is jó (vagy bármi hasonló):
#! /bin/bash
for file
do
title=""
while read line
do
back=${line#*<title>}
if [ "x$back" != "x${line}" ]
then
title=${back%</title>*}
echo mv "$file" "${title}"
break
fi
done < "$file"
done -
Jester01
veterán
válasz
pckownz
#5625
üzenetére
Nem ismerem ezt a rendszert szóval csak tippelgetek.
Ránézésre nem látom, hogy valami intervallum be lenne állítva a timernek, nem lehet, hogy azzal van a baj? Vagy ha van is valami alapértelmezés, nem lehet, hogy miközben számolgatsz, a timer lejár és újra hívódik a függvényed?
-
-
-
Jester01
veterán
válasz
Jim Tonic
#5389
üzenetére
Valóban nem kellett volna azt a megjegyzést tennem, amiért ezúton elnézésedet kérem.
A többiben továbbra sem értünk igazán egyet. Tényleg elkanyarodtam a pszeudokódtól, ami azért volt mert bevallásod szerint a saját nem-pszeudokódodat is úgy optimalizálod, hogy minél rövidebb legyen és úgy állítod be, mintha a kevesebb utasítás gyorsabb is lenne. Erre próbáltam ellenpéldákat hozni, az intelest azért mert konkrét, de a többi amit általánosságban mondtam szerintem helytálló még pszeudokód esetén is. Ha valaki pszeudokódban hatékony de alkalmasint hosszabb kódot mutat be (és meg tudja indokolni) az nálam pozitívum, továbbá feltételezhető, hogy az egyszerűbbet is meg tudta volna csinálni.
A gyakorlatban minden bizonnyal neked is már megvannak a kialakult szokásaid, amik feltehetően az adott környezetben működnek is. Én leginkább csak azt akartam leszögezni, hogy az optimalizálást általánosságban nehogy úgy képzeljék el az emberek, hogy ami rövid az gyors és kész.
-
Jester01
veterán
válasz
Jim Tonic
#5386
üzenetére
Ilyen sorok után már nem szoktam tovább olvasni a hozzászólást.
Köszönöm, hogy ezúttal nyilvánvalóan kivételt tettél.
Az Inteles példád pedig pont engem igazol, csak továbbra sem sikerült megértened, miről beszéltem.
Tényleg nem értem. Ezt írtad betű szerint: "a kevesebb utasítás gyorsabb." Erre hoztam rögtön a két példát az intel doksiból, amikor a kevesebb utasítás nem gyorsabb. Akkor mégis hogy igazol téged?
De maradjunk a tőled idézett fenti mondatnál, és akkor úgy is felesleges folytatnunk a megbeszélést, ha ennyibe nézel.
Én ugye épp békejobbot nyújtottam, hogy talán maradjunk a szakmai résznél és ne azzal vágjunk fel, hogy "fejlesztek egy cégnél, ahol majdnem 20e ember dolgozik". Ha ez neked nem megy, akkor lehetőleg tényleg tartózkodj a válaszolástól és ne piszkálódj ilyen "pont engem igazol" odavetett állításokkal, mert ezekre én viszont továbbra is fogok reagálni, tényekkel, amíg lehet. Lásd fentebb.
-
Jester01
veterán
válasz
Jim Tonic
#5384
üzenetére
A kódodból ítélve nem sebesség orientált vagy
Pedig de. Az egyébként nem az én kódom volt, és bármelyik C fordító tök optimálisra fordítja le. Amúgy gyanítom kicsit jobban értek hozzá, mint te. Azért ne menjük el személyeskedés és e-pénisz verseny felé.
És mint írtam, a kevesebb utasítás gyorsabb.
Inkább hadd idézzek akkor az intel optimization manualból, hátha annak hiszel:
Assembly/Compiler Coding Rule 31. (ML impact, M generality) Avoid using
complex instructions (for example, enter, leave, or loop) that have more than four
µops and require multiple cycles to decode. Use sequences of simple instructions
instead.Ez például azt jelenti, hogy x86 assemblyben az enter 8,0 utasítás lassabb mint az őt helyettesítő push ebp; mov ebp, esp; sub esp, 8 3 utasítás (ami 3 sor is, tipikusan) . Előbbi egyébként 4 byte, utóbbi 6 byte gépi kód.
Vagy ezt, ugyanonnan:
Assembly/Compiler Coding Rule 49. (H impact, ML generality) If it is
necessary to extract a non-aligned portion of stored data, read out the smallest
aligned portion that completely contains the data and shift/mask the data as
necessary. This is better than incurring the penalties of a failed store-forward.Ez például azt jelenti (akár C szinten is), hogy érdemesebb lehet shift (<<) és mask (&) műveletekkel dolgozni egy látszólag tök egyszerű byte olvasásnál is!
Ezek ugye erősen architektúra-függő dolgok, tehát pszeudokód szinten nincs értelme róluk beszélni. De mondok másik példát. Ha van egy általános kódod ami mondjuk x sor és mindig működik, de van egy másik kódod ami mondjuk y sor de bizonyos (gyakori) esetekben sokkal gyorsabb, akkor megéri olyanra írni a függvényed, hogy előbb z sorban ellenőrzi a feltétel fennállását és az alapján dönt, hogy melyik verzió fusson. Ilyen eset lehet például aligned/unaligned memória vagy egy adott blokkméret (jellemzően például képfeldolgozásnál, de már a mezei memcpy is a legtöbb esetben így működik). Így az x+y+z soros kód mégis gyorsabb lesz az esetek többségében.
Még vadabbat mondok, általában a rövid kód a legegyszerűbb és legáltalánosabb, ha pedig hatékonyságra gyúrsz akkor sokszor a kifinomultabb adatszerkezet és algoritmus nagyobb kódot és nagyobb memóriafelhasználást is jelent. Példa erre, ha C-ben szeretnél kulcs-érték párokat tárolni. A legegyszerűbb egy tömb, amibe a triviális módon beszúrsz és törölsz, a keresés pedig lineáris. Ez lássuk be elég egyszerű, rövid, nem használ felesleges memóriát és nem utolsósorban dög lassú. Ha nekiállsz helyette egy hash táblát implementálni, az sokkal több sor kód lesz, több gépi kód is, lesz neki memória overheadje és ennek ellenére gyorsabb is lesz (megfelelő hash függvény esetén). Az is köztudott, hogy a kis memóriahasználatra és/vagy kódméretre optimalizálás természetétől fogva nehezen összeegyeztethető a sebességre optimalizálással (bár nyilván vannak kivételek). Extrém példa: ha akarod, tömörítheted az egész program memóriát, ezzel csökken a memória használat de ugyanakkor minden bizonnyal lassul is, kivéve ha ettől befér a fizikai memóriába és nem kell lapozni. Kevésbé extrém példa: a linux kernel szereti processzor cache line határra igazítani a kritikus adatszerkezeteket. Még kevésbé extrém példa: már a C fordító is igazítja a struktúrák elemeit:
$ cat >t.c
#include <stdio.h>
int main()
{
struct { int a; unsigned char b; unsigned char c; } x;
struct { unsigned char b; int a; unsigned char c; } y;
printf("%d %d\n", sizeof x, sizeof y);
return 0;
}
$ gcc -Wall -m32 t.c && ./a.out
8 12Ugye a második esetben az a mező előtt van 3 byte padding, továbbá mindkét esetben van a végén is még. Ha ezek nem lennének, akkor kevesebb memóriát használna a program viszont esetleg lassabb lenne. Bizonyos architektúrákon nem is futna, vagy hibásan (pl. atomi műveleteknél).
Nem ettől lesz felesleges egy változó. Az teljesen mást jelent. Pl. részeredmények tárolása.
Oké, akkor minden bizonnyal elbeszélünk egymás mellett. De a példában az pont egy részeredmény volt. Most akkor ez felesleges vagy nem? Lásd még: premature optimization. -
Jester01
veterán
válasz
Jim Tonic
#5382
üzenetére
A felesleges változó felesleges hely a memóriában...
Mármint, ha nem lesz kioptimalizálva.Senki nem mondta, hogy gyorsabb lesz
Én nem ma kezdtem, de máig találok módot a sorok csökkentésére, van, hogy le is felezem.
Akkor miért is csökkented a sorok számát, ha nem lesz gyorsabb vagy legalább olvashatóbb.Ha ezt előadod a felvételin, jó eséllyel nem vesznek fel.
Én szoktam felvételiztetni És ha valaki bármit előad amit értelmesen meg tud indokolni akkor az nem kizáró tényező, sőt, előny.Mit? Ismered az összes fordítót? Pszeudokódban ír, lehet, hogy abszolút nem képes optimalizálni a fordító, mert nem is ismered.
Viszont az összes hétköznapi gyakorlatban előforduló fordító tudja ezt. Pszeudokód hatékonyságát meg amúgy is csak algoritmus szintjén nézzük. Nyilván nem hasraütésszerűen vette fel a változót, hanem olvashatóság céljából. Példa:double map_coefficient = Ze/(Ze+Z_airbox+Zt);
// Add a one second lag to manifold pressure changes
double dMAP = (TMAP - p_ram * map_coefficient) * dt;
TMAP -=dMAP;A map_coefficient nyilván "felesleges változó" mivel egyszerűen bele lehetne másolni a dMap képletbe (amit aztán szintén tovább lehetne másolni a TMAP képletbe). Mégis, így olvashatóbb, főleg mivel fizikai jelentése is van.
-
Jester01
veterán
válasz
Jim Tonic
#5378
üzenetére
A sorok csökkentése egyáltalán nem biztos, hogy gyorsabb vagy olvashatóbb kódot eredményez.
Felesleges változók? Ha attól olvashatóbb lesz a kód, akkor miért ne. A fordító meg úgyis kioptimalizálja. Persze az egyáltalán nem használt változók tényleg feleslegesek, de azok tipikusan kód módosítások után szoktak bentfelejtődni.
-
#5209
Jester01
veterán
Sk8erPeter
#5208
Jester01
veterán
válasz
Sk8erPeter
#5208
üzenetére
Bár logikátlan lenne, de elképzelhető hogy az egyik sor az stdout-ra a másik meg az stderr-re megy. Én ezt ellenőrizném először.
Ugyanakkor az sincs kizárva, hogy a net start eleve ad vissza errorlevelt (bár ugye a microsoftról ennek az ellenkezője is elvárható) -
Jester01
veterán
Nem tudom, nekem általában rengeteg időm van szövegszerkeszteni miközben kitalálom mit is akarok utána csinálni
Szóval az én produktivitásomnak nem a szövegszerkesztő a szűk keresztmetszet.A gyakran használt hasznos funkciókra (például a dd vagy a *) pedig majd' minden editorban van gyorsbillentyű lehetőség, a ritkábban használtakat meg tovább tart megtanulni/megkeresni minthogy megérje.
-
Jester01
veterán
válasz
PH-User
#4834
üzenetére
Windowshoz nem értek, de hallomásból úgy tudom a win7 már nem támogat dos-os cuccokat. Ehhez az a csoda beépített virtuális xp mód kell vagy mi a szösz. De majd egy szakemberebb megmondja.
MOD: persze régi dos-os com fájlok programozását megtanulni nem sok értelme van manapság.
-
Jester01
veterán
Nagyon jó, hogy "képzeljük oda", de abban a kódban kell legyen a hiba!
Ha nem bejövő kapcsolatokat akarsz fogadni (listen) akkor ne adj meg helyi portot és a rendszer fog neked választani egy megfelelőt automatikusan.
Helyesen használt kimenő kapcsolatoknál ez a TIME_WAIT probléma nem jelentkezik. -
Jester01
veterán
Konkrétan a bemásolt kódban sehol nem látszik hogy használsz portot.
A távoli port nyilván adott, azon nem tudsz variálni. A helyi portot pedig egyáltalán nem szokás megadni, a rendszer választ egy alkalmasat automatikusan. Egyébként hiába is zárod be, van egy várakozási idő mielőtt újra használni lehetne. -
Jester01
veterán
Mert biztos béna voltál
Nekem érdekes mód tíz éve is sikerült 878as kártyát használni amikor kölcsön kaptam egyet. 848-as pedig 12 éve van a gépemben (ugyanaz). Ettől függetlenül a 848/878 chipek doksija ingyenesen elérhető a neten, és ez a fontos mert ez kell ahhoz, hogy bárki tudjon drivert írni ha szükséges. Továbbá egy jól megírt 32 bites driverrel semmi dolog nincs, csak le kell fordítani 64 bitre is - ezért általában nem probléma linuxon a 32/64 bit.
Mondjuk a tv kártyákon más chipek is vannak, tipikusan a tunerrel és a távirányítóval szokott még gond lenni illetve az általános célú lábak (GPIO) különböző bekötésével. Ez megint csak azért van mert a gyártók nem publikálják az információt - rugdosni kellene őket.
-
Jester01
veterán
Én majdnem biztosra veszem, hogy van BT878 driver mivel az egy elég elterjedt chip. Mondjuk például legalább a gyártó oldalán megnézted? Mivel szerintem ez a Windows 7 64bit build 7600.16385 WHQLed driver pont az.
Amúgy én mindig mondtam, hogy a windows felhasználóknak is érdeke lenne a nyílt forráskód és a nyílt hardver támogatása a linux köpködése helyett. Nekünk van 64 bites driverünk alapból
-
Jester01
veterán
De az alapkövetelmény, hogy csak egy megoldás legyen.
Amúgy a tippelés a nem megfelelő mértékű előre gondolkodás. Az az eset, amikor már nem tudod fejben tartani a lehetőségeket ezért beírod. (Az agyadból kiswappolod a papírra
) Ilyenformán soha nem kell tippelni ha elég mélységben látsz előre, ez pedig valamilyen szinten az adott tábla nehézségi foka. Miután megtippelted, helytelen tipp esetén szükségszerűen ellentmondásra jutsz ha pontosan egy megoldás van. Persze vannak előre legyártott minták amik már ismert állásokra megadják a helyes választ ezért az embernek nem mindig kell újra meg újra mélységi bejárással feltalálni őket. Az, hogy neked tippelned kell valójában ekvivalens azzal, hogy az adott állásra illeszkedő szabályt nem ismerted illetve fejben nem tudtad kidolgozni. Mi lenne, ha egy nagyon buta ember (vagy "favágó" számítógép) nem tudná azt a szabályt, hogy ha egy sorból csak egy szám hiányzik akkor azt nyilván be lehet írni. Ekkor neki sorra meg kellene "tippelnie" a lehetőségeket és megnézni ellentmondásra jut-e. -
Jester01
veterán
válasz
lakisoft
#4598
üzenetére
Persze, mert ténylegesen meg is csináltad a joint (az optimizer meg ezek szerint buta és nem veszi észre, hogy nem is kell).
Egy lekérdezéssel nem tudom hogy lehet megkerülni, de ha egyesével lekéred a táblák rekordszámát és utána azt tetszőleges nem-sql módon összeszorzod az valószínű gyorsabb lesz
Vagy persze írhatsz rá tárolt eljárást. -
-
Jester01
veterán
válasz
szasza_1
#4563
üzenetére
Első ránézésre ismétléses variációnak látszik, mégpedig nem is egynek.
Én hozzávenném a táblázathoz az eredeti elemet és csinálnék a cserélendő betű számosságának megfelelő számrendszerű számlálót ami 1-ről indulna (ha feltétel, hogy 1 előfordulást mindenképp cserélni kell).
Pl. ha az "a" betűből lehet "á, ó, é" és a szövegben 3 "a" betű van, akkor egy 3 jegyű, 4-es számrendszerbeli számot kell használni amelyiknek minden jegye jelzi, hogy az adott előfordulást mire cseréled. Ez viszont nem olyan sorrendben cserél, ahogy te írtad. Ha ez is fontos, akkor más módszer kell. Ha pedig több betűt kell cserélni, akkor az egyes rész-variációkat össze kell szorozni. -
-
Jester01
veterán
Ez eléggé házi feladatnak tűnik amit nem fogunk neked megcsinálni. Főleg, mert ha magadtól nem találsz meg benne legalább kettőt, akkor olyan szinten nem értesz hozzá (feltehetőleg szorgalom vagy odafigyelés hiánya miatt) amit mi itt nem tudunk érdemben orvosolni. De javíts ki ha tévednék.
MOD: ALI_G: hát, a tied se túl jó
-
Jester01
veterán
Szerintem itt a hardver sokkal inkább érdekes mint a szoftver. Én például telepítettem egy pár hőmérőt szerte a lakásban illetve egy egy relét a kazánhoz. A szoftver meg egy pár soros perl script volt.Igaz, nem grafikus, cserébe viszont működött mobiltelefonon keresztül is
-
Jester01
veterán
-
Jester01
veterán
válasz
Bagira01
#3916
üzenetére
Ötletünk rengeteg van, de ha ismered a pascalt akkor ez neked se lehet gond.
Kell egy ciklus illetve játékosonként 2 változó: egyik az előző dobás értékét tárolja a másik pedig az összeget. Ha az aktuális és az előző dobás is 1, akkor ugye a játékos vesztett. Különben meg a ciklus után összehasonlítod a két összeget. -
Jester01
veterán
Nem mondtad milyen oprendszer alatt. Mindenesetre egy cross-platform megoldás lehet a plib (példa progi hozzá a js_demo a flightgear-ből). Persze használhatod egyből az oprendszer szolgáltatásait is ehhez az említett plib forráskódja gyakorlatilag kész megoldással szolgál windows, mac, bsd és linux esetén.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
). A programban pedig ha szükséges szedd több darabra és nézd meg a részeredményeket.
) Ilyenformán soha nem kell tippelni ha elég mélységben látsz előre, ez pedig valamilyen szinten az adott tábla nehézségi foka. Miután megtippelted, helytelen tipp esetén szükségszerűen ellentmondásra jutsz ha pontosan egy megoldás van. Persze vannak előre legyártott minták amik már ismert állásokra megadják a helyes választ ezért az embernek nem mindig kell újra meg újra mélységi bejárással feltalálni őket. Az, hogy neked tippelned kell valójában ekvivalens azzal, hogy az adott állásra illeszkedő szabályt nem ismerted illetve fejben nem tudtad kidolgozni. Mi lenne, ha egy nagyon buta ember (vagy "favágó" számítógép) nem tudná azt a szabályt, hogy ha egy sorból csak egy szám hiányzik akkor azt nyilván be lehet írni. Ekkor neki sorra meg kellene "tippelnie" a lehetőségeket és megnézni ellentmondásra jut-e.
Vagy persze írhatsz rá tárolt eljárást.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- HIBÁTLAN iPhone 15 Pro 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3003
- ÚJ Lenovo Yoga 7 2-in-1 - 14"WUXGA - Ryzen 7 8840HS - 16GB - 512GB - Win11 - 3 év garancia - MAGYAR
- Extra olcsó! HP 230 Vezetéknélküli USB-s Billentyűzet
- Új MSI 17 Raider GE78 QHD 240Hz i9-13980HX 24mag 32GB 2TB SSD Nvidia RTX 4090 16GB 175W W11 Garancia
Állásajánlatok
Cég: FOTC
Város: Budapest