Hirdetés
- Mobilhasználat külföldön
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Milyen okostelefont vegyek?
- Samsung Galaxy S21 FE 5G - utóirat
- Visszatérnek a Samsung tervezte CPU-magok és GPU az Exynos 2800-ban?
- Yettel topik
- OnePlus 15 - van plusz energia
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- iPhone topik
- Apple iPhone 15 Pro Max - Attack on Titan
Új hozzászólás Aktív témák
-
-
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.
-
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. -
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. -
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...) -
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]. -
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.
-
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.
-
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
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.
-
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
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Titkos szabállyal tereli a hazai megoldások felé a félvezetőgyártóit Kína
- Mobilhasználat külföldön
- LEGO klub
- Ultrakönnyű Logitech "G305" egér? Úgy tűnik, igen!
- World of Tanks - MMO
- OLED TV topic
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- 2026 a GDDR6-os VGA-k éve lesz?
- Exkluzív órák
- Milyen okostelefont vegyek?
- További aktív témák...
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i5-1135G7 4Mag 16GB/512GB FHD IPS
- Bomba ár! Lenovo ThinkPad Yoga 370 - i5-G7 I 8GB I 256SSD I 13,3" FHD Touch I W11 I Cam I Gari!
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W11 I Cam I Gari!
- HP EliteBook 850 G8 Fémházas Tartós Laptop 15,6" -65% i7-1165G7 16/512 Iris Xe FHD
- Bomba ár! Lenovo ThinkPad X390: i5-G8 I 16GB I 256-1TSSD I 13,3" FHD Touch I HDMI I Cam I W11 I Gar
- 2026.01.02 - Frissített Lenovo Gamer árlista (RTX 5090 / 4090 / 5080 / 4080 / 5070Ti / 4070 / 5060)
- Apple iPhone 13Pro 256GB Kártyafüggetlen 1év Garanciával
- BESZÁMÍTÁS! MSI B350M R5 1400 8GB DDR4 240GB SSD 1TB HDD GTX 1060 3GB Rampage SHIVA DeepCool 400W
- HIBÁTLAN iPhone 13 Pro Max 128GB Gold-1 ÉV GARANCIA - Kártyafüggetlen, MS4162, 100% Akksi
- BESZÁMÍTÁS! ASUS H510M i5 11400F 16GB DDR4 512GB SSD RX 6700 10GB Zalman T4 Plus Chieftec 650W
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest