{"id":88581,"date":"2020-07-15T01:42:09","date_gmt":"2020-07-14T23:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/unreal-features-of-real-types-ili-budte-ostorozhny-s-real"},"modified":"2020-07-15T01:42:09","modified_gmt":"2020-07-14T23:42:09","slug":"unreal-features-of-real-types-ili-budte-ostorozhny-s-real","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/unreal-features-of-real-types-ili-budte-ostorozhny-s-real","title":{"rendered":"Unreal Features of Real Types, oder Seien Sie vorsichtig mit REAL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nach der Ver\u00f6ffentlichung des Artikels<\/a><\/noindex> \u00dcber die Besonderheiten der Typisierung in PostgreSQL war der erste Kommentar \u00fcber die Schwierigkeiten im Umgang mit Flie\u00dfkommazahlen. Ich habe beschlossen, schnell durch den Code der mir verf\u00fcgbaren SQL-Abfragen zu schauen, um zu sehen, wie oft der Typ REAL darin verwendet wird. Es wird, wie sich herausstellt, ziemlich h\u00e4ufig verwendet, und nicht immer verstehen die Entwickler die damit verbundenen Gefahren. Und das trotz der Tatsache, dass im Internet und auf Habr viele gute Artikel \u00fcber die Besonderheiten der Speicherung von Flie\u00dfkommazahlen im Arbeitsspeicher und den Umgang mit ihnen zu finden sind. Daher werde ich in diesem Artikel versuchen, diese Besonderheiten auf PostgreSQL anzuwenden und die damit verbundenen Probleme \u201eanhand von Beispielen\u201c zu er\u00f6rtern, damit es den Entwicklern von SQL-Abfragen leichter f\u00e4llt, sie zu vermeiden.<\/p>\n

<\/p>\n

Die Dokumentation von PostgreSQL enth\u00e4lt den pr\u00e4gnanten Satz: \u201eDas Management solcher Fehler und deren Verbreitung im Berechnungsprozess ist Gegenstand eines gesamten Bereichs der Mathematik und Informatik und wird hier nicht behandelt\u201c (und verweist dabei weise den Leser auf den Standard IEEE 754). Welche Fehler sind hier gemeint? Lassen Sie uns diese nacheinander diskutieren, und bald wird klar, warum ich wieder zur Feder gegriffen habe.<\/p>\n

<\/a><\/noindex><\/p>\n

Nehmen wir zum Beispiel eine einfache Abfrage:<\/p>\n

<\/p>\n

********* ABFRAGE *********\nSELECT 0.1::REAL;\n**************************\nfloat4\n--------\n    0.1\n(1 Zeile)\n<\/code><\/pre>\n
<\/p>\n
Als Ergebnis werden wir nichts Besonderes sehen \u2013 wir erhalten das erwartete 0.1. Aber jetzt vergleichen wir es mit 0.1:<\/p>\n
<\/p>\n
********* ABFRAGE *********\nSELECT 0.1::REAL = 0.1;\n**************************\n?column?\n----------\nf\n(1 Zeile)\n<\/code><\/pre>\n
<\/p>\n
Sie sind ungleich! Was f\u00fcr ein Wunder! Aber es kommt noch mehr. Jemand wird sagen, ich wei\u00df, dass REAL sich schlecht mit Bruchzahlen verh\u00e4lt, also werde ich dort ganze Zahlen eingeben, mit denen wird es ganz sicher gut gehen. Okay, lassen Sie uns die Zahl 123 456 789 in den Typ REAL umwandeln:<\/p>\n
<\/p>\n
********* ABFRAGE *********\nSELECT 123456789::REAL::INT;\n**************************\n   int4   \n-----------\n123456792\n(1 Zeile)\n<\/code><\/pre>\n
<\/p>\n
Und sie ist 3 gr\u00f6\u00dfer geworden! Die Datenbank hat endg\u00fcltig das Rechnen verlernt! Oder missverstehen wir etwas? Lassen Sie uns das kl\u00e4ren.<\/p>\n
<\/p>\n
Um anzufangen, lassen Sie uns die Grundkenntnisse auffrischen. Wie bekannt ist, kann jede Dezimalzahl in Potenzen von zehn zerlegt werden. So wird die Zahl 123.456 gleich 1*10\u00b2 + 2*10\u00b9 + 3*10\u2070 + 4*10\u207b\u00b9 + 5*10\u207b\u00b2 + 6*10\u207b\u00b3. Aber der Computer arbeitet mit Zahlen in bin\u00e4rer Form, daher m\u00fcssen sie in Form von Potenzen von zwei dargestellt werden. Deshalb wird die Zahl 5.625 in bin\u00e4rer Form als 101.101 dargestellt und entspricht 1*2\u00b2 + 0*2\u00b9 + 1*2\u2070 + 1*2\u207b\u00b9 + 0*2\u207b\u00b2 + 1*2\u207b\u00b3. W\u00e4hrend positive Potenzen von zwei immer ganze Dezimalzahlen (1, 2, 4, 8, 16 usw.) ergeben, ist es bei negativen komplizierter (0,5, 0,25, 0,125, 0,0625 usw.). Das Problem ist, dass nicht jede dezimale Bruchzahl als endlicher bin\u00e4rer Bruch dargestellt werden kann<\/b>. So pr\u00e4sentiert sich unser ber\u00fcchtigtes 0,1 in Form eines bin\u00e4ren Bruchs als periodischer Wert 0,0(0011). Folglich wird der Endwert dieser Zahl im maschinellen Speicher je nach Genauigkeit variieren.<\/p>\n
<\/p>\n
Jetzt ist der richtige Zeitpunkt, um sich daran zu erinnern, wie Gleitkommazahlen im Computer gespeichert werden. Grob gesagt besteht eine Gleitkommazahl aus drei Hauptteilen \u2013 Vorzeichen, Mantisse und Exponent. Das Vorzeichen kann entweder plus oder minus sein, daher wird daf\u00fcr ein Bit reserviert. Die Anzahl der Bits f\u00fcr Mantisse und Exponent wird jedoch durch den Gleitkommatyp bestimmt. So betr\u00e4gt bei dem Typ REAL die L\u00e4nge der Mantisse 23 Bits (ein Bit, das gleich 1 ist, wird implizit am Anfang der Mantisse hinzugef\u00fcgt, sodass es insgesamt 24 wird), und der Exponent hat 8 Bits. Zusammen ergibt das 32 Bits oder 4 Byte. Bei dem Typ DOUBLE PRECISION betr\u00e4gt die L\u00e4nge der Mantisse bereits 52 Bits, und der Exponent hat 11 Bits, insgesamt also 64 Bits oder 8 Byte. PostgreSQL unterst\u00fctzt keine h\u00f6here Genauigkeit f\u00fcr Flie\u00dfkommazahlen.<\/p>\n
<\/p>\n
Lassen Sie uns unsere Zahl 0.1 in dezimaler Form in beiden Typen \u2013 REAL und DOUBLE PRECISION \u2013 verpacken. Da Vorzeichen und Wert des Exponenten \u00fcbereinstimmen, konzentrieren wir uns auf die Mantisse (ich lasse bewusst die nicht offensichtlichen Besonderheiten der Speicherung von Exponentenwerten und null Gleitkommazahlen weg, da sie das Verst\u00e4ndnis erschweren und vom Kern des Problems ablenken; bei Interesse \u2013 siehe Standard IEEE 754). Was erhalten wir? In der oberen Zeile gebe ich die \u201eMantisse\u201c f\u00fcr den Typ REAL an (unter Ber\u00fccksichtigung der Rundung des letzten Bits auf 1 auf die n\u00e4chstgelegene darstellbare Zahl; andernfalls ergibt sich 0,099999 \u2026), und in der unteren Zeile die f\u00fcr den Typ DOUBLE PRECISION:<\/p>\n
<\/p>\n
0.0001<\/b>10011001100110011001101<\/b>
\n0.0001<\/b>1001100110011001100110011001100110011001100110011001\n<\/p><\/blockquote>\n
<\/p>\n
Offensichtlich sind das zwei v\u00f6llig unterschiedliche Zahlen! Daher wird beim Vergleich die erste Zahl mit Nullen erg\u00e4nzt und ist somit gr\u00f6\u00dfer als die zweite (unter Ber\u00fccksichtigung der gerundeten \u2013 fett markierten Eins). Dies erkl\u00e4rt die Mehrdeutigkeit in unseren Beispielen. Im zweiten Beispiel wird die ausdr\u00fccklich angegebene Zahl 0.1 in den Typ DOUBLE PRECISION umgewandelt, bevor sie mit einer Zahl vom Typ REAL verglichen wird. Beide werden in denselben Typ konvertiert, und wir haben genau das, was oben zu sehen ist. Lassen Sie uns die Abfrage so \u00e4ndern, dass alles an seinen Platz r\u00fcckt:<\/p>\n
<\/p>\n
********* ABFRAGE *********\nSELECT 0.1::REAL > 0.1::DOUBLE PRECISION;\n**************************\n?column?\n----------\nt\n(1 Zeile)\n<\/code><\/pre>\n
<\/p>\n
Und tats\u00e4chlich, nachdem wir die Zahl 0.1 zweimal in REAL und DOUBLE PRECISION umgewandelt haben, erhalten wir die Antwort auf das R\u00e4tsel:<\/p>\n
<\/p>\n
********* ABFRAGE *********\nSELECT 0.1::REAL::DOUBLE PRECISION;\n**************************\n\n      float8       \n-------------------\n0.100000001490116\n(1 Zeile)\n<\/code><\/pre>\n
<\/p>\n
Dies erkl\u00e4rt auch das dritte Beispiel aus den oben genannten. Die Zahl 123 456 789 einfach nicht in 24 Bit Mantisse unterzubringen<\/b> (23 explizite + 1 implizierte). Die maximale ganze Zahl, die in 24 Bit gespeichert werden kann, betr\u00e4gt 224<\/sup>-1 = 16 777 215. Daher wird unsere Zahl 123 456 789 auf die n\u00e4chstgelegene darstellbare 123 456 792 gerundet. Wenn wir den Typ auf DOUBLE PRECISION \u00e4ndern, sehen wir dieses Szenario nicht mehr:<\/p>\n
<\/p>\n
********* ABFRAGE *********\nSELECT 123456789::DOUBLE PRECISION::INT;\n**************************\n   int4   \n-----------\n123456789\n(1 Zeile)\n<\/code><\/pre>\n
<\/p>\n
Das ist alles. Es stellt sich heraus, dass es keine Wunder gibt. Aber all dies ist ein guter Anlass, dar\u00fcber nachzudenken, wie notwendig Ihnen der Typ REAL wirklich ist. Vielleicht ist der gr\u00f6\u00dfte Vorteil seiner Verwendung die Schnelligkeit der Berechnungen mit einer unvermeidlichen Verlust an Genauigkeit. Aber wird dies ein universelles Szenario sein, das die h\u00e4ufige Verwendung dieses Typs rechtfertigt? Ich denke nicht.<\/p>\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u043e\u0441\u043b\u0435 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043e\u0431 \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u0442\u0438\u043f\u0438\u0437\u0430\u0446\u0438\u0438 \u0432 PostgreSQL, \u043f\u0435\u0440\u0432\u044b\u0439 \u0436\u0435 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u0439 \u0431\u044b\u043b \u043f\u0440\u043e \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441 \u0432\u0435\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u043c\u0438 \u0447\u0438\u0441\u043b\u0430\u043c\u0438. \u042f \u0440\u0435\u0448\u0438\u043b \u0431\u0435\u0433\u043b\u043e \u043f\u0440\u043e\u0431\u0435\u0436\u0430\u0442\u044c\u0441\u044f \u043f\u043e \u043a\u043e\u0434\u0443 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u043c\u043d\u0435 SQL-\u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u0442\u043e \u0432 \u043d\u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0442\u0438\u043f REAL. \u0414\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0447\u0430\u0441\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f, \u043a\u0430\u043a \u043e\u043a\u0430\u0437\u0430\u043b\u043e\u0441\u044c, \u0438 \u043d\u0435 \u0432\u0441\u0435\u0433\u0434\u0430 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438 \u043f\u043e\u043d\u0438\u043c\u0430\u044e\u0442 \u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438, \u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0437\u0430 \u043d\u0438\u043c. \u0418 \u044d\u0442\u043e \u043d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-88581","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Unreal Features of Real Types, oder Seien Sie vorsichtig mit REAL | ProHoster","description":"Nach der Ver\u00f6ffentlichung des Artikels \u00fcber die Besonderheiten der Typisierung in PostgreSQL war der erste Kommentar \u00fcber die Schwierigkeiten bei der Arbeit mit.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/unreal-features-of-real-types-ili-budte-ostorozhny-s-real","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Unreal Features of Real Types, \u0438\u043b\u0438 \u0411\u0443\u0434\u044c\u0442\u0435 \u043e\u0441\u0442\u043e\u0440\u043e\u0436\u043d\u044b \u0441 REAL | ProHoster","og:description":"\u041f\u043e\u0441\u043b\u0435 \u043f\u0443\u0431\u043b\u0438\u043a\u0430\u0446\u0438\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043e\u0431 \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u0442\u0438\u043f\u0438\u0437\u0430\u0446\u0438\u0438 \u0432 PostgreSQL, \u043f\u0435\u0440\u0432\u044b\u0439 \u0436\u0435 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u0439 \u0431\u044b\u043b \u043f\u0440\u043e \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0440\u0430\u0431\u043e\u0442\u044b \u0441.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/unreal-features-of-real-types-ili-budte-ostorozhny-s-real","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-14T23:42:09+00:00","article:modified_time":"2020-07-14T23:42:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"88581","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:10:53","updated":"2022-10-03 00:47:31","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/88581","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=88581"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/88581\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=88581"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=88581"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=88581"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}