som php niet juist
Ik maak een som per datum in mysql Er zit echter een minim verschil op. Waarom?
Quote:
14/04/2021, 6.3, 18.450000286102295
14/04/2021, 5.85, 18.450000286102295
14/04/2021, 6.3, 18.450000286102295
27/03/2021, 6.99, 6.989999771118164
20/02/2021, 6.5, 62.44000053405762
20/02/2021, 6.5, 62.44000053405762
20/02/2021, 6.99, 62.44000053405762
20/02/2021, 7.5, 62.44000053405762
14/04/2021, 5.85, 18.450000286102295
14/04/2021, 6.3, 18.450000286102295
27/03/2021, 6.99, 6.989999771118164
20/02/2021, 6.5, 62.44000053405762
20/02/2021, 6.5, 62.44000053405762
20/02/2021, 6.99, 62.44000053405762
20/02/2021, 7.5, 62.44000053405762
Prijs is van type float.
Ik lost dit natuurlijk op via number_format. Ik wil enkel weten waarom en hou betrouwbaar is rekenen met sql.
Jan
Het staat wel ongeveer in de handleiding van MySQL, met FLOAT werk je met 4 bytes ofwel 32-bit precisie, dat is te weinig om betrouwbaar met prijzen te werken. Je kunt het aantal bits verhogen naar 64 met een DOUBLE. Dat verbetert de precisie, maar het probleem blijft, geeft MySQL toe.
Als je de details wilt weten kan je het artikel What Every Computer Scientist Should Know About Floating-Point Arithmetic lezen. Je bent niet de enige die er last van heeft, iedereen heeft er last van, zelfs Excel.
De oplossing is om prijzen en alles wat precies moet blijven op te slaan met het datatype DECIMAL of NUMERIC. Bijvoorbeeld met DECIMAL(12,3) kan je 12 cijfers opslaan, waarvan de laatste 3 achter de komma. Dat is en blijft precies, exact wat je moet hebben voor prijzen en boekhoudkundige dingen.
Toevoeging op 17/04/2021 11:13:06:
Nog even aangaande het 'natuurlijk' oplossen met number_format().
Mijn persoonlijke voorkeur is NumberFormatter, die kan rekening houden met een locale zonder dat je setlocale() hoeft te gebruiken, zodat je nooit hoeft na te denken over conflicten tussen localen voor thread safe PHP en non-thread safe PHP.