20 svar · 2 751 visningar · startad av david760
Hej jag ska skriva ett prgram sm med hjälp av typomvandling omvandlar ett inmatat decimaltal till närmaste hel tal. exempel 34.5 avrundar till 35
Så här långt har jag kommit
:
public class uppgift3_3 {
public static void main(String[] args) {
char tecken = 97;
System.out.println("tecken = " + tecken);
System.out.print("Mata in ett nytt tecken: ");
tecken = Keyboard.readChar();
System.out.println("tecken = " + tecken);
}
}
En liten hjälp på vägen:
* läs in ett flyttal till en variabel (ex. tal)
* Antingen använd språkets inbyggda avrundningsfunktion (kan heta round någontin) eller addera talet med 0,5 och gör sedan om det till ett heltal.
Btw: om man följer reglerna så borde 34,5 avrundas till 34 inte 35 (iallafall dom regler jag lärt mig någon gång på forntiden :) )
Btw: om man följer reglerna så borde 34,5 avrundas till 34 inte 35 (iallafall dom regler jag lärt mig någon gång på forntiden :) )
Jag har lärt mig tvärtom, vilket enligt min vetskap är det mest vedertagna. Avrundar man 34,5 till heltal så blir resultatet 35. Däremot så avrunda 34,49 till 34.
Avrunda rätt:
http://www.matteguiden.se/matte-a/grunder/tal-i-decimalform/#Avrunda-rtt
Om man nu ska gå in på matematisk teori har både GunnarD och Compusa rätt - det beror på vilken avrundningsmetod man förespråkar. GunnarD har lärt sig Bankers' rounding, och det är den metod jag brukar använda också.
http://en.wikipedia.org/wiki/Rounding#Round_half_to_even
Men det var bara en liten parentes. :)
Det är iofs den ganska stor parantes, den har lärts ut i Sverige någon gång för länge sedan, men det som lärs ut nuförtiden, och nog får anses korrekt, är att alltid avrunda uppåt om det är 50/50
En liten hjälp på vägen:
* läs in ett flyttal till en variabel (ex. tal)
* Antingen använd språkets inbyggda avrundningsfunktion (kan heta round någontin) [...]
Jupp, Math.round() borde vara användbart :)
Well. Om man programmerar i .NET kan man prova att konvertera 34.5 resp 35.5 till heltal så får man se vad som händer. Menar onkelborg att talfunktionerna i .NET gör fel?
men det som lärs ut nuförtiden, och nog får anses korrekt, är att alltid avrunda uppåt om det är 50/50
När man i framtiden tar bort 50öringen och bara räknar med kronor, så kommer konsumenterna att förlora om man alltid höjer .5 till jämn krona, om man däremot avrundar till närmsta jämna krona så kommer det att gå jämt upp med tiden.
I det läget föredrar jag nog det sättet jag lärt mig :)
Well. Om man programmerar i .NET kan man prova att konvertera 34.5 resp 35.5 till heltal så får man se vad som händer. Menar onkelborg att talfunktionerna i .NET gör fel?
Hm, om jag ska vara ärlig så har jag inte hört talas om att det här sättet att avrunda på fortfarande användas innan jag hade läst den här tråden. Har precis gjort lite empiriska studier och vid snabb anblick konstaterat att .NET avrundar som nämnts, men javascript avrundar alltid uppåt vid 50/50. Måste undersökas mer :)
Har tittat lite mer på det hela, hittade följande tråd som är intressant: http://stackoverflow.com/questions/977796/in-c-math-round2-5-result-is-2-instead-of-3-are-you-kidding-me
[edit]Mer exakt: http://stackoverflow.com/questions/977796/in-c-math-round2-5-result-is-2-instead-of-3-are-you-kidding-me/1606252#1606252 [/edit]
C/C++, Java, Perl och Javascript verkar bete sig som de ska, .NET har den lite udda buggen (eftersom att .NET följer en IEEE-standard.. Ibland är inte standarder av godo, men det går att komma runt med en overload.)
Hur som haver, det blir nog till att skriva en extensionmethod till i biblioteket :)
onkelborg: Är det en bugg om det är per design? :)
Jag gillade Skeets svar: "In particular, history has shown that it's not the expected behaviour - and in most cases that's a cardinal sin in API design."
Det är en bugg ur alla användares och programmerares ögon, även fast det är en "feature". Ungefär som att .NET Framework, till skillnad mot alla andra bibliotek och mjukvaror, bara körde med max två samtidigt anslutningar mot en webbserver pga. att det stod så i en spec :)
(Jepp, jag är lite hård, t.ex. kallade jag lite av Tele2:s mjukvara för virus för ett tag sedan..)
Hade vi använt din definition av buggar i vårt företag hade vi inte kunna ta betalt för många förändringar ("buggar") våra kunder ber om eftersom det oftast är per design. Men jag förstår absolut din ståndpunkt! En produkt ska inte fungera efter en standard/specifikation utan det förväntade beteendet hos användarna.
Nja, snarare så att bara för att man byter utvecklingsmiljö så ska inte sådana simpla saker som avrundning börja fungera på ett annat sätt. Det klassar jag nog som en bugg. (Sen att det är per design, och dessutom följer en rekommendation i en standard är en annan sak..) Utöver standarden så är det som används överallt annars avrundning uppåt vid 50/50, om man bortser ifrån att avrunda till jämnt har lärts ut en gång i tiden när man inte visst bättre ;) Någonstans borde någon tänkt till lite i designprocessen..
(Så vitt jag förstår så är det alltså ett designval i .NET Framework, inte i t.ex. C#. C# i sig säger ingenting om hur en avrundning ska ske.)
(I fallet med antal anslutningar mot en webbserver så ser jag att jag formulerade mig klumpigt, och tänkte fel. Jag backar på den. Det är ok, det är trots allt ganska högnivå, även om det är lite störande.)
När man i framtiden tar bort 50öringen och bara räknar med kronor, så kommer konsumenterna att förlora om man alltid höjer .5 till jämn krona,
I det läget föredrar jag nog det sättet jag lärt mig :)
Är det verkligen så?
Om vi tänker oss att vi har talen
34.0
34,1
34,2
34,3
34,4
-------------
34,5
34,6
34,7
34,8
34,9
så kommer de fem första att avrundas till 34 och de fem sista att avrundas till 35. Sålunda lika många avrundningar uppåt som nedåt, vilket borde ge en jämn fördelning av "felen" ?
Fast 34.0 behöver ju inte avrundas, det är ju redan ett heltal :)
Jag tillhör nog de yngre som fått lära sig att 0,5 avrundas uppåt. Under tioöringarnas utdöende tid lärde jag mig att >= 0,25 blir 0,50 och >= 0,75 blir 1. Dock tycker jag att avrundning nedåt/uppåt beroende på jämn/ojämn siffra var väldigt spännande :)
Är det verkligen så?
Om vi tänker oss att vi har talen
34.0
34,1
34,2
34,3
34,4
-------------
34,5
34,6
34,7
34,8
34,9så kommer de fem första att avrundas till 34 och de fem sista att avrundas till 35. Sålunda lika många avrundningar uppåt som nedåt, vilket borde ge en jämn fördelning av "felen" ?
Eftersom du har 34.0 med så skall du ha 35.0 med, annars blir inte medel 34.5 och det blir obalans.
34.0
34.1
34.2
34.3
34.4
---------
34.5
---------
34.6
34.7
34.8
34.9
35.0
Nu har du 5 tal på varje sida och om man då alltid höjer 34.5 så kommer 5 av 11 avrundas till 34 och 6 av 11 avrundas till 35 vilket ger en obalans men om man avrundar .5 till närmsta jämna så blir balans över tiden. (ju fler avrundingar desto bättre balans blir det)
Var inte det just av-rundningen som det gick så mycket "hacker" myter om. Hackers som lyckats stoppa in en liten kod snutt i en bankernas datasystem. Var gång det skulle betalas ut en summa som avrundades så hamnade mellanskillnaden på hackerns konto. Många transaktioner senare blev det en rejäl slant på kontot. Myt eller verklighet, men bra "saga" är det.
En JÄTTE parantes i sammanhanget.
Var inte det just av-rundningen som det gick så mycket "hacker" myter om. Hackers som lyckats stoppa in en liten kod snutt i en bankernas datasystem. Var gång det skulle betalas ut en summa som avrundades så hamnade mellanskillnaden på hackerns konto. Många transaktioner senare blev det en rejäl slant på kontot. Myt eller verklighet, men bra "saga" är det.
Verklighet, är ett program hot av typen Trap Door. Flera programmerare har blivit arresterade för detta brått. Man har ofta inte gömmt den felaktiga avrundningen i koden utan i kompilatorn vilket gör det svårt att upptäcka.
Sen finns det en film där några noobs gör det och dom råkar göra fel så dom får för mycket pengar.
SRY för OT
Var inte det just av-rundningen som det gick så mycket "hacker" myter om. Hackers som lyckats stoppa in en liten kod snutt i en bankernas datasystem. Var gång det skulle betalas ut en summa som avrundades så hamnade mellanskillnaden på hackerns konto. Många transaktioner senare blev det en rejäl slant på kontot. Myt eller verklighet, men bra "saga" är det.
Office Space! :D