Visual Basic Konsolenanwendung: Größte Zahl ermitteln

  • VB.NET

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Yanbel.

    Visual Basic Konsolenanwendung: Größte Zahl ermitteln

    Hallo Leute,

    ich bin neu hier und mache momentan ein Fernstudium zum Fachinformatiker - Anwendungsentwicklung. Daher hoffe ich, dass ihr mich hier nicht auslacht, wenn ich dumme Fragen stelle :)

    Zu meiner Frage:
    Ich muss eine Konsolenanwendung schreiben und habe 7 vorgegebene Byte-Werte (Zahlen). Von diesen 7 Werten soll ich die größte Zahl ermitteln. Ich habe mir erstmal gedacht, dass ich eventuell folgendermaßen richtig liegen könnte:

    VB.NET-Quellcode

    1. Imports System.Console
    2. Module Module1
    4. Sub Main()
    5. Dim aByte(6) As Byte
    6. Dim i As Integer
    7. Dim größte, größere As Integer
    9. aByte(0) = 19
    10. aByte(1) = 125
    11. aByte(2) = 43
    12. aByte(3) = 200
    13. aByte(4) = 11
    14. aByte(5) = 2
    15. aByte(6) = 84
    16. WriteLine()
    18. For i = 0 To aByte.GetUpperBound(0) - 1
    19. If aByte(i) <> aByte(i + 1) Then
    20. If aByte(i) > aByte(i + 1) Then
    21. größere = aByte(i)
    22. ElseIf aByte(i) < aByte(i + 1) Then
    23. größere = aByte(i + 1)
    24. End If
    25. End If
    26. größte = größere
    27. Next i
    28. WriteLine("Das größte Element hat den Wert: {0}", größte)
    29. End Sub
    31. End Module

    Da kam dann aber leider das größte Element 84 raus. Ich denke mal, dass das daran liegt, weil er im Array ja als letzte Position bzw. letztes Element gezeigt ist. Könntet ihr mir bitte Tipps geben wie man sozusagen innerhalb der Elemente den größten Wert herausfinden kann? Ich hab schon vieles probiert und diese Variante kam mir logisch vor...
    Ich bedanke mich schon mal im Voraus.

    MfG

    CodeTags gesetzt ~VaporiZed

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Pack doch deine Zahlen in eine List(Of Byte) und sortiere diese Absteigend. Die erste Zahl der Liste ist dann die Größte.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Es sieht mir nach Übungsaufgabe aus, wo der Prof keinen Wert auf Frameworklösungen legt.
    Aber auch der manuelle Weg geht kürzer.

    Visual Basic-Quellcode

    1. ​Sub Main()
    2. Dim aByte(6) As Byte
    3. Dim greatest, b As Byte
    4. aByte(0) = 19
    5. aByte(1) = 125
    6. aByte(2) = 43
    7. aByte(3) = 200
    8. aByte(4) = 11
    9. aByte(5) = 2
    10. aByte(6) = 84
    11. WriteLine()
    13. For Each b in aByte
    14. if b > greatest Then greatest = b
    15. Next
    16. WriteLine("Das größte Element hat den Wert: {0}", greatest)
    17. End Sub
    Gewöhn dir Variablennamen mit Umlauten erst gar nicht an.
    Das wirst du sonst irgendwann verfluchen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Fernstudium zum Fachinformatiker für Anwendungsentwicklung, soso... wenn man eine Ausbildung zum Fachinformatiker für Anwendungsentwicklung macht, dann sollte man zumindest wissen, dass das eine Ausbildung ist und kein Studium. Die Studiengänge dazu sind beispielsweise Bachelor of Sience (Wirtschaftsinformatik) oder Bachelor of Science (Softwareengineering) ;)

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    @Yakup07 Willkommen im Forum. :thumbup:
    @petaod Seh ich auch so.
    Aber Du solltest greatest vorher sinnvoll belegen, denn in der nächsten Aufgabe sind das keine Bytes mehr.
    @Yakup07 Initialisiere Deine Ziel-Variable stets so, dass gesichert ist, dass Du den Zielwert auch findest.
    Da gibt es zwei Möglichkeiten:
    • Byte.Minimum
    • aByte(0)
    Wenn Du in der nächsten Runde das Minimum finden sollst, musst Du auf Byte.Maximum initialisieren, aByte(0) funktioniert ebenfalls.
    Wenn Du Dir dies ansiehst, machst Du in diesem Kontext nie einen Fehler, wenn Du das erste Element verwendest.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Das funktioniert dann nicht mehr problemlos, wenn du
    - an einer nicht deutschen Tastatur arbeitest
    - in einem internationalen Entwicklerteam arbeitest
    - in Nicht-UTF-Entwicklungsumgebungen arbeitest
    bis VS2008 wurde beispielsweise der Code in der Codepage des regionalen Windows-Setups gespeichert (in D Codepage 1252)
    das lässt sich in USA unter Umständen gar nicht mehr compilieren, weil du ggf. plötzlich illegale Zeichen im Code hast.

    Ich würde sogar so weit gehend und sagen, dass man sich möglichst der Sprache der Programmiersprache anpasst.
    Und die ist bei fast allen Programmiersprachen englisch.
    Das ist einfach lesbarer als ein denglisches Sprachgemisch.

    Solange du in deiner Kammer vor dich hinprogrammierst, kannst du alles verwenden, was die IDE frisst.
    Aber besser ist es, wenn du dir gleich angewöhnst, universell zu codieren.
    Vielleicht willst du das ja mal zu deinem Beruf machen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    oobdoo schrieb:

    ich hatte gedacht das solche Probleme der Vergangenheit angehören.
    Die Globalisierung ist eher Zukunft als Vergangenheit.
    Und wenn du heute in internationalen Teams arbeiten willst, müssen sich alle verstehen.

    oobdoo schrieb:

    Mit 50 bestimmt nicht mehr
    Na gut, du vielleicht nicht.
    Aber der TE, dem der ursprüngliche Rat ja galt, scheint in die Richtung gehen zu wollen.
    Auch wenn ich den wagen Verdacht hege, dass ihn dieser Thread überhaupt nicht mehr interessiert.
    Zumindest hat er sich nicht mehr gemeldet.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    petaod schrieb:


    Gewöhn dir Variablennamen mit Umlauten erst gar nicht an.
    Das wirst du sonst irgendwann verfluchen.


    Kann ich nur zustimmmen. Daher programmieren die meisten Entwickler mit englischen Bezeichnern.

    Zurück zum Thema:

    VB.NET-Quellcode

    1. Dim IntList As New List(of Integer)
    2. Dim MaxInt As Integer = 0
    4. IntList.add(19)
    5. IntList.add(125)
    6. IntList.add(43)
    7. IntList.add(200)
    8. IntList.add(11)
    9. IntList.add(2)
    10. IntList.add(84)
    12. MaxInt = IntList.Max()

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.

    @Yanbel
    Siehe Post #4
    Meine Vermutung geht dahin, dass solche Lösungen vom "Auftraggeber" unerwünscht sind, da auf traditionelle Weise programmiert werden soll.

    Aber das werden wir wohl kaum erfahren, wenn sich @Yakup07 nicht mehr meldet.
    Solange betrachte ich diesen Thread als tot.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Sorry hab mich nicht gemeldet, weil ich erstmal schauen wollte, ob ich es allein schaffe. Wie @petaod schon sagte, muss ich es anders lösen. In dem Studienheft geht es um Arrays, Prozeduren und Funktionen. Ich bin das Heft jetzt dreimal durchgegangen und hab leider nichts gefunden, was mir annähernd weiterhelfen könnte. Ich musste vorher eine Konsolenanwendung, bei der man das Alphabet richtig sortiert. Das könnte ich eventuell machen... dass er die Zahlen erstmal nach Größe sortiert und dann den größten automatisch dadurch findet. Was mich interessieren würde, ist: Was ist eigentlich der Unterschied zwischen For Each und For ... Next i (i einfach nur als Beispiel)?

    Ich danke euch wirklich sehr. Nochmals sorry, dass ich so spät antworte... Hoffentlich bin ich mit diesem Studienheft so schnell wie möglich fertig...

    MfG

    Yakup07 schrieb:

    der Unterschied zwischen For Each und For ... Next i
    For i = 1 To n ... Next i läuft durch die Schleife mittels einer Index-Variablen (i).
    Du musst den Anfang und das Ende vorher kennen.
    Dafür hast du einen Schleifenzähler (Index) und weißt immer, an welcher Position im Array du bist.
    Du musst aber auch das Array-Element per Index selektieren.
    Diese Variante wird gern für Zahlen genommen. Man kann z.B. auch in grösseren Schritten zählen (Step).

    Bei For Each werden einfach alle Elemente des Arrays (oder der Liste oder der Aufzählung) durchlaufen.
    Wenn du den Schleifenzähler nicht brauchst, ist das die einfachere Variante.
    Das Array-Element wird direkt der Schleifenvariable zugewiesen.

    docs.microsoft.com/de-de/dotne…s/for-each-next-statement
    docs.microsoft.com/de-de/dotne…ements/for-next-statement

    Yakup07 schrieb:

    Das könnte ich eventuell machen... dass er die Zahlen erstmal nach Größe sortiert und dann den größten automatisch dadurch findet.
    Ja, deinem ersten Versuch sieht man an, dass er aus einem Sortieralgorithmus stammt.
    Sortieren ist etwas komplizierter als nur den Maximalwert bestimmen.

    Wie du den verschiedenen Vorschlägen entnehmen kannst, wird normalerweise weder Sortieren noch Maximalwertberechnung "von Hand" ausprogrammiert.
    Da hat das Framework sehr effiziente Methoden schon an Bord.
    Aber für die Grundlagen ist es ganz gut, wenn du weißt, wie man es selbst macht.

    Zum Schluss noch eine Anmerkung zu deiner Namensgebung.
    aByte ist ungarische Notation.
    Das Prefix a bedeutet, dass es sich um ein Array handelt.
    Solche Prefixe stammen aus Zeiten, als die Entwicklungsumgebungen noch nicht typsicher waren.
    In modernen Umgebungen ist das absolut überflüssig,
    Es gibt im Netz kilometerlange Abhandlungen darüber (pro und kontra).
    Doch die maßgebensten Richtlinien für .Net-Programmierer sind die Microsoft Design Guidelines.
    Dort steht in den Naming Conventions ganz klar:
    DO NOT use Hungarian notation

    Es kann gut sein, dass du damit bei deiner Ausbildung aneckst.
    Ausbilder/Lehrer/Professoren/Bücherschreiber sind halt oft vom alten Schlag und nicht besonders lernwillig.
    Dann mach es halt, wie es von dir verlangt wird.
    Aber du solltest es wenigstens mal gehört haben, dass diese Namensgebung gegen die Konvention ist.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „petaod“ ()

    Danke dir vielmals. Erstens hast du den Unterschied sehr gut erklärt und zweitens noch einen Tipp gegeben, den ich auf jeden Fall berücksichtigen werde. Ich danke nochmals auch allen anderen für eure Hilfe und die Zeit, die ihr euch genommen habt. Endlich mal ein Forum, wo man tatsächlich sofort Antworten bekommt, und zwar so nützliche dazu :D

    MfG

    petaod schrieb:


    Meine Vermutung geht dahin, dass solche Lösungen vom "Auftraggeber" unerwünscht sind, da auf traditionelle Weise programmiert werden soll.


    Jo... schätze es hätte geholfen, wenn ich alle Kommentare gelesen hätte :D Danke für den Hinweis :thumbup:

    Ein Computer wird das tun, was du programmierst - nicht das, was du willst.