sciencetalk

Xilvo schreef: ↑za 08 aug 2020, 12:54 Ik zie nog steeds dat verschil van 0,05

kopt. dat is bij een offset van 0.05. de functie berekent het gemiddelde uit 1 miljoen getallen als functie van de offset. Bij offset=0 is de afwijking tussen gemiddelde van de afgeronde getallen en de niet afgeronde getallen wel 0. Dat is wat het laatste grafiekje ook laat zien.

Xilvo schreef: ↑za 08 aug 2020, 12:47 500,0005
en
500,0509
Dat lijkt me een niet te verwaarlozen verschil.

Ik heb hetzelfde gedaan in Python, en dan vind ik dat verschil niet.
Maar dat komt omdat 'round' in numpy het heel netjes doet om systematische fouten te voorkomen:

For values exactly halfway between rounded decimal values, NumPy rounds to the nearest even value. Thus 1.5 and 2.5 round to 2.0, -0.5 and 0.5 round to 0.0, etc.

Mathcad is juist bedoeld om lastige berekeningen te doen, dus doet qua afronden wat het moet doen. Dat verschil komt dus niet omdat Mathcad 'verkeerd' afrond, maar omdat ik bewust een offset had aangebracht om te kunnen zien bij welke offset het exact klopt en dat is dus offset=0 dus afronden >=5 naar boven en <5 naar beneden. offset 0.05 betekent afronden naar boven bij >=4.5 naar boven en <4.5 naar beneden

Controleer eens hoe Mathcad getallen afrondt.
Wat wordt 2,65 afgerond op 1 decimaal, wat wordt 2,75 op 1 decimaal.

Dat doet numpy anders.
>>> print(np.round(2.65,1))
2.6
>>> print(np.round(2.75,1))
2.8

Dat betekent dat je nooit gelijke waardes voor het gemiddelde kunt krijgen met offset = 0.
Je krijgt een bias omdat je 1 2 3 4 (vier waardes)naar beneden afrondt en 5 6 7 8 9 (vijf) naar boven

je vergeet de 0.
met 5 afronden naar boven heb je hetvolgende:
0,1,2,3,4 is 5 getallen
5,6,7,8,9 is 5 getallen
(wat ik al eerder had aangegeven)

HansH schreef: ↑za 08 aug 2020, 16:14 je vergeet de 0.

Nee. Bij de nul rond je niet af, dat getal blijft ongewijzigd.

Het gemiddelde wordt wel beinvloed door het aantal getallen wat je gebruikt.
als de de serie van 0-1 gebruikt in stapjes van 0.01 dan krijg je als verschil tussen het getal en het afgeronde getal het volgende plaatje: het bemiddelde verschil is dan -0.005
maar met meer getallen 0-1 in stapjes van 0.0001 krijg je al een veel kleiner verschil dus als je afrond op basis van een oneindige dichtheid van getallen fan klopt het afronden precies met 5 of meer naar boven en minder dan 5 naar beneden afronden

Xilvo schreef: ↑za 08 aug 2020, 16:16

HansH schreef: ↑za 08 aug 2020, 16:14 je vergeet de 0.

Nee. Bij de nul rond je niet af, dat getal blijft ongewijzigd.

ja er zijn meer getallen die ongewijzigd blijven na afronden, maar wat kun je daaruit concluderen?

HansH schreef: ↑za 08 aug 2020, 17:06

Xilvo schreef: ↑za 08 aug 2020, 16:16

HansH schreef: ↑za 08 aug 2020, 16:14 je vergeet de 0.

Nee. Bij de nul rond je niet af, dat getal blijft ongewijzigd.

ja er zijn meer getallen die ongewijzigd blijven na afronden, maar wat kun je daaruit concluderen?

Dat altijd naar boven afronden als je precies halverwege zit (dus 2,765 naar 2,77 afronden) een systematische fout geeft.

HansH schreef: ↑za 08 aug 2020, 17:05 dus als je afrond op basis van een oneindige dichtheid van getallen fan klopt het afronden precies met 5 of meer naar boven en minder dan 5 naar beneden afronden

Dan wordt je fout inderdaad ook oneindig klein.
Maar bij echte getallen met een beperkt aantal decimalen voor het afronden houd je een systematische fout.

Xilvo schreef: ↑za 08 aug 2020, 17:08 Dat altijd naar boven afronden als je precies halverwege zit (dus 2,765 naar 2,77 afronden) een systematische fout geeft.

Dat had ik proberen toe te lichten in Bericht za 08 aug 2020, 16:05
De systematische fout die je maakt is afhankelijk van de afstand van de getallen tot elkaar. met een oneindige dichtheid aan getallen maak je dus geen systematische fout. Het heeft natuurlijk weinig zin om het afrondmechanisme afhankelijk te maken van de getallen waar jet het op toe gaat passen. Dus dat ze het voor een oneindige dichtheid aan gelijk verdeelde getallen laten kloppen lijkt me dan een voor de hand liggende keuze.

Je moet gewoon zorgen dat bij een 5 er een even grote kans is op naar boven of naar beneden afronden.
Dat doet numpy's round functie correct door naar een even waarde af te ronden.
Vreemd dat Mathcad het fout doet.

Xilvo schreef: ↑za 08 aug 2020, 17:20 Dat doet numpy's round functie correct door naar een even waarde af te ronden.

wat is dan precies de definitie die daar gebruikt wordt?
hoe rond je daar de volgende getallen af naar 1 cijfer achter de komma?:
4.49
4.5
4.51
4.515
4.499
4.50

>>> z=[4.49, 4.5, 4.51, 4.515, 4.499, 4.50]

>>> for x in z:
... print(x,np.round(x,1))
...
4.49 4.5
4.5 4.5
4.51 4.5
4.515 4.5
4.499 4.5
4.5 4.5