Új hozzászólás Aktív témák
-
kutga
nagyúr
-
Finwe
őstag
Sziasztok!
Tudtok ajánlani valakit a ki szóban/korrepetálás jelleggel tudna nekem segíteni, hogy mihamarabb képbe kerüljek a python-nal? Haladok egy könyvvel és topikban is sok hasznos infó van, de szóban gyorsabban tanulok és most ez elég kritikus szempont.
Privátban is várom, ha van ajánlás.
Köszi szépen!-{PoH}- Patriots of Hungary
-
-
Találkozott már valaki azzal, hogy a Visual Studio Code hozzárendeli magát a directory-khoz, így ha valamilyen programban meg akarom nyitni a directory-t, akkor VSC-ben nyílik meg? Mindez Debian 9-ben történik.
https://www.coreinfinity.tech
-
hierroo
friss újonc
Sziasztok!
Nem tudja valaki, hogy ha van egy futó pythonos program amiben folyamatosan módosuló változók és listák meg szótárak vannak, akkor azokat hogy lehet kimenteni? Utána esetleg a kimentett változókat újra megnyitni akkor, amikor a programot újraindítottuk? -
hierroo
friss újonc
válasz concret_hp #2908 üzenetére
Igen, akár file-ba is jó volna, ha utána a file-ból visszaolvashatóak a változó értékek a pythonos programba valahogy!
-
Siriusb
veterán
válasz hierroo #2907 üzenetére
Korábban csak tőmondatokban tudtam írni. Kicsit részletesebben:
pickle
— Python object serializationEz rögtön a példára visz, hogy lásd milyen egyszerű.
A feladattól függően érdemes lehet megfontolni akár egy egyszerűbb adatbázis használatát is, pl. sqlite3.
-
mylastage
csendes tag
Sziasztok,
egy kezdő Python könyvben volt egy árfolyam átváltó gyakorló feladat. Blender-hez akarok írni egy scriptet, ami a "padlóra" helyezi az objektum alját, ezért néztem bele a programnyelvbe (többek között a Blender scriptnyelve is a Python).Gondolom ismeritek...
# EUR to CAD
arfolyam_eurtocad = 1.57
szamlalo = 1
while (szamlalo < 21):
cad = arfolyam_eurtocad * szamlalo
print (szamlalo, " EUR = ", cad, " CAD ")
szamlalo = szamlalo + 1Valamiért nem tud számolni a Python, mert az 1.57-nél az 5.,10, 19. 20. sornál az X milliomodik résznél ad valamennyi értéket a változóhoz.
Utánanéztem, hogy a round() függvénnyel lehet kerekíteni pl. 2 tizedesjegyig.
Csak az a baj, hogy nem tud kerekíteni sem. Előfordul, hogy az 5-öt lefelé kerekíti - és két tizedesnél ez 1%.
Ha 100 millió EUR-t váltok CAD-ra (a példa alapján), akkor buktam 1 millát CAD-ban a Python miatt.
Azt rebesgetik, hogy komoly scripteket lehet vele írni - biztos van megoldás - csak nem tudom hogyan lehetne kivédeni ezt a kellemetlenséget.Ha valakinek van megoldása és megosztja, köszönöm szépen - érdekelne a miértje is...
Tegnap kezdtem a Pythont - szóval csak bonyolítás nélkül.
Köszi előre is... -
kovisoft
őstag
válasz mylastage #2912 üzenetére
A sokadik tizedesjegynél való eltérés azért adódik, mert amikor nem egész számokkal dolgozik a számítógép, akkor lebegőpontosan tárolja azokat, kettedes tört formájában, és vannak véges tizedes törtek, amik csak végtelen kettedes törtként ábrázolhatóak (hasonlóan ahhoz, mint ahogy az 1/3-ot csak végtelen 0.33333... formájában tudjuk tizedes törtként ábrázolni, harmados törtként meg ez a 0.1), ezért óhatatlanul kerekítve lesznek. Ha egy ilyen végtelen kettedes törtet utána visszaalakítjuk tizedes törtté, akkor lesz ez a pici eltérés a tároláskori kerekítés miatt.
Ezért szokás a pénzügyi rendszereknél, ahol 1 fillér vagy cent sem térhet el, hogy egész számokkal dolgozunk, pl. mindent fillérben, egész számként tárolunk és számolunk, a számítások eredményét is egészre kerekítjük, kiírásnál pedig a 100-zal való osztás hányadosát és maradékát írjuk ki.
De én kipróbáltam a programodat egy round() beiktatásával, és nem látom, hogy hol adna rossz eredményt:
> while (szamlalo < 21):
... cad = round(arfolyam_eurtocad * szamlalo, 2)
... print (szamlalo, " EUR = ", cad, " CAD ")
... szamlalo = szamlalo + 1
...
1 EUR = 1.57 CAD
2 EUR = 3.14 CAD
3 EUR = 4.71 CAD
4 EUR = 6.28 CAD
5 EUR = 7.85 CAD
6 EUR = 9.42 CAD
7 EUR = 10.99 CAD
8 EUR = 12.56 CAD
9 EUR = 14.13 CAD
10 EUR = 15.7 CAD
11 EUR = 17.27 CAD
12 EUR = 18.84 CAD
13 EUR = 20.41 CAD
14 EUR = 21.98 CAD
15 EUR = 23.55 CAD
16 EUR = 25.12 CAD
17 EUR = 26.69 CAD
18 EUR = 28.26 CAD
19 EUR = 29.83 CAD
20 EUR = 31.4 CAD[ Szerkesztve ]
-
mylastage
csendes tag
-
kovisoft
őstag
válasz mylastage #2914 üzenetére
Ennek is pont ugyanez az oka. Nem végtelen tizedes törtről, hanem végtelen kettedes törtről van szó. Tehát olyan véges tizedes törtről, amelyik csak tízes számrendszerben felírva véges, de kettes számrendszerben felírva végtelen. A gép ugyanis kettes számrendszerben tárolja a számokat, a lebegőpontosakat is.
Nem tudom, milyen hibás szorzásra gondolsz. Ha egész számokat szorzol, akkor az eredmény is egész és pontos lesz.
-
cousin333
addikt
válasz mylastage #2912 üzenetére
"Előfordul, hogy az 5-öt lefelé kerekíti - és két tizedesnél ez 1%."
Példa? Remélem nem a 7.850000000005-től vártad, hogy 7.86 legyen...
"az apróban való tárolás tényleg egy jó ötlet, de még mindig zavar, hogy szorzás esetén - ahol nincs szó végtelen tizedes törtről - hibás eredményt ad."
Nem, nem ad. A "klasszikus példádban" meg pont nincs szorzás. Az említett számábrázolási hiba legtöbbször minimális pontatlansággal jár (nem 1%), ha meg mindenképpen el akarod kerülni ezeket, akkor Decimal osztály, vagy sympy modul valódi törtekkel
[ Szerkesztve ]
"We spared no expense"
-
mylastage
csendes tag
Köszönöm a válaszokat, de nem lettem meggyőzve...
Egy változóban tárolt érték, miért vesz fel vhol az 'X' milliomodikon bármilyen értéket is?!A "klasszikus példa" esetén még szorzásról-osztásról sincs szó, csak összeadás és kivonás; de nem tud számolni... a miértje lett volna a kérdés, de a kuzinomnak ez nem ment át.
A kerekítéstől mit várok??!
Nem ennek a futási eredményét...x = 0.5
x2 = round (x, 0)
print (x2)A Python nyalókáknak gondolom nem szimpatizál a kérdés - miért kell egy programnyelvet isteníteni, mikor alapvető múveleteket nem tud megoldani?
a MIÉRT érdekel, és a hogyan kerüljük ki a hibákat válaszok leginkább...
A Decimal-t ill. a sympy-t megnézem mit kreálnak - köszi az infót - -
sztanozs
veterán
válasz mylastage #2918 üzenetére
Ez nem a python hibája, ez egy általános informatikai probléma, ami szinte az összes programozási nyelvet érinti. Értem, hogy laikus fejjel ez az egyik legnehezebben feldolgozható dolog, de ennek az a fő oka, hogy nem tudod, hogyan működik a számítógép (pontosabban az ALU) valójában.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
kovisoft
őstag
válasz mylastage #2918 üzenetére
A MIÉRTet korábban már elmondtuk, de akkor megpróbálom jobban kifejteni. 10-es számrendszerben is csak azokat a törteket tudjuk véges alakban felírni, amelyek nevezőjében csak a 10 prímtényezőinek, azaz 2-nek és 5-nek valamilyen hatványa szerepel, mint pl. 1/5, 3/8, 17/40. Minden más végtelen tizedes tört lesz, mint pl. 1/6, 2/7, 8/11.
Ugyanez igaz a 2-es számrendszerre is: csak azokat a törteket tudjuk véges alakban felírni, amelyeknek a nevezőjében valamilyen 2-hatvány szerepel, mint pl. 1/2, 3/8, 47/256. Minden más végtelen kettedes tört lesz.
Vegyünk egy példát: 1/5. Ez tízes számrendszerben 0,2. Ha ugyanezt 2 (vagy 1/2) hatványaival akarjuk felírni, akkor mi lesz? 1/5 = 1/8+1/16+1/128+1/256+1/2048+1/4096+... ami ez a végtelen kettedes tört lesz: 0,001100110011... Mivel csak véges számjegyen ábrázolhatjuk mindezt, ezért itt mindenképpen lesz egy kerekítés, azaz az 1/5 nem pontosan 0,2, hanem egy icipicit kisebb vagy nagyobb számként lesz tárolva (a kerekítés irányától függően).
És ahogy előttem már írták, ennek semmi köze a Pythonhoz, ez minden programozási nyelven így van, ahol lebegőpontos számábrázolást használunk.
[ Szerkesztve ]
-
-
axioma
veterán
válasz mylastage #2918 üzenetére
Celhoz az eszkozt!
A jelenlegi megkozelites az esetek igen nagy szazalekaban jobban szolgalja az erdekeket, mit mas abrazolasi modok. Igen, lebegopontos abrazolasnal nem lehet egyenloseggel vizsgalni, hanem az elteres nagysagrendjet te meghatarozod ami me'g jo, es arra a kozelsegre vizsgalsz (ne felejtsd el hogy ekozben neked kell kovetned, hogy melyik muveletnel mi lesz a hibahatarod...). Ha ezt valasztod, akkor ezzel kell egyutt elned. Ha stringben tarolod a szamokat es megirod ra a muveleteket, akkor erre mar jo lesz, de (amellett hogy lassu) akkor a Pi-vel nem fog tudni mit kezdeni, vagy a gyok3-mal.
Szerencsere a gyakorlatban a nagyon sokadik ertekes jegynek ugysincs jelentosege, plane mikor tolomerovel mered aztan baltaval szabod le... [pl. a 3.3-bol egeszet kell a vegen csinalni]. -
mylastage
csendes tag
Sajnálom, de nem tudom elfogadni "a számítógépes számábrázolás egyszerűen ilyen",
"a lebegőpontos ábrázolás így működik" stb. kijelentéseket - mert ez nem magyarázat.
15000 évvel ezelőtt (infotech szinten) mikor a Turbo Pascal volt a gyakorló nyelv az oktatásban, két 'int' változó megoldotta a helyi problémát - ami nem volt látható.
Valós időben 25-30 év nem elegendő egy ilyen kulcsprobléma kiküszöbölésére??!
Az ASM szintén 'két' változóban tárolja a tört kifejezést, ha ezt adom meg neki regiszter szinten.
A kérdés még mindig ua. : egy változó értéke hogyan kap értéket az "X" milliomodik helyen, mikor nem adtam meg semmit sem...
(Szeretem a pontosságot; az építőiparban fontos lehet 1-1 cm - szerintem) -
-
axioma
veterán
válasz mylastage #2924 üzenetére
Rendben, epitoipar 1 cm. Legnagyobb tavolsag az epitmenyeknel? 100m? Keme'ny 4 nagysagrend elteres van a ketto kozott (ertsd: viccesen keves, barhol abrazolhato). Szerintem pont egy rossz pelda, ez me'g mm-ben is csak szazezres nagysagrend, tehat siman lehet egesz mm-ben szamolni (de cm-ben me'g 16 biten is).
Ha az M7-est akarod modellezni akkor meg a kituzes/megvalositas nem lesz cm pontos, ott atrakod a leptekedet arra, hogy m/100km.
(Amugy van ahol fontosabb a sokadik szamjegy, pl. masodik/harmadik derivaltat hasznalo szabalyzokorok. De azt nem is pythonban vagy mas magas szintu nyelven irjak...)[ Szerkesztve ]
-
sztanozs
veterán
válasz mylastage #2924 üzenetére
Pascalban az int változó sose vett fel tört értéket. Szerintem az emlékeid ködösítik a múltat. Persze ettől függetlenül a Real így működött, de az már a régmúlt.
Ráadásul ez nem egy python 'tulajdonság' igazából, az utóbbi időben (nem 25 évvel ezelőtt) már ez (banker's round) a sztenderd, azaz a felet mindig a közelebbi páros számhoz kell kerekíteni. Ez egy komolyabb (statisztikai) problémát old meg, mivel a 0.5 mindig felfelé kerekítése mérhető mértékben eltolja a kerekített számok eloszlását.
What’s New In Python 3.0:
The round() function rounding strategy and return type have changed. Exact halfway cases are now rounded to the nearest even result instead of away from zero. (For example, round(2.5) now returns 2 rather than 3.)
For the built-in types supporting round(), values are rounded to the closest multiple of 10 to the power minus n; if two multiples are equally close, rounding is done toward the even choice.
+
Python 3's way (called "round half to even" or "banker's rounding") is considered the standard rounding method these days, though some language implementations aren't on the bus yet.
The simple "always round 0.5 up" technique results in a slight bias toward the higher number. With large numbers of calculations, this can be significant. The Python 3.0 approach eliminates this issue.[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
válasz mylastage #2924 üzenetére
Kis olvasnivaló: https://en.wikipedia.org/wiki/Rounding#Round_half_to_even
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
mylastage
csendes tag
Köszönöm a linkeket és az infót... de...
"Pascalban az int változó sose vett fel tört értéket. Szerintem az emlékeid ködösítik a múltat. Persze ettől függetlenül a Real így működött, de az már a régmúlt."
És mégis működött két integer használatával, és erre homályos foltok nélkül is emlékszem. Az egyik egész számokat, a másik a tört részét tárolta.
"...mivel a 0.5 mindig felfelé kerekítése mérhető mértékben eltolja a kerekített számok eloszlását."
OK, de hol marad a következetesség?! Van egy matematikai rendszer, aminek nem tudok megfelelni.
A másik, hogy 0.5 kerekítése "a páros szám " irányába az miért is nulla?"The Python 3.0 approach eliminates this issue."
...és mégsem...Mint mondottam volt vala... csak egy értelmes megoldást keresek, vagy egy következetes választ...
Az építőipar meg túltekint a www.malter.hu portálon, és már a tervezés is beletartozik, ahol nem mindegy fél cm eltérés sem. Kinek a papné, kinek a vakolat... -
axioma
veterán
válasz mylastage #2931 üzenetére
A paros szamosat szerintem benezted (maradjunk ennel a valtozatnal), pont hogy azert 0.
Az epitoiparban meg tok mind1 hogy mm pontosan szamolsz-e, a valosagban mindennek nagyobb ennel a turese (a teglanak is, nem csak a malternek) Barcsak ne lenne nagyobb gond minthogy "csak" 10 cm-rel szamoltak el magukat... sajna volt szerencsem epitkezni, nem a tervezo a leggyengebb lancszem.. Talan a spektrumos oriashid-epitoknel lehet, hogy mm pontossag kell par specialis muvelethez, de ott se mindenhez, es ott se a szamolason hanem a kivitelezesen szokott mulni. -
nagyúr
válasz mylastage #2931 üzenetére
És mégis működött két integer használatával, és erre homályos foltok nélkül is emlékszem. Az egyik egész számokat, a másik a tört részét tárolta.
rollerblade![ Szerkesztve ]
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
mylastage
csendes tag
válasz velizare #2933 üzenetére
Valami hasonló fapados volt igaz de eltelt 30 év és még mindig nincs megoldás.
Függvények, eljárások, modulok, metódusok próbálnak segíteni az alap_problémán: miszerint nem tud számolni az istenített programnyelv.
A kérdés még mindig ugyanaz:
Hogy(an) írnak nem egyszerű scripteket ebben a programnyelvben, mikor nem tud számolni szegényke...?! -
kovisoft
őstag
válasz mylastage #2935 üzenetére
Korábban azt hittem, hogy tényleg egy probléma megoldásáért fordultál a topikhoz. De most már látom, hogy nem ez a célod, hiszen a megoldásra kaptál már több javaslatot is, hogy ha a konkrét céljaidnak nem felel meg a lebegőpontos aritmetika, akkor milyen egyéb lehetőségeid vannak (egész számok, decimal, fractions, sympy, stb). De valahogy ezeket nem veszed figyelembe. Azt sem vagy hajlandó megérteni, amit szintén már számtalanszor leírtunk, hogy ez nem programnyelv, hanem számábrázolás függő. Más programnyelven is ugyanezzel a problémával fogsz szembesülni lebebőpontos számok használata esetén.
-
nagyúr
válasz mylastage #2935 üzenetére
úgy, hogy megvizsgálják, milyen változók léteznek még, azoknak milyen tulajdonságaik, metódusaik vannak, és igyekeznek egy duplaintes összetákolt megoldásnál könnyebben kezelhetőt választani a céljaik eléréséhez. ez célravezető, a valóság tagadása kevésbé.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
sztanozs
veterán
válasz #29736192 #2939 üzenetére
Használd a Decimal round függvényét (vagy meg kell írni kézzel)
import decimal
from decimal import Decimal as D
context = decimal.getcontext()
context.rounding = decimal.ROUND_HALF_UP
round(D(2.5), 0)JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Siriusb
veterán
gmx.com-ra csatlakozok IMAP4_SSL-lel. A list() által visszaadott találatokban az egyik könyvtárnév kódolva van, mert magyar ékezetes betű van benne, tehát az "á" betűt "&AOE-"-nek mondja (természetesen webes felületen minden rendben). Hogyan lehet ezt dekódolni, illetve ebben a protokollban az UTF-8-at? Az enable('UTF8=ACCEPT') is a kódolt á betűt adja vissza.
Nem fontos kérdés, nehogy valaki időt áldozzon rá, csak ha kisujjban van a megoldás, akkor válaszoljon. Kösz.
-
kovisoft
őstag
válasz GaezhyFeri #2944 üzenetére
Kérésedre idemásoltam ezt a linket: [link]
-
Siriusb
veterán
válasz GaezhyFeri #2944 üzenetére
-
Siriusb
veterán
válasz GaezhyFeri #2947 üzenetére
Ez a modul segít, kösz a tippet.
Telepítettem és bele is kukucskáltam a kódba hogy lássam, mi a baj velem. -
Siriusb
veterán
d = dict.fromkeys(ez_egy_list, [])
Létrehozok egy dictionary-t, amivel az a baj, hogy minden key-hez ugyanaz az üres list objektum kerül. Miként lehet elegánsan megoldani, hogy a value mindegyiknél egy új list objektum legyen?
Új hozzászólás Aktív témák
- Tippmix
- Milyen monitort vegyek?
- HBO Max & OD topic
- Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Elektromos rásegítésű kerékpárok
- Trollok komolyan
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Kecskemét és környéke adok-veszek-beszélgetek
- Egyéni arckép 2. lépés: ARCKÉPSZERKESZTŐ
- Politika
- További aktív témák...
- Creative Hybrid Pro Classic (Egyszer kipróbált, garanciális)
- iPhone 15 Pro 128gb Natúr Titanium, bontatlan, független
- ÚJ Apple Watch Ultra 2 GPS + Cellular 49mm - titántok, alpesi szíj
- 8/16GB memoriák
- APPLE MacBook Air 2020 13" Retina - M1 / 8GB / 256 GB SSD / MAGYAR / 96% akku, 81 ciklus / Garancia