[Netzwelt] Gangnam Style führt zu Problemen bei YouTube

Jump to last post
Zu den etwas lustigeren Fehler 2014 gehört wahrscheinlich dieser hier: Der berühmte Clip "Gangnam Style" von Psy war 2012 ein großer Erfolg, nicht nur auf YouTube. Nach wie vor lässt sich das Video anklicken und führte heute zu einem interessanten Bild.

Jedes YouTube Video hat einen Zugriffzähler. Während Ende 2012 schon die Marke "Eine Milliarde" geknackt wurde, erreichte im Mai 2014 das Video über Zwei Milliarden Klicks. Nach dieser Marke hing bereits der Zugriffszähler, fand aber keine große Beachtung. Doch vor kurzen erschien auf dem YouTube Zähler dieses Clips eine andere Zahl: "-2.147.483.648" und sorgte so bestimmt bei vielen Leuten für ein leichtes Grinsen. Google hat darauf bereits reagiert, behoben den Fehler und erklärte: "Wir haben niemals daran gedacht, dass die Klicks für ein Video zu einer größeren Zahl als einem 32-Bit-Integer werden könnte".

Quelle:
You do not have permission to view link please Anmelden or Registrieren
 
Zuletzt bearbeitet:
Zum Vergrößern anklicken....
Das eigentlich bekloppte ist allerdings, das die nen signed integer für nen Zählern verwenden …
 
hrhr....geil.

Genauso wie damals, als ein Spieler in WoW auch beinahe einen Überlauf erzeugt hatte, weil er mehr Gold gehortet hat, als die Entwickler es je vorhergesehen haben :D
 
Signed ist doof weil auch negative Werte möglich sind?
Wenn ich das richtig verstehe wäre mit einem unsigned integer die Grenze erst bei 2^32 während die Grenze bei einem signed integer bei 2^31 wäre.

Ist eine Verständnis Frage :)

Lg
 
You do not have permission to view link please Anmelden or Registrieren

genau, bei einem counter dieser art gibt es keinen möglichen Fall in dem ein negativer Wert korrekt wäre, somit macht es überhaupt keinen Sinn dafür einen signed integer zu benutzen und wie du bereits richtig erkannt hast ist der Wertebereich bei einem unsigned integer sogar größer, somit wäre das Problem erst deutlich später aufgetreten.
 
Und weil das eine zusätzliche bit bei einem signed integer bedeutet das die Zahl negativ ist kommt es zu dieser negativen Anzeige und irgendwann zu einem overflow. Ich verstehe. Danke!
 
War das schön als man Anfang der 90er noch Cheaten konnte indem man Schulden machte bis es zum Overflow kam und man dann unglaublich viel Geld hatte^^ (damals waren das noch signed integer mit nur 16 bit)
 
Asseon schrieb:
Das eigentlich bekloppte ist allerdings, das die nen signed integer für nen Zählern verwenden …
Zum Vergrößern anklicken....

welche Programmiersprache verwenden die?

Wenn es C ist .. dann sicher unsigned int

You do not have permission to view link please Anmelden or Registrieren


auf der Webseite ist die Rede von einem Wechsel . Also 32 bit auf 64 bit . In C würde man dann auf double wechseln. Die Werte können also wieder negativ sein.

wenn es Python ist muss man wohl ein L an den Wert schreiben, damit erkannt wird, dass es sich um einen 64bit Wert (Datentyp long) handelt und nicht um 32 Bit (Integer)

in Java müsste man long statt int nehmen. Aber mit unsigned hat es auch nichts zu tun.

Wie kommt ihr dann auf die Idee mit dem unsigned?
 
Sp1xx schrieb:
Signed ist doof weil auch negative Werte möglich sind?
Wenn ich das richtig verstehe wäre mit einem unsigned integer die Grenze erst bei 2^32 während die Grenze bei einem signed integer bei 2^31 wäre.

Ist eine Verständnis Frage :)

Lg
Zum Vergrößern anklicken....

Signed und unsigned 32bit-Integer:

Signed Integer:
00000000000000000000000000000000[SUB]bin[/SUB] = 0[SUB]dec[/SUB]
00000000000000000000000000000001[SUB]bin[/SUB] = 1[SUB]dec[/SUB]
00000000000000000000000000000010[SUB]bin[/SUB] = 2[SUB]dec[/SUB]
00000000000000000000000000000011[SUB]bin[/SUB] = 2[SUB]dec[/SUB]
....
01111111111111111111111111111111[SUB]bin[/SUB] = 2[SUP]31[/SUP]-1[SUB]dec[/SUB]
1000000000000000000000000000000[SUB]bin[/SUB] = -1[SUB]dec[/SUB]
1000000000000000000000000000001[SUB]bin[/SUB] = -2[SUB]dec[/SUB]
1000000000000000000000000000010[SUB]bin[/SUB] = -3[SUB]dec[/SUB]
1000000000000000000000000000011[SUB]bin[/SUB] = -4[SUB]dec[/SUB]
....
11111111111111111111111111111111[SUB]bin[/SUB] = -2[SUP]31[/SUP][SUB]dec[/SUB]

Das most significant bit (x0000000000000000000000000000000), ich habe es mit x markiert, gibt das Vorzeichen an.
Die übrigen bits stehen für die Zahlen.

Unsigned Integer:
00000000000000000000000000000000[SUB]bin[/SUB] = 0[SUB]dec[/SUB]
00000000000000000000000000000001[SUB]bin[/SUB] = 1[SUB]dec[/SUB]
00000000000000000000000000000010[SUB]bin[/SUB] = 2[SUB]dec[/SUB]
00000000000000000000000000000011[SUB]bin[/SUB] = 2[SUB]dec[/SUB]
....
01111111111111111111111111111111[SUB]bin[/SUB] = 2[SUP]31[/SUP]-1[SUB]dec[/SUB]
1000000000000000000000000000000[SUB]bin[/SUB] = 2[SUP]31[/SUP][SUB]dec[/SUB]
....
11111111111111111111111111111111[SUB]bin[/SUB] = 2[SUP]32[/SUP]-1[SUB]dec[/SUB]


Wieso die Klick-/Viewzahlen signed sind, ist für mich auch rätselhaft. Solange die Standardzahlentypen ausreichen und keine speziellen Cryptotypen genutzt werden müssen, sehe ich da noch keinen Grund zum Verzweifeln.


Datentypen, Bitlängen, Wertebereich (signed, unsigned)
[src=text]Bezeichnung | #bits | signed | unsigned |
| | min | max | min | max |
byte | 8bit | -128 | 127 | | |
short | 16bit | -32,768 | 32,767 | | |
int | 32bit | -2^31 | (2^31)-1 | 0 | (2^31)-1 |
long | 64bit | -2^63 | (2^63)-1 | 0 | (2^64)-1 |
float | 32bit | | | | |
double | 64bit | | | | | ungenau[/src]

Außerdem gibt es noch: (java.math.*)
BigDecimal
BigInteger
 
Zuletzt bearbeitet:
You do not have permission to view link please Anmelden or Registrieren

Bei der "UNIX-Time" macht das aber durchaus sinn, denn auch wenn Zeit nur vorwärts "läuft" ist unter Umständen durchaus nicht unwichtig auch vergangene Daten darstellen zu können, und man hat Anfang der Siebziger einfach noch nicht für 70 Jahre im voraus gedacht.

You do not have permission to view link please Anmelden or Registrieren

Wäre es ein "unsigned int" int wäre der Überlauf erst bei "4294967295" aufgetreten und der Wert wäre auf 0 und nicht auf -2147483648 gesprungen. Wie Pleitegeier bereits sagte double ist eine Gleitkommazahl und für einen Counter so oder so nicht geeignet.

In Python2 ist der Übergang von int zu long transparent selbst wenn du explizit ein int anforderst, ist die Zahl zu groß bekommst ein long, in python3 gibt es die Unterscheidung aus sicht des Programmierers gar nicht mehr.

Es ist btw viel wahrscheinlicher, dass der Überlauf in der Datenbank aufgetreten ist und nicht im YT code selber.
 
  • Thread Starter Thread Starter
  • #13
Asseon schrieb:
Es ist btw viel wahrscheinlicher, dass der Überlauf in der Datenbank aufgetreten ist und nicht im YT code selber.
Zum Vergrößern anklicken....

Das denke ich mir auch. Ich finde es nur interessant, wie der Code reagiert hat, als er +1 erhöht hat. Wieso ging er in den den Negativ Bereich?
 
Das erklärt dieses gif zum "Jahr-2038-Problem" sehr gut
Year_2038_problem.gif
 
  • Thread Starter Thread Starter
  • #15
You do not have permission to view link please Anmelden or Registrieren
Verdammt, daran habe ich gar nicht gedacht!

Logisch, alles ist Binär, und da das erste Bit über - oder + entscheidet. Danke dir :)
 
Das erinnert mich an die Windows-Shell cmd aka DOS-Fenster. Die rechnet auch mit dem vorzeichenbehafteten 32bit Integer, positiv bis
2[sup]31[/sup]-1​
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben