Ú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
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- Formula-1
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Jövedelem
- Képregény topik
- Futás, futópályák
- Hitelkártyák használata, hitelkártya visszatérítés
- Vezeték nélküli fejhallgatók
- Kertészet, mezőgazdaság topik
- 5.1, 7.1 és gamer fejhallgatók
- További aktív témák...
- MSI Gaming Thin 15 - 15.6"FHD 144Hz - Ryzen 7 7735HS - 16GB - 1TB - Win11 - RTX 4060 - 2,5 év gari
- Akció! Acer Nitro 5 AN515-55! I7 10750H / RTX 3050Ti / 16GB DDR4 / 512GB Nvme SSD!
- Ryzen7 5700G/ 32GB DDR4/ 1TB m.2 alapú mini PC/ garancia
- AKCIÓ! iMac Pro Intel Xeon W2150B 64GB 1TB VEGA 64 16GB!!! 1 év garancia!
- Dell Latitude 5591 i7/500GB M2 SSD/ 32GB DDR4
- 0% THM 4 havi részlet, beszámítás! Gamer PC, notebook, konzol, Apple termék, hardver KAMATMENTESEN!
- AKCIÓ! CSAK KIBONTOTT Honor 200 Lite 8GB 256GB mobiltelefon garanciával hibátlan működéssel
- HIBÁTLAN iPhone 14 Pro Max 128GB Deep Purple-1 ÉV GARANCIA - Kártyafüggetlen, MS4682
- iPhone 15 Plus 128GB 100% (1év Garancia)- ÚJ EREDETI AKKUMULÁTOR - AKCIÓ
- Lenovo ThinkPad T15 Gen 2 i5-1135G7 16GB Ram 256 GB SSD FHD IPS Garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest