Zahl aufgerundet stimmt dennoch nicht?

  • Themenstarter Themenstarter Sup3rm4n
  • Beginndatum Beginndatum
Status
Nicht offen für weitere Antworten.
S

Sup3rm4n

Gast
hallo,

Code:
String information   =  "Warum werden immer alle Zeilen -1 Zeile ausgegeben? Ich weiß nicht warum, aber es fehlt immer 1 Zeile am Ende die nicht mit ausgegeben wird egal was ich mache. Probiert es bitte selbst aus es ist wirklich komisch. Denn ich runde ja auf tja was kann ich da nur tun?";
		

int zeilenLaenge = 60 ; 
int anzahlZeilen = (int)Math.ceil(information.length() / zeilenLaenge);
System.out.println("Number of Lines: " + anzahlZeilen + " " + "Number of Chars totally: " + information.length());


Warum bekomme ich bei einer Textlänge von 264 Zeichen nur 4 Zeilen raus anstatt 5 bzw. 4 Rest 24 (264/60) ergibt ja 5 aufgerundet nicht ???:L
 
int anzahlZeilen = (int)Math.ceil( information.length() / zeilenLaenge);

Dort teilst du einen int durch einen int - der Nachkommaanteil wird ageschnitten. Sieht man auch bei
int a = 3 / 4; // Jetzt ist a == 0 !!!

So müßt's gehen:
int anzahlZeilen = (int)Math.ceil( (float)information.length() / zeilenLaenge);
 
Die Verwendung von float sollte man so gut es geht vermeiden. Versuch es mal so:

Code:
int zeilenLaenge = 60 ; 
int anzahlZeilen = (information.length() + zeilenlaenge - 1 ) / zeilenLaenge;

Fred
 
Anonymous hat gesagt.:
Die Verwendung von float sollte man so gut es geht vermeiden. Versuch es mal so:

Code:
int zeilenLaenge = 60 ; 
int anzahlZeilen = (information.length() + zeilenlaenge - 1 ) / zeilenLaenge;

Fred

Das ergibt keinen Sinn was du da schreibst mit "+" , der Tip mit float geht, danke dirr!
 
Hi,

warum Math.ceil() nicht aufrundet liegt daran, dass du einen integer durch einen integer teilst,
das Ergebnis ist auch ein integer, diesen kannst du zwar aufrunden aber ohne Effekt und
Fehlermeldung, weil eine ganze Zahl nicht aufgerundet wird und es auch kein Fehler
ist eine ganze Zahl aufzurunden.

Der Unterschied ist der, dass du bei der 1. Zeile auch eine Nachkommastelle hast die
aufgerundet werden kann, oder auch nicht falls die Rechnung aufgeht ohne Rest.


Code:
int z1 = (int)Math.ceil((float)264 / 60);
int z2 = (int)Math.ceil(264 / 60);
int z3 = (int)Math.ceil((float)240 / 60);

System.out.println(z1 + " " + z2 + " " + z3);

Grüße Ralf
 
Anonymous hat gesagt.:
Die Verwendung von float sollte man so gut es geht vermeiden. Versuch es mal so:

Code:
int zeilenLaenge = 60 ; 
int anzahlZeilen = (information.length() + zeilenlaenge - 1 ) / zeilenLaenge;

Fred
ups...

habe das "/zeilenLaenge" als Kommentar gelesen :bae:
 
Code:
public static void main(String[] args)
	{		
		i

		String  information = "Ist die Welt den  überhaupt denn wahr sein oder ist das verarsche? Ich bin mir sicher der Fernsehr ist nicht verschwunden oder verloren gegangen, sondern die Monitore wurden letztes mal in die Hand genommen als er mich arsch nannte...hahahahah hätte er wenigstens arschloch gesagt doch so ist es ein Beleidigung und Mobbing zugleich..."; 
             int zeilenLaenge =  50;  
	     int anzahlZeilen = (int)Math.ceil((float)information.length() / zeilenLaenge);
			    
	     String[] outputArray = new String[anzahlZeilen];
	
	     int start = 0; 
	     int end = zeilenLaenge; 
	     System.out.println("Zeilen insgesamt: " + anzahlZeilen + "   Zeichen insgesamt: " +  information.length());    
	      
               for( int i = 0 ; i < outputArray.length ; i++) 
	      {  
	    	
	    	 String zeilenInhalt =  information.substring(start,end);	    	 
	         outputArray[i] = zeilenInhalt;		         
	         System.out.println(outputArray[i]); 
	         end  =  end + zeilenLaenge; 
	         start =  end -  zeilenLaenge;	         
	      }			     
		
	}

}

FehlerCode:
Code:
Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 350
	at java.lang.String.substring(Unknown Source)

Irgendwas stimmt mit dem String.substring nicht und deren Werten ich komme aber nicht drauf. Dachte mir schon dass der substring wert wenn er das letzte mal in der schleife aufgerufen wird evtl zu groß ist und somit keinen text erfasst, wenn die letzte Zeile keine volle 50 Zeichen hat.
 
Code:
System.out.println("Zeilelänge: " + zeilenlänge);
	        if(end > zeilenlänge)
	        {
	        	end = zeilenlänge;
	        	
	        }	
	        else
	        {
	        	
	        }

ok habs schon ;-)
 
darüber könnte man wirklich streiten.

float ist natürlich ein erheblicher mehraufwand für den prozessor. aber ich werde auf einem 3 ghc rechner, bei dem die bottelnecks sicherlich bei der festplatte oder im netzwerk liegen, sicher keine formeln umschreiben damit ich keine float brauche. und mir da irgendwo eine ns spare

optimieren nur wos sinn macht, wenn ich ein j2me programm habe, dann lass ichs mir einreden. aber desktop? ???:L
 
der Hinweis macht schon deshalb Sinn,
um float hier im Forum nicht zu verbreiten,

keiner meckert über alte Formeln aber wenn man hier neue schreibt, dann doch bitte ohne

(ob nun float überhaupt so schlimm ist will ich nicht beurteilen)
 
Vielleicht hätte ich das " :?: :!: ???:L :bahnhof: " etwas präziser formulieren sollen: Was spricht gegen float? Sowas wie

int x = Math.ceil(size / 10.0f);

liest doch doch wohl besser (und ist leichter versändlich) als

int x = (size + 10 - 1) / 10;

Man könnte (wenn man es drauf anlegen würde) ja float "fast immer" vermeiden, aber wie groß sollen die Verrenkungen dafür denn sein? Welcher Anlaß besteht denn dafür?
 
Marco13 hat gesagt.:
Anonymous hat gesagt.:
Die Verwendung von float sollte man so gut es geht vermeiden.
:?: :!: ???:L :bahnhof:
Nicht wegen Performance, sondern weger der auftretenden Ungenauigkeiten.

information.length() ist ein int. Wenn man den auf float castet, gibt es schon Rundungsfehler, weil nicht jeder int in einen float passt.

Nimm als Beispiel den Wert 19999981 für information.length(). Mein Taschenrechner sagt mir:

19 999 981 / 60 = 333 333.017

Aufgerundet sollte das also 333 334 ergeben. Folgendes Programm zeigt, dass man kein float verwenden sollte:

Code:
int informationlength = 19999981;
int zeilenLaenge = 60;

int mitInt = (informationlength + zeilenLaenge - 1) / zeilenLaenge;
int mitFloat = (int)Math.ceil((float)informationlength / zeilenLaenge);

System.out.println("  int: " + mitInt);
System.out.println("float: " + mitFloat);



// Ausgabe:

  int: 333334
float: 333333

Fred
 
Nun - man könnte jetzt sagen, dass Math ja sowieso überall double verwendet, und man deswegen auch gleich nach double casten kann - wäre das dann OK? Ja, vielleicht... aber wenn man dann einen long als Eingabe hat.... :roll:

Man hat IMMER mit beschränkter Genauigkeit zu kämpfen - man muß sich halt im klaren sein, wo die auftreten kann...
Code:
class FloatTest
{

    public static void main(String args[])
    {
		test(19999981);
		test(2147483647);
    }

    private static void test(int informationlength)
    {
		System.out.println("Input : "+informationlength);
		int zeilenLaenge = 60;
		int mitInt = (informationlength + zeilenLaenge - 1) / zeilenLaenge;
		int mitFloat = (int)Math.ceil((float)informationlength / zeilenLaenge);
		int mitDouble = (int)Math.ceil((double)informationlength / zeilenLaenge);
		System.out.println("   int: " + mitInt);
		System.out.println(" float: " + mitFloat);
		System.out.println("double: " + mitDouble);
	}
}

Ausgabe:
Input : 19999981
int: 333334
float: 333333
double: 333334
Input : 2147483647
int: -35791393 Hoppla :shock:
float: 35791396
double: 35791395

Aber grundsätzlich akzeptiere ich das mal als Argument - Aber nur für diesen speziellen Fall. Einige Antworten klangen, als sei float grundsätzlich falsch und böse. Es kommt eben auf den Zusammenhang an...
 
Marco13 hat gesagt.:
Nun - man könnte jetzt sagen, dass Math ja sowieso überall double verwendet, und man deswegen auch gleich nach double casten kann - wäre das dann OK?
Wenn die Ausgangswerte vom Typ int sind kann man ruhigen Gewissens mit double rechnen, da jeder int ohne Verlust nach double gecastet werden kann. Trotzdem finde ich die Lösung irgendwie unschön, weil einen das double-Ergebnis mit den ganzen Nachkommastellen ja gar nicht interessiert, sondern die GANZZAHLIGE Lösung. Daher finde ich es auch logisch, ausschließlich mit Ganzzahlen zu rechnen.

Marco13 hat gesagt.:
Ja, vielleicht... aber wenn man dann einen long als Eingabe hat.... :roll:
Dann wird double für große long-Werte nicht mehr funktionieren, da long 64 Bit Genauigkeit hat und double nur 53 Bit.
 
Status
Nicht offen für weitere Antworten.

Zurück
Oben