Auf eine ganze Zahl aufrunden

[Gast]

Hello,

gibt es in Java eine Funktion welche mir auf einen Integer aufrundet, wenn zum beispiel 1.1 - 2.0 rauskommt, dann soll das Ergebnis auch 2 sein,
Sobald bei einem Ergebnis eine Kommastelle auftritt, soll auf eine ganze Zahlaufgerundet werden,

Gibts sowas?

 

[MiDniGG]

Hm. Ist wahrscheinlich etwas umständlich aba ich würd es so in der Art machen:

Schaun ob die Zahl nen Punkt enthält; die Zahl die vor dem Punkt um Eins erhöhen, aber nur, wenn keine 0 dahinter steht...

Aber geht bestimmt auch einfacher

Edit: Achso. Dazu würd ich s in nen String umwandeln, dass de schön beim Punkt trennen kannst. Und zum Schluss eben in Integer wandeln.

 

[SlaterB]

naja, mit String wirds dann wirklich unschön,
es gibt Math.ceil(), und dann auf int casten

 

[ARadauer]

aufrunden -> ceil

System.out.println((int)Math.ceil(1.1d));
System.out.println((int)Math.ceil(2d));

 

[Soqinho]

Ich bin mir nicht sicher, aber gibts dafür nicht

Math.floor(deineZahl)

Math.floor schneidet die Nachkommastellen weg.

Dann musst du nur noch +1 rechnen und schon hast du dein Ergebnis ...

 

[ARadauer]

ja gute idee sogino, nachdem wir 2 funktionierende lösungen gefunden haben, kommst du daher und machst aus einem 1.0 eine 2

;-)

 

[Soqinho]

Funktioniert doch

Ich tipp einfach zu langsam

 

[ARadauer]

nein funktioniert nicht

bei 2.0 soll 2 raus kommen, wenn du abrundest und +1 rechnest kommt aber 3 raus

 

[Gast]

Hätte noch eine Frage dazu,
ich habe einen Vector<String> in dem unterschiedlich viele Strings drinnen sein können, sagen wir z.B.: 34, dann rufe ich eine Methode auf, wo ich einen Vector übergeben soll, wo immer nur max. 16 Strings drinnen sein sollen, bei 34 Strings rufe ich die Methode dann 3 mal auf mit 2 mal 16 Stings und zum Schluß mit 2 Strings,

Ich wollte das jetzt so realisieren:

vec hat z.B.: 34 Einträge
int amountInvocation = (int)Math.ceil(vec.size()/16d);
for (int i = 0; i < amountInvocation; i++)
      invokeMethode((Vector<String>)text.subList(i*16, i*16+16));

Da habe ich jetzt das Problem, dass ich beim letzten Aufruf nur mehr 2 Strings im Vector habe,
Gibts da eine vernünftige Lösung?

 

[SlaterB]

> bei 34 Strings rufe ich die Methode dann 3 mal auf mit 2 mal 16 Stings und zum Schluß mit 2 Strings

du willst also beim letzen Mal nur 2 Strings in der Liste haben bzw. arbeitest aktiv darauf hin

> Da habe ich jetzt das Problem, dass ich beim letzten Aufruf nur mehr 2 Strings im Vector habe,

und dann beschwerst du dich darüber?

das wäre so als wenn du dein Auto gelb anmalst und dich dann beschwerst, dass es gelb ist,

wenn du es so willst, dann tue es, ansonsten nicht,
ich sehe dabei keine echte Frage?

 

[Marco13]

Wenn immer (möglichst) gleich wiele drin sein sollen, aber nie mehr als 16, kann man das was basteln... schnell hingeschrieben:
int max = 16;
int aufrufe = (int)Math.ceil((float)list.size() / max);
int proAufruf = list.size() / aufrufe;
int letzerAufruf = listSize() - (aufrufe-1) * proAufruf;

Ergibt bei 34 Elementen:
int max = 16;
int aufrufe = ceil(34/16) = ceil(2.xxx) = 3;
int proAufruf = 11
int letzerAufruf = 34-2*11 = 12

Grenzfälle beachten!

 

[ARadauer]

ich finds lustig.
34 durch 16 teilen und sich beschwehren, dass es einen rest gibt *lol* wenn heute freitag wäre, würd ichs verstehen! aber um gottes willen es ist erst mittwoch, was wird da noch kommen......

 

[thE_29]

Ich hab das auch erst vor kurzem entdeckt und gebe das mal gleich weiter

BigDecimal kann das sehr fein!

Das würde zB so aussehen

    new BigDecimal(0.0f).setScale(0, BigDecimal.ROUND_HALF_UP).longValue();

Also bei setScale ist der erste Parameter die Anzahl der Nachkomastellen!
Und der 2te gibt den Rundungsmodus an! Also auf, ab, etc..

 

[Quaxli]

Ich hätte einfach 0.5 aufaddiert und nach int gecastet..

 

[SlaterB]

und könntest damit wirklich auch 1.1 auf 2 runden?

 

[thE_29]

Naja, mit dem bigDecimal kann man auch sagen ROUND_UP!

Dann rundet es immer auf! Wie gesagt, super Methode

 

[Marco13]

Ich find's auch lustig: Da gibt es eine einfache, praktische und perfekt auf das gestellte Problem passende Funktion wie Math.ceil(...), und dann wird bei so einer Trivialbockmistfrage was von BigDecimal erzählt, oder empfohlen, das ganze mit Strings zurechtzumurksen. Erinnert mich an den Klassiker

public boolean isNegative(int i)
{
    if (String.valueOf(i).startsWith("-") == true)
    {
        return true;
    }
    else if (String.valueOf(i).startsWith("-") == false)
    {
        return false;
    }
    else 
    {
        throw new RuntimeException("Achtung, ungültige Zahl!");
    }
}

 

[MiDniGG]

Hey, wegen dem String murksen. Das kam von mir und ich hab als erster geantwortet, weil ich noch nie was von Math.ceil(...) gehört hab. also halt mich da mal raus!!!

^^

Aber der Klassiker hat was ^^

 

[SlaterB]

dann merk dir wenigstens für alle Zahl-Operationen wie z.B. auch das beliebte 'x-te Nachkommastelle herausfiltern':
ein String-Objekt zu erzeugen ist teuer und damit tendentiell immer die falsche Wahl

 

[MiDniGG]

OK. Ich schreibs mir hinter die Ohren

Und schlagt mich, falls ich es je wieder erwähne!!!

 

[thE_29]

@Marco13: es geht einfach drum, das Math.ceil eigentlich nicht fürs runden da ist, sondern das hier macht:

Returns:
the smallest (closest to negative infinity) floating-point value that is not less than the argument and is equal to a mathematical integer.

Was in dem Fall halt das gleiche ist! Würde der TE es auf 1e Kommastelle brauchen, würde es am Besten mit BigDecimal funktionieren.


Aber von der Beschreibung her, hätte/wäre ich nicht so schnell auf ceil gekommen

 

[Marco13]

Ja - es wird halt aufgerundet, und wenn das, was "ceil" macht, kein Runden ist (worüber ich nicht philosophieren will) dann war die Fragestellung falsch :wink: Aber für das Runden zu einer bestimmten Nachkommastelle wäre die Lösung mit BgDecimal vermutlich garnicht verkehrt, weil man damit vermutlich eine höhere Genauigkeit erreichen kann, als mit sowas wie "runde(zahl*100)/100"....

 

[thE_29]

Jo, also ich runde immer mit BigDecimal, weil ich eben immer diese 0.00000001 Differenzen Blödsinn gehabt habe!

Ok, Ceil macht auch runden Aber es ist halt nicht als die "Rundungsfunktion" angedacht. (sonst würds auch explizit im Kommentar stehen)

 

[ARadauer]

Aber es ist halt nicht als die "Rundungsfunktion" angedacht

sondern?

 

[thE_29]

Steht da irgendwas von round? Da wird einfach die nächste ganzzahlige Zahl gesucht!

Bei einer "richtigen" Rundungsfunktion sollte/kann man Parameter übergeben, die das Rundungsverhalten setzen.

 

[SlaterB]

aja,
Collections.sort ist also auch keine erwähnenswerte Sortieroperation,
denn da kann man ja das Sortierverfahren nicht übergeben

 

[thE_29]

Sicher! (einen Comparator)

Außerdem wird da mit Klassenobjekten gearbeitet und die setzen schon die Reihenfolge (compareTo) fest

 

[SlaterB]

Comparator & compareTo legen nur die Ordnung/ Reihenfolge fest,
nicht das Sortierverfahren (BubbleSort & Co.)

war ja eh nicht ernst gemeint, aber solche hohlen Gegenargumente lasse ich auf keinen Fall zählen

 

[thE_29]

Achso, das Sortierverfahren hast du gemeint!

Das kannste ja bei Bigdecimal auch nicht ändern! Also wie er rundet! Vielleicht konvertiert er es ja in einen String :bae: Oder er multipliziert es mal den Kommastellen und nimmt Math.ceil

 

[Marco13]

Diese :bae: und :wink: sind garnicht mal sooo berechtigt: Ich habe mal mit BigDecimal rumhantiert, und mich dann gewundert, warum das Programm (das u.a. BigDecimals in doubles konvertiert hat) doch so EXTREM langsam war. Als ich mir dann angesehen habe, wie die Konvertierung von BigDecimal in double abläuft, bin ich beinahe abgebochen:
:autsch: :autsch: :autsch:

    public double doubleValue(){
	if (scale == 0 && intCompact != INFLATED)
	    return (double)intCompact;
	// Somewhat inefficient, but guaranteed to work.
	return Double.parseDouble(this.toString());
    }

:autsch: :autsch: :autsch:
"Somewhat inefficient" ist gut. Für viele potentielle, praktische Anendungen ist das damit schlicht und einfach unbrauchbar

 

[thE_29]

Oho!
Naja, wer weiß was Math.ceil macht! Das liegt ja in irgendeiner dll rum.

Manchmal isses halt besser, man sieht den Source erst gar nicht