Fachrat Informatik - Forum

Die verschiedenen Methoden zur Abfrage würden mich ja auch mal interessieren. Für Hex haette ich statt Bitoperatoren folgendes anzubieten:

Quoted

Original von Markus
Was spricht gegen '{' in die nächste Zeile? Die Übersicht kann's ja wohl nicht sein? (: Comments?

Wenn man Abschnitt 7.2 der Java Code Conventions auch auf Methodendeklaration anwendet, muss '{' auch dort ans Ende der Zeile. Ich bevorzuge diese Formatierung auch wegen der Konsistenz. (Denn wenn die öffnende Klammer bei compound statements ans Ende der Zeile kommt, dann auch bei Methodendeklarationen.)

off topic: Für dieses Forum würde ich mir eine Konvention wünschen, nach der Antworten ohne zusätzliche Leerzeilen auf das Zitat folgen. - Das sparte Scroll-Arbeit und machte die Zuordnung der Antwort zum Zitat klarer. (Bei code-Blöcken geht das leider nicht.)

@Kaos:Klar, denn ">> 4" ist ja bei ganzen Zahlen das gleiche wie die Division mit 16. Hier auf Bit-Operatoren zu verzichten, dient aber nur der Übung, oder?

Quoted

@Kaos:

	Source code
1	else a = a / 16;

Klar, denn ">> 4" ist ja bei ganzen Zahlen das gleiche wie die Division mit 16. Hier auf Bit-Operatoren zu verzichten, dient aber nur der Übung, oder?

Der Abwechslung

Quoted

Original von migu
@Kaos:

	Source code
1	else a = a / 16;

Klar, denn ">> 4" ist ja bei ganzen Zahlen das gleiche wie die Division mit 16.

Herr Parchmann wies mich soeben freundlicherweise darauf hin, dass dies nur für positive ganze Zahlen gilt.

Dazu will ich ein Beispiel bringen. Negative Ganzzahlen werden im Computer üblicherweise im Zweierkomplement dargestellt.
Beispiel an der Zahl 58:

Binärdarstellung:
00111010

Viermal nach rechts schieben ergibt:
00000011 (=3)

Zweierkomplement bilden (für -58)
11000101 (INV)
11000110 (ADD 1) entspricht -58d

Viermal nach rechts schieben ergibt:
00001100 (=12)

Die Division in Java ergibt hingegen:
58 / 16 = 3
-58 / 16 = -3

Stimmt, mit negativen Zahlen klappt das mit der Division nicht mehr. War aber in der Aufgabestellung nicht verlangt

Außerdem ist da ein kleiner Schönheitsfehler in deinem Post:

Quoted

Original von migu
Zweierkomplement bilden (für -5
11000101 (INV)
11000110 (ADD 1) entspricht -58d

Viermal nach rechts schieben ergibt:
00001100 (=12)

Wenn man in Java negative Zweierkomplementzahlen nach rechts schiebt, wird links nicht mit Nullen sondern mit Einsen aufgefüllt. Richtig wäre also
11000110 um 4 nach rechts verschoben ergibt
11111100 = -4_dezimal

Das verschieben nach rechts ist also auch bei negativen Zahlen durchaus eine Division, nur dass halt nicht in "Richtung 0" gerundet wird, sondern immer in "Richtung negativ".
Das Eregbnis bei der normalen Division ist also quasi wie bei der ganzzahligen Division mit Rest die man aus Mathe in der dritten Klasse kennt
Die Verschiebung spuckt dagegen die größte ganze Zahl aus, die kleiner gleich dem genauen Ergebnis ist.

Ich hoffe das stimmt so.

Quoted

Original von Schokoholic
Wenn man in Java negative Zweierkomplementzahlen nach rechts schiebt, wird links nicht mit Nullen sondern mit Einsen aufgefüllt.

Das wusste ich noch gar nicht. Danke.

Quoted

Original von Schokoholic
Richtig wäre also
11000110 um 4 nach rechts verschoben ergibt
11111100 = -4_dezimal

Stimmt. Ich hab's auch noch einmal nachgeprüft.

Quoted

Original von migu
Wenn man Abschnitt 7.2 der Java Code Conventions auch auf Methodendeklaration anwendet, ...

Hm, das habe ich dann wohl überlesen. Na gut. Aber solange ich nicht im Betrieb arbeite, bleib ich erst mal dabei, wie ich es jetzt mache.

Quoted

off topic: Für dieses Forum würde ich mir eine Konvention wünschen, nach der Antworten ohne zusätzliche Leerzeilen auf das Zitat folgen. - Das sparte Scroll-Arbeit und machte die Zuordnung der Antwort zum Zitat klarer. (Bei code-Blöcken geht das leider nicht.)

@Kaos:

	Source code
1	else a = a / 16;

Klar, denn ">> 4" ist ja bei ganzen Zahlen das gleiche wie die Division mit 16. Hier auf Bit-Operatoren zu verzichten, dient aber nur der Übung, oder?

Sprachs, und hielt sich selbst nicht dran

Quoted

Original von Markus

Quoted

off topic: Für dieses Forum würde ich mir eine Konvention wünschen, nach der Antworten ohne zusätzliche Leerzeilen auf das Zitat folgen. - Das sparte Scroll-Arbeit und machte die Zuordnung der Antwort zum Zitat klarer. (Bei code-Blöcken geht das leider nicht.)

@Kaos:

	Source code
1	else a = a / 16;

Klar, denn ">> 4" ist ja bei ganzen Zahlen das gleiche wie die Division mit 16. Hier auf Bit-Operatoren zu verzichten, dient aber nur der Übung, oder?

Sprachs, und hielt sich selbst nicht dran

Wie meinst du das? (Hast du meinen Beitrag vollständig gelesen?)

Also, wenn ich dich richtig verstanden habe, möchtest du al Konvention, dass nach einem [ quote ] Block keine zusätzlichen Leerzeichen stehen, als so:

Quoted

.

Hier geht es weiter.

Und direkt nach dem du das geschrieben hast, hast du Kaos zitiert:

Quoted

Kaos laber was

Und Migu macht eine zusätzliche Leerzeile

Oder hab ich da was falsch verstanden?

Ihr seid ja bescheuert , was für eine Diskussion...
migu meint, dass man nach codeblöcken um eine überflüssige leerzeile nicht drum herum kommt. "(Bei code-Blöcken geht das leider nicht.)"

Und wieder einmal ist ein Thread Piraten zum Opfer gefallen. Schade.

Quoted

Original von DrChaotica
migu meint, dass man nach codeblöcken um eine überflüssige leerzeile nicht drum herum kommt. "(Bei code-Blöcken geht das leider nicht.)"

Achso, ok.
Anykey, eine höfliche Bitte zum Thema zurück zukehren, hätte es auch getan ... also back to topic.

Quoted

Original von Kaos

Quoted

Original von retr0virus
Wo gerade schonmal ein Thema dazu da ist...
wie ist in der Aufgabe1 zu verstehen, dass keine String-Operationen zu verwenden sind?
Also z.B. kein .charAt() ?
Gerade bei der Methode mit der HEX-Überprüfung wäre es damit ja ein leichtes, nach dem char 'A' zu suchen...

Moin, es gibt sicher einige bessere Ideen als meine, aber du könntest ausnutzen, dass alle 16 Zahlen ein A auftauchen muss (hoffe ich zumindest), angefangen ab der 10.

Das stand auf der allerersten Seite. War gar nicht mal so eine dumme Idee, das lief wohl darauf hinaus die Bedingung (n*16^(a+1)+10*16^a <= x < n*16^(a+1) + 11*16^a => Hexadezimaldarstellung von x besitzt irgendwo ein A) für alle natürlichen Zahlen n und a zu überprüfen, was einen linearen Zeitaufwand bedeutet hätte...Subtraktion von n*16^(a+1) auf beiden Seiten und Lösen der Ungleichung durch Shiften/Dividieren ist dann nur der logische Folgeschritt gewesen, eine Implementierung mit Hexadezimalzähler oder per Schieben führt natürlich in beiden Fällen zur Komplexität O(log(n)). Wenn jetzt noch jemand geschrieben hätte, warum es nicht besser hätte gelöst werden können, wäre das Thema wirklich komplett gegessen worden. Also haben die Piraten somit nun jede Daseinsberechtigung, yo ho.

Na dann:


http://www.xkcd.com/c221.html