I et nyt scoop har jeg med mine fælles amatør journalister fundet ud af at MobilePay hiver en unfair mængde penge ud af Android brugere, i forhold til Iphone brugere.
Undersøgelsen, der blev bragt ud på Aalborg Universitet, viser at når man dividere i den nye UI på MobilePay, bliver der konsekvent rundet ned på iPhones, alt imens Android telefonerne runder op eller ned, i forhold til de gængse regler.
Undersøgelsen bestod af at prøve at dividere 20 med 3 på MobilePay når man skal sende penge til nogen. Vores prøvestørrelse var en Android telefon og 2 iPhones. Vi opfordrer læsere af dette scoop til selv at afprøve det, og melde ud med deres erfaring.
For at vise den store økonomiske belastning det kunne påføre Android brugere har vi lavet følgende udregning.
Hvis mand hyppigt betaler for sine 2 venner, som begge bruger iPhones, når der skal dagmartærter ind i Lidl til 20 kroner, med forventning om at det betaler dig tilbage over MobilePay, vil efter at have købt 60 dagmartærter være i minus 40 øre i forhold til man ville forvente under retfærdige forhold.
Det er tydeligt hvordan det ville føre til økonomisk ulighed i samfundet, og vi satser på at TV2 eller DR samler op på dette scoop så vi kan få retfærdighed for Android brugerne.
REDIGERING:
Her kan der ses videomatriale af fænomenet. Alle telefoner er også opdateret til den nyeste version af MobilePay
Dette indlæg blev automatisk arkiveret af Leddit-botten. Vil du diskutere tråden? Tilmeld dig på feddit.dk!
The original was posted on /r/denmark by /u/HamDerAnders at 2024-03-25 11:50:54+00:00.
wanze at 2024-03-25 13:12:22+00:00 ID:
kwhbvq0Nej, der er nogen, der ikke har snakket sammen om, hvorvidt der skal bruges
round,floor,ceileller trunkering/intcasting. Eller også er det bare en brainfart.x/y, hvor mindst én erfloat-like kommer aldrig til at resultere i, at du mister decimalerne, uanset om det er skrevet i Swift, ObjC eller JavaScript, som vil være et af de sprog, hvori logikken i iOS-app'en er skrevet.Muligvis parser iOS-app'en tallene forkert, så den laver heltalsdivision, men det er i så fald stadig ikke et spørgsmål om afrundingen.
iAmHidingHere at 2024-03-25 13:17:36+00:00 ID:
kwhcmcmMan laver sjældent finansielle beregninger med floats (hvis man ved hvad man laver).
Abeneezer at 2024-03-25 14:16:06+00:00 ID:
kwhlm4rDet vil sige at det er 50/50 om MobilePay gør det.
iAmHidingHere at 2024-03-25 14:17:55+00:00 ID:
kwhlwsvMan kan sikkert dekompilere den hvis man gider.
wanze at 2024-03-25 16:29:46+00:00 ID:
kwi8upcFuldstændig enig. Jeg bygger sågar selv betalingssoftware til dagligt og alt er (en form for) heltal med eksponenter, så 1 DKK er 100 med eksponent 2.
Men når man forsøger at dividere tal, så kommer man ikke langt, hvis man holder sig til heltal. (Ja, man kan komme lidt længere, hvis man bruger modulo, eller man kan implementere sine egne brøktyper, men det er ikke altid nødvendigt).
ointen var blot, at det her ikke er et spørgsmål om at sprogene laver afrunding forskelligt. Typerne er måske forskellige, men det er en anden snak.
MedianHansen at 2024-03-25 16:57:10+00:00 ID:
kwie9vajeg er ikke helt enig i det du siger. ToInt() kan sagtens afrunde forskelligt, nogle agerer som round, nogle agerer som floor.
wanze at 2024-03-25 19:07:15+00:00 ID:
kwj21tcKan du komme med et eksempel på et sprog, hvor
ToInt()afrunder, fremfor at trunkere?iAmHidingHere at 2024-03-25 19:45:26+00:00 ID:
kwj8y21Den simple afrunding man har brug for her, kan uden problemer laves i heltal, selv for meget store tal. Jeg ved ikke forfærdeligt meget om Swift, men antager de må have et bibliotek som kan gøre dette.
wanze at 2024-03-25 19:53:58+00:00 ID:
kwjai95Jeg synes nu, at det er fint at lave 2000/3 og så afrunde til nærmest øre, fremfor kun at lave trunkering. Så længe man naturligvis sørge for, at de endelige beløb summer til 2000, og som her er heltal. Så længe alt forretningslogik agerer på heltal med eksponenter, så ser jeg ikke et problem i at man slår genvej på den måde i maven af en funktion.
Men ja, der er da sikkert et bibliotek – du har nok ret i, at det ikke er nødvendigt at implementere brøktyperne selv, men det stadig ikke noget, jeg ville introducere en dependency for.
blobfis at 2024-03-25 13:36:19+00:00 ID:
kwhfd5kglem ikke den famøse "round-to-even"
BertoLaDK at 2024-03-25 13:13:54+00:00 ID:
kwhc3gvDet er også en mulighed. Men tror dog næppe det er med intention om at snyde.
KarmusDK at 2024-03-25 13:36:03+00:00 ID:
kwhfbopBeviser for mig at de sakser andres kode i stedet for at tænke kritisk over deres producerede outputs.
wanze at 2024-03-25 16:29:18+00:00 ID:
kwi8rpfNej, det tror jeg bestemt ikke. Hanlon's razor and all.
BertoLaDK at 2024-03-25 17:59:09+00:00 ID:
kwipq1yYup. Selv de klogeste kan overse det mest simple.
mazi710 at 2024-03-26 08:53:45+00:00 ID:
kwm6nzsAltså jeg har siddet med et større IT konsulent firma med 100+ software udviklere, hvor de har lavet et system til os til at konvertere billedformat i en online portal til vores kunder. Det har kostet flere hundrede tusinde kroner.
Efter lang tids frem og tilbage, har jeg med min amatør viden om Python kommet frem til at i stedet for at afrunde tallene så sletter de bare alt efter kommaet ved billede data.
So feks .png billeder og .jpg billeder fungerer ikke ens. .png billeder vil altid hedde feks 299 eller 300 DPI. Hvorimod .jpg billeder kan have en float værdi. Så når man konverteret et 300DPI png billede til jpg, så er det reelt feks 299,99998DPI selvom alt software viser det som 300DPI.
Så vores kunder endte med at afvise alle vores jpg billeder, fordi de ikke var 300 DPI, fordi vores billede software havde lavet dem til 299DPI fordi de bare har slettet alt efter kommaet.
Jovist, mobilepay er endnu større firma. Men jeg ville ikke være overrasket det er en fejl 40.