Wertebereich//Datentyp
-
@SeppJ sagte in Wertebereich//Datentyp:
Dann gibt aber deine physische Hardware die logischen Anforderungen an die Software vor. Schlechte Praxis!
Versteh ich nicht. Ich entwickle meine Software immer auf und für Hardware
️ Aber nimm von mir aus unint32_t und Konsorten.
-
@Tyrdal sagte in Wertebereich//Datentyp:
Versteh ich nicht. Ich entwickle meine Software immer auf und für Hardware
️ Aber nimm von mir aus unint32_t und Konsorten.Auftraggeber spezifiziert: Software muss ganzzahlige Werte bis 9999999999999 unterstützen. Tyrdal nimmt int, weil das der native Datentyp der Maschine für Ganzzahlen ist, was ja richtig sein muss.
Auftraggeber spezifiziert: Rechnung muss exakt sein auf drei dezimale Stellen. Tyrdal nimmt float, weil das der native Datentyp der Maschine für reelle Zahlen ist, was ja richtig sein muss..
Bei dir bestell' ich nix.
-
@SeppJ sagte in Wertebereich//Datentyp:
Auftraggeber spezifiziert: Rechnung muss exakt sein auf drei dezimale Stellen. Tyrdal nimmt float, weil das der native Datentyp der Maschine für reelle Zahlen ist, was ja richtig sein muss..
Software läuft halt nur auf Power10 mit FPU-Support für Decimal Floats. Den musste halt mitbestellen, wenn du so technisch anspruchsvolle Anforderungen hast
-
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
Versteh ich nicht. Ich entwickle meine Software immer auf und für Hardware
️ Aber nimm von mir aus unint32_t und Konsorten.Auftraggeber spezifiziert: Software muss ganzzahlige Werte bis 9999999999999 unterstützen. Tyrdal nimmt int, weil das der native Datentyp der Maschine für Ganzzahlen ist, was ja richtig sein muss.
Auftraggeber spezifiziert: Rechnung muss exakt sein auf drei dezimale Stellen. Tyrdal nimmt float, weil das der native Datentyp der Maschine für reelle Zahlen ist, was ja richtig sein muss..
Bei dir bestell' ich nix.
Wo kamen denn derartige Forderungen im Original Post vor? Ich habe meine Rahmenbedingungen vorgegeben, weil keine da waren. Und damit gehts.
-
@Tyrdal sagte in Wertebereich//Datentyp:
Wo kamen denn derartige Forderungen im Original Post vor? Ich habe meine Rahmenbedingungen vorgegeben, weil keine da waren. Und damit gehts.
Ja, eben. Du hast dir selbst irgendetwas ausgedacht, das gar nicht in der Anforderung steht. Schlimmer noch: Es passt nicht einmal zur Anforderung, denn wie hier im Thread groß diskutiert, sind keiner der Werte 7.12, 100.121, und 0.145612141 überhaupt in einem Binärsystem darstellbar.
@Finnegan sagte in Wertebereich//Datentyp:
@SeppJ sagte in Wertebereich//Datentyp:
Auftraggeber spezifiziert: Rechnung muss exakt sein auf drei dezimale Stellen. Tyrdal nimmt float, weil das der native Datentyp der Maschine für reelle Zahlen ist, was ja richtig sein muss..
Software läuft halt nur auf Power10 mit FPU-Support für Decimal Floats. Den musste halt mitbestellen, wenn du so technisch anspruchsvolle Anforderungen hast
Oder halt einen komplexen Datentypen nutzen, der den Anforderungen nachkommt. Ist ja nicht so, dass ein Rechnen mit solchen Zahlen auf x86 unmöglich wäre, es wäre nur etwas langsamer als mit den nativen Typen. Wenn's dem Auftraggeber zu langsam ist, dann muss er halt eine optimierte Hardware/Softwarekombination bestellen und der Erfüller kann dann Power10 liefern.
Aber allgemein ist logisch korrekte Erfüllung der Anforderungen doch offensichtlich immer das oberste Ziel. Es interessiert niemanden, wie schnell du ein falsches Ergebnis berechnen kannst. Oft ist die logische Anforderung auch, dass eine Rechnung in bestimmter Zeit fertig wird (z.B. Framerate bei Spielen) oder wenigstens so schnell wie möglich im Rahmen einer gewissen Genauigkeit (wissenschaftliches Rechnen). Da ist die erste Anlaufstelle natürlich die Fähigkeiten der Hardware auszureizen. Aber halt nur, wenn die Genauigkeit dabei im durch die Anforderung definierten Rahmen bleibt, sonst ist das auch nutzlos.
In den allermeisten Fällen sind die Maschinentypen ja auch weit überdimensioniert für die notwendigen Genauigkeiten, aber hier ist halt die Aufgabe scheiße gestellt, weil alle drei gezeigten rationalen Zahlen eben zu keinem üblichen Maschinentypen passen (obwohl der dumme Lehrer offensichtlich float und double als Antwort sucht). Wenn da in der Aufgabe sonst nichts steht, ist die halt inkompetent gestellt, und somit eine Einladung, unseren Spaß mit einer kleinkarierten Antwort zu haben.
-
Sehe ich auch so, war auch als Scherz gemeint mit der CPU. Obwohl ich durchaus auch schon einige Fälle gesehen habe, in denen man dem Kunden auch noch eine Hardware mitverkauft hat, die eigentlich bei besserer Softwarequalität unnötig gewesen wäre - da reibt man sich doch die Hände
... die Gematik scheint mir so ein Laden zu sein, z.B. wegen der Sache mit dem Konnektorentausch vor einiger Zeit (wenn auch nicht direkt ein Softwareproblem).@SeppJ sagte in Wertebereich//Datentyp:
Wenn da in der Aufgabe sonst nichts steht, ist die halt inkompetent gestellt, und somit eine Einladung, unseren Spaß mit einer kleinkarierten Antwort zu haben.
Ja, das kann ich verstehen. Interessante Fragen zerpflücke ich auch gerne genüsslich. Selbst wenn es nur von nem Troll kommt oder ein "Mach meine Hausaufgaben"-Thread ist. Hauptsache man hat seinen Spass und macht sich selbst auch nochmal Gedanken zu dem Thema. Dabei lernt man meist selbst auch noch eine Menge (oder frischt das Wissen nochmal auf)
-
Nachdem ich mich nunmehr einige Stunden mit dem Thema beschäftigt habe, zurück in verlorenes Wissen aus dem Studium abtauchte, erfuhr, dass unterschiedliche Zahlensysteme und Primfaktoren etwas miteinander zu tun haben, und vieles mehr, komme ich nun mit meiner eigenen Klugscheißer-Antwort hervor (ungeachtet der Auflösung d. Wertebereichs).
0,145612141 bis 1
"Ich möchte bitte
unsigned char[3]einlocken"
"Sind Sie sicher?"
"Ja."Falls wir in den Spielregeln auch nicht-konventionelle Hardware erlauben, dann wäre meine Antwort in dem Fall lieberuint19_t.
Upps, Denkfehler, wenn schonuint21_tEdit: Ach, mist, schon wieder viel zu kompliziert gedacht. Es ging ja quasi nur drum, ob
shortoderfloat, usw.
Insbesondere dachte ich bei "X und Z", man solle eine generische Formel für fixed point aufstellen
-
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
Wo kamen denn derartige Forderungen im Original Post vor? Ich habe meine Rahmenbedingungen vorgegeben, weil keine da waren. Und damit gehts.
Ja, eben. Du hast dir selbst irgendetwas ausgedacht, das gar nicht in der Anforderung steht. Schlimmer noch: Es passt nicht einmal zur Anforderung, denn wie hier im Thread groß diskutiert, sind keiner der Werte 7.12, 100.121, und 0.145612141 überhaupt in einem Binärsystem darstellbar.
Wieso sollten 712, 100121, und 145612141 nicht binär darstellbar sein?
-
@Tyrdal sagte in Wertebereich//Datentyp:
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
Wo kamen denn derartige Forderungen im Original Post vor? Ich habe meine Rahmenbedingungen vorgegeben, weil keine da waren. Und damit gehts.
Ja, eben. Du hast dir selbst irgendetwas ausgedacht, das gar nicht in der Anforderung steht. Schlimmer noch: Es passt nicht einmal zur Anforderung, denn wie hier im Thread groß diskutiert, sind keiner der Werte 7.12, 100.121, und 0.145612141 überhaupt in einem Binärsystem darstellbar.
Wieso sollten 712, 100121, und 145612141 nicht binär darstellbar sein?
Weil 712 nicht 7.12 ist. 712 * 10^-2 ist 7.12. Aber fällt dir was auf? Da ist eine 10 in der Rechnung. Nenn mir ganzzahlige X und Y, so dass X * 2^Y = 7.12, und du hättest Recht! Denn irgendwo muss ja festgehalten werden (egal ob statisch oder dynamisch), dass die 712 (oder das X ) noch mit irgendetwas multipliziert werden soll, um auf den gewünschten Wert zu kommen. Wenn du es mit einer Zehnerpotenz multiplizierst, ist das kein Wert im Binärsystem mehr, und somit wären double und float raus, denn die können nur Zweierpotenzen.
Du hast natürlich insofern recht, als das ein Fixed Point Decimal (oder auch ein Floating Point Decimal) eine mögliche (und gut passende!) Antwort auf die Aufgabenstellung ist. Aber Decimals sind halt keine Zahlen im Binärsystem. Es gibt auch keine üblichen Maschinendatentypen dafür, sondern es sind auf den meisten Maschinen komplexe Datentypen, die das Verhalten in der Software nachbilden.
-
@SeppJ sagte in Wertebereich//Datentyp:
Es gibt auch keine üblichen Maschinendatentypen dafür, sondern es sind auf den meisten Maschinen komplexe Datentypen, die das Verhalten in der Software nachbilden.
Das stimmt so nicht. Es gibt diese Datentypen nur auf bestimmte CPU Architekturen (IBMs Power und die z Series sowie Fujitsu SPARC CPUs können Dezimalgleitkomma in Hardware), und früher war BCD eigentlich auf jeder Plattform vorhanden. Bei x86 gibt es noch immer in der x87 FPU BCD Formate. Allerdings sollte man die x87 Instruktionen nicht mehr nutzen, weil Intel plant x87 in absehbarer Zukunft los zu werden.
-
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
Wo kamen denn derartige Forderungen im Original Post vor? Ich habe meine Rahmenbedingungen vorgegeben, weil keine da waren. Und damit gehts.
Ja, eben. Du hast dir selbst irgendetwas ausgedacht, das gar nicht in der Anforderung steht. Schlimmer noch: Es passt nicht einmal zur Anforderung, denn wie hier im Thread groß diskutiert, sind keiner der Werte 7.12, 100.121, und 0.145612141 überhaupt in einem Binärsystem darstellbar.
Wieso sollten 712, 100121, und 145612141 nicht binär darstellbar sein?
Weil 712 nicht 7.12 ist.
Doch, weil ich festgelegt habe, daß ich den Punkt ignoriere da nicht eindeutig.
-
@Tyrdal sagte in Wertebereich//Datentyp:
Doch, weil ich festgelegt habe, daß ich den Punkt ignoriere da nicht eindeutig.
Du hast aber ignoriert, dass die Bedeutung des Punktes aus dem Dezimalsystem kommt.
-
@Tyrdal sagte in Wertebereich//Datentyp:
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
Wo kamen denn derartige Forderungen im Original Post vor? Ich habe meine Rahmenbedingungen vorgegeben, weil keine da waren. Und damit gehts.
Ja, eben. Du hast dir selbst irgendetwas ausgedacht, das gar nicht in der Anforderung steht. Schlimmer noch: Es passt nicht einmal zur Anforderung, denn wie hier im Thread groß diskutiert, sind keiner der Werte 7.12, 100.121, und 0.145612141 überhaupt in einem Binärsystem darstellbar.
Wieso sollten 712, 100121, und 145612141 nicht binär darstellbar sein?
Weil 712 nicht 7.12 ist.
Doch, weil ich festgelegt habe, daß ich den Punkt ignoriere da nicht eindeutig.
-
@SeppJ sagte in Wertebereich//Datentyp:
@Tyrdal sagte in Wertebereich//Datentyp:
Doch, weil ich festgelegt habe, daß ich den Punkt ignoriere da nicht eindeutig.
Du hast aber ignoriert, dass die Bedeutung des Punktes aus dem Dezimalsystem kommt.
Tut sie das im Deutschen? Und was ist dann das Komma bei der anderen Zahl? Was ist das dann?
-
Da kann ich mich nur hustbaer anschließen. Die Aufgabe mag zwar dumm gestellt sein, aber sich dann noch dümmer zu stellen ist nicht gerade mein Stil. Zumal du ja meiner Erklärung, dass 7.12 nicht binär darstellbar wäre, geantwortet hast, nicht der Aufgabe, und daher weißt, was ich mit 7.12 meine und das von mir gemeinte 7.12 ist eben nicht in einem Binärsystem darstellbar.
-
Ich finde die Aufgabe nichtmal so blöd formuliert.
Also ja, man kann da viel dran kritisieren. Und ja, es wäre schön wenn man von Unterrichtenden erwarten könnte dass sie das besser hinbekommen. Aber eigentlich gibt es für mich nur eine Sache die wirklich nicht klar ist. Und das ist die Frage ob die[u]int_leastN_tTypedefs gesucht sind oder direktchar& Co.Wenn man "Datentyp" so interpretiert dass auch Typedef-Namen/Type-Aliase erlaubt sind, dann müsste man wohl mit
[u]int_leastN_tantworten. Wenn man "Datentyp" so auslegt dass nur die eingebauten Datentypen erlaubt sind, dann halt mitchar& Co. Wobei es dann natürlich strenggenommen auf die Plattform ankommt. Was aber auch mehr akademisch ist. Wenn nix spezielles dabei steht, ist es denke ich nicht ganz verkehrt wenn man davon ausgeht dassintmehr als 16 Bit hat - auch wenn der Standard das nicht verlangt.Und dieser Punkt ist auch nur dann ein Problem, wenn der Vortragende ein Arsch ist und/oder der Modus zur Abgabe es nicht erlaubt 1-2 Sätze als Erklärung wo dazuzuschreiben. Weil ansonsten kann man ja einfach beide Varianten mit einer Erklärung hinschreiben.
-
@SeppJ sagte in Wertebereich//Datentyp:
Zumal du ja meiner Erklärung, dass 7.12 nicht binär darstellbar wäre [...]
Nicht als Binärbruch darstellbar, wäre glaub ich etwas genauer, oder? (Nennt man das so? Impliziert jedenfalls, dass es nicht mit endlich vielen binären Nachkommastellen darstellbar ist). Ich erwähne das nur, weil meines Wissens bei Decimal Floats die Komponenten wie Mantisse und Exponent eben auch binär gespeichert werden, nur eben die Algorithmen andere sind, mit denen diese Zahlen miteinander verrechnet werden. Das könnte man durchaus eine "binäre Darstellung" nennen, aber ich verstehe schon, dass das nicht das ist, worauf die hinaus wolltest
-
@hustbaer sagte in Wertebereich//Datentyp:
Und dieser Punkt ist auch nur dann ein Problem, wenn der Vortragende ein Arsch ist und/oder der Modus zur Abgabe es nicht erlaubt 1-2 Sätze als Erklärung wo dazuzuschreiben. Weil ansonsten kann man ja einfach beide Varianten mit einer Erklärung hinschreiben.
Oder es ist einfach nur Bequemlichkeit und es wird bei der Korrektur lediglich ein stupides "Pattern Matching" gemacht. Sowas konnte ich selbst aber immer in einem nachträglichen Gespräch klären. Es gibt ja durchaus mal mehrere Lösungen, die äquivalent zur geforderten Lösung sind. Oft sogar unendlich viele
-
@Finnegan sagte in Wertebereich//Datentyp:
@SeppJ sagte in Wertebereich//Datentyp:
Zumal du ja meiner Erklärung, dass 7.12 nicht binär darstellbar wäre [...]
Nicht als Binärbruch darstellbar, wäre glaub ich etwas genauer, oder? (Nennt man das so? Impliziert jedenfalls, dass es nicht mit endlich vielen binären Nachkommastellen darstellbar ist).
Korrekt, man könnte es mit einer periodischen Bruchentwicklung darstellen.
(Eigentlich war mir die Wortwahl egal, aber jetzt habe ich es doch nachgeguckt und möchte es auch weitergeben. Im Deutschen würde man sagen: Jede rationale Zahl ist als Bruch darstellbar, und dieser Bruch ist (in egal welchem Zahlensystem) immer entwickelbar. In manchen Zahlensystemen bricht diese Entwicklung nach endlich vielen Stellen ab (hier z.B. 7.12 im Zehnersystem), ansonsten ist die Bruchentwicklung immer periodisch (z.B. 7.12 im Binärsystem, schreibe ich jetzt aber nicht aus, da selbst die Darstellung mit Periode zu lang ist))
