# floating-point Published articles for floating-point. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Subnormal floating-point numbers are expensive... on Intel processors DevFeed: [Subnormal floating-point numbers are expensive... on Intel processors]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-09-15T12:54:32Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [floating-point](), [Benchmark](), [intel](), [C++](), [Cache]() Tags: [benchmark](), [c-plus-plus](), [floating-point](), [intel](), [linux](), [numbers](), [performance](), [processors]() ### AI overview This article benchmarks the performance cost of IEEE subnormal floating-point values across Intel, AMD, Arm, and Apple processors. It reports that Intel multiplications involving subnormals can be about 45 to 50 times slower than normal multiplications, while additions and subtractions remain at full speed. AMD Zen 5 performs much better in the tested workloads. ### Source excerpt We represent floating-point numbers using the IEEE standard. For very small numbers, the standard uses special subnormal numbers. Unfortunately, they have a reputation of making operations slow. Thus video game programmers and machine learning specialists sometimes avoid computing with subnormal numbers for performance. How slow are they? Let me measure. I wrote a small C++ ... Continue reading Subnormal floating-point numbers are expensive... on Intel processors ## An Incorrect Temperature Conversion Lookup Table in Home-Automation Code DevFeed: [An Incorrect Temperature Conversion Lookup Table in Home-Automation Code]() Original publisher: [Read original article]() Author: Remy Porter Published: 2026-09-03T06:30:00Z Content type: opinion Language: en Sources: [The Daily WTF]() Topics: [Code](), [floating-point](), [Open Source]() Tags: [code](), [codesod](), [errors](), [floating-point](), [open-source]() ### AI overview The article examines home-automation code that uses a floating-point lookup table to convert Celsius to Fahrenheit. It explains that several mappings are incorrect and that using floating-point values as map keys can also cause lookup failures because of rounding errors. ### Source excerpt A common option for retrofitting heating and cooling into older homes is a mini-split, frequently tied to a heat pump. They're (relatively) cheap to install, energy efficient, and can be added without substantial modifications to the home. They also, annoyingly, are mostly controlled via IR remotes, making them challenging to wire up to home automation or even a household thermostat. People have made solutions, and today's code comes from one of those solutions. Which, I want to stress, this code comes from an open source project for home automation, so it's not the code that's wrong, here. At first I thought it was, and had a moment of, "I'm not going to pick on some hobby project," but then I realised the hobby project points at a deeper issue. // temperature helper these are direct mappings based on the remote float toFahrenheit(float fromCelsius) { // Lookup table for specific mappings const std::map lookupTable = { {16.0, 61}, {16.5, 62}, {17.0, 63}, {17.5, 64}, {18.0, 65}, {18.5, 66}, {19.0, 67}, {20.0, 68}, {21.0, 69}, {21.5, 70}, {22.0, 71}, {22.5, 72}, {23.0, 73}, {23.5, 74}, {24.0, 75}, {24.5, 76}, {25.0, 77}, {25.5, 78}, {26.0, 79}, {26.5, 80}, {27.0, 81}, {27.5, 82}, {28.0, 83}, {28.5, 84}, {29.0, 85}, {29.5, 86}, {30.0, 87}, {30.5, 88} }; // Check if the input is in the lookup table auto it = lookupTable.find(fromCelsius); if (it != lookupTable.end()) { return it->second; } // Default conversion and rounding to nearest integer return roundf(fromCelsius * 1.8 + 32.0); } Okay, I am going to pick on their code a little bit; using float as a key in a map is asking for trouble, because rounding errors are going to surprise you. But honestly, failing to find the key you're looking for is better than the opposite, since that actually does the correct thing. Because if you look carefully at the table, you'll see that it's wrong. 18C, for example, should be 64F. Well, 64.4F, but we're rounding to an integer. The choice here is to roughly map every 0. ## C++29 -- начало. Встреча ISO C++ в Брно DevFeed: [C++29 -- начало. Встреча ISO C++ в Брно]() Original publisher: [Read original article]() Author: antoshkka (Яндекс) Published: 2026-08-17T07:01:31Z Content type: article Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [C++](), [floating-point](), [implementation]() Tags: [c-plus-plus](), [c-plus-plus-29](), [floating-point](), [fmt](), [format](), [implementation](), [iso](), [standard](), [standard-library](), [tagged-pointers](), [thread](), [threads](), [undefined-behavior](), [undefined-behaviour]() ### AI overview A report on the ISO C++ committee meeting in Brno, where work on C++29 began. It describes plans to organize and clarify documented undefined behavior and ill-formed-no-diagnostic-required cases, along with changes involving constexpr floating-point evaluation and other language rules. ### Source excerpt Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Недавно в Брно состоялась встреча международного комитета по стандартизации языка программирования C++, в которой я принимал активное участие. В этот раз началась работа над C++29 и как раз о новинках и хочется рассказать. Читать далее ## Arm's Cortex A55 DevFeed: [Arm's Cortex A55]() Original publisher: [Read original article]() Author: Chester Lam Published: 2026-08-02T22:02:44Z Content type: article Language: en Sources: [Chips and Cheese]() Topics: [Arm](), [Front end](), [Cache](), [Neural Network]() Tags: [arm](), [cache](), [core](), [cortex-a55](), [devices](), [efficiency](), [floating-point](), [frontend](), [linux](), [memory](), [neural](), [performance]() ### AI overview A technical analysis of Arm's Cortex A55 examines its microarchitecture, including its in-order pipelines, frontend, memory subsystem, branch prediction, and implementations in the MediaTek Genio 1200 and other devices. ### Source excerpt Arm's 5-series cores are meant for tasks where performance barely matters, but power and area efficiency are top priorities. ## double, BigDecimal, or Fixed-Point? DevFeed: [double, BigDecimal, or Fixed-Point?]() Original publisher: [Read original article]() Author: Stefano Fago Published: 2026-06-14T00:00:00Z Content type: article Language: en Sources: [Nicolas Fränkel]() Topics: [Java]() Tags: [bigdecimal](), [engineering](), [floating-point](), [java](), [numbers](), [performance](), [pitfalls](), [precision]() ### AI overview A Java-focused article explains how to choose among double, BigDecimal, and fixed-point arithmetic based on required precision, rounding rules, and performance constraints. It covers IEEE 754 binary representation, floating-point equality pitfalls, tolerance-based comparisons, and production concerns such as serialization, testing, and concurrency. ### Source excerpt There is an evergreen debate in the Java world: should you always use BigDecimal for money? The short answer is no. The real answer is: it depends on your computational context: the precision you need, the rounding rules you must follow, and the performance budget you have. The problem is that this conversation is often driven by dogma rather than engineering. ## Building an AI Tennis Coach with MediaPipe and Claude DevFeed: [Building an AI Tennis Coach with MediaPipe and Claude]() Original publisher: [Read original article]() Published: 2026-02-25T00:00:00Z Content type: tutorial Language: en Sources: [Gaurav Sarma's Blog]() Topics: [Streamlit](), [MediaPipe Face Landmarker](), [Claude](), [Artificial Intelligence](), [Code](), [math]() Tags: [ai](), [app](), [building](), [code](), [floating-point](), [laptop](), [math](), [mediapipe](), [pipeline](), [speed]() ### AI overview This tutorial explains how to build a Streamlit AI tennis-coaching app using MediaPipe pose detection and Claude. The pipeline analyzes uploaded tennis video, calculates joint angles and swing timing, overlays a skeleton on the footage, and generates coaching feedback grounded in the computed measurements. ### Source excerpt . [Building an AI Tennis Coach with MediaPipe and Claude](building-an-ai-tennis-coach-mediapipe-claude-cover... ## Comparing Integers and Doubles DevFeed: [Comparing Integers and Doubles]() Original publisher: [Read original article]() Author: Thomas Neumann (noreply@blogger.com) Published: 2025-11-10T16:55:00Z Content type: article Language: en Sources: [Database Architects]() Topics: [floating-point](), [SQL](), [DuckDB](), [sql-server](), [Programming](), [C++]() Tags: [c-plus-plus](), [compiler](), [duckdb](), [floating-point](), [precision](), [sql](), [sql-server](), [testing](), [undefined-behavior]() ### AI overview The article explains how comparing large integers with double-precision values can lose integer precision and produce non-transitive results in SQL systems. It describes how this can cause differences between ordinary comparisons and hash joins, and outlines a conversion-based approach for correct comparisons. ### Source excerpt During automated testing we stumbled upon a problem that boiled down to transitive comparisons: If a=b, and a=c, when we assumed that b=c. Unfortunately that is not always the case, at least not in all systems. Consider the following SQL query: select a=b, a=c, b=c from (values( 1234567890123456789.0::double precision, 1234567890123456788::bigint, 1234567890123456789::bigint)) s(a,b,c) If you execute that in Postgres (or DuckDB, or SQL Server, or ...) the answer is (true, true, false). That is, the comparison is not transitive! Why does that happen? When these systems compare a bigint and a double, they promote the bigint to double and then compare. But a double has only 52 bits of mantissa, which means it will lose precision when promoting large integers to double, producing false positives in the comparison. This behavior is highly undesirable, first because it confuses the optimizer, and second because (at least in our system) joins work very differently: Hash joins promote to the most restrictive type and discard all values that cannot be represented, as they will never produce a join partner for sure. For double/bigint joins that leads to observable differences between joins and plain comparisons, which is very bad. How should we compare correctly? Conceptually the situation is clear, an IEEE 754 floating point with sign s, mantissa m, and exponent e represents the values (-1)^s*m*2^e, we just have to compare the integer with that value. But there is no easy way to do that, if we do a int/double comparison in, e.g., C++, the compiler does the same promotion to double, messing up the comparison. We can get the logic right by doing two conversions: We first convert the int to double and compare that. If the values are not equal, the order is clear and we can use that. Otherwise, we convert the double back to an integer and check if the conversion rounded up or down, and handle the result. Plus some extra checks to avoid undefined behavior (the conversion of intma ## Floating-Point Units on Espressif SoCs: Why (and when) they matter DevFeed: [Floating-Point Units on Espressif SoCs: Why (and when) they matter]() Original publisher: [Read original article]() Author: John Lee Published: 2025-10-13T00:00:00Z Content type: article Language: en Sources: [Blog on Developer Portal]() Topics: [Espressif](), [Hardware](), [cpu](), [ESP32-S3](), [ESP32-C3](), [Benchmark](), [math]() Tags: [benchmark](), [blog](), [esp32](), [esp32-c3](), [esp32-s3](), [espressif](), [floating-point](), [fpu](), [hardware](), [math](), [performance](), [precision](), [processor]() ### AI overview This article explains what floating-point units are, why they matter for calculations involving decimal values and wide dynamic ranges, and how they differ across Espressif SoCs. It states that the ESP32-S3 performs floating-point operations directly in hardware, while the ESP32-C3 executes them in software, and introduces a benchmark-based discussion of performance. ### Source excerpt In this article, you'll learn what an FPU is, why it's useful, which Espressif SoCs feature one, and how it impacts performance through a benchmark. ## mac-volume: A CLI to control device volume DevFeed: [mac-volume: A CLI to control device volume]() Original publisher: [Read original article]() Author: Rob Published: 2025-10-07T10:00:00Z Content type: article Language: en Sources: [Rob Allen]() Topics: [Command-line interface](), [Swift](), [C](), [floating-point](), [function](), [GitHub]() Tags: [audio](), [c](), [cli](), [floating-point](), [github](), [mac](), [swift](), [volume]() ### AI overview The article explains why Mac volume controls can be inconvenient when calls use a separate audio device. It describes a Swift command-line utility called mac-volume that uses Core Audio to control volume by device name, including listing devices and incrementing or decrementing volume, with integration through StreamDeck and Keyboard Maestro. ### Source excerpt I've set my Mac up such that video calls such as Zoom use the microphone and earphones attached to my Behringer UMC204HD, which all other audio plays through the my normal speakers which are the default. One issue I have with this is that it's quite hard to change the volume when a call as the volume buttons on the Mac are connected to the default output. This finally annoyed me enough that I looked... continue reading. ## Code golfing a tiny demo using maths and a pinch of insanity DevFeed: [Code golfing a tiny demo using maths and a pinch of insanity]() Original publisher: [Read original article]() Published: 2025-09-29T13:30:50Z Content type: tutorial Language: en Sources: [The Last Static Blog RSS]() Topics: [glsl](), [Code](), [Canvas](), [coding]() Tags: [3d](), [canvas](), [code](), [coding](), [floating-point](), [fun](), [glsl](), [graphics](), [math](), [prog]() ### AI overview This tutorial explains how a 448-character GLSL fragment shader creates a procedural demo by evaluating mathematical formulas for each pixel. It examines the shader structure, WebGL2 canvas inputs, code-golfing techniques, and a local live-coding workflow. ### Source excerpt A few weeks ago, I made a tiny demo that fits into 448 characters: Red Alp GLSL demo in 448 characters void main(){vec3 c,p,K=vec3(3,1,0);for(float z,i,a,g=1.,t,h,d,w,k=.15;i++<1e2;d=max(max(d-3. ,-d),a=z)*k,w=g-g/exp(h>.001?a++,d/.4:h*3e2),g-=a*=w,c+=a*d*4.5+(d>z?z:h/2e2)*K,a=min(p.y+2. ,1.),c.r+=w*a*a*.1,t+=min(h*.2,k/=.985))for(p=normalize(vec3(P+P-R,R.y))*t,p.xz*=mat2(cos( sin(T*.2)+K.zyxz*11.)),p.z+=T*.3,d=p.y,h=d+.5,a=.01;a<1.;a+=a)p.xz*=mat2(8,6,-6,8)*.1,d+=abs (dot(sin((p/a+T)*.3),p-p+a)),h+=abs(dot(sin(p.xz*.6/a),P-P+a));O=vec4(tanh(c),1);} Note The number of characters was 464 characters at first, but thanks to the community it got reduced further, and the article updated accordingly. There is no texture, no mesh, no 3D helper: it's simply a procedural mathematical formula evaluated at each pixel assigning them a color. Code golfing is about making it as short as possible, and thus is part of the art performance. To put things into perspective, the 853x480 JPEG thumbnail of this article is 167x larger than this code. You can watch a larger version on its main dedicated page, or a portage on Shadertoy (484 chars). If your device is not powerful enough (I'm sorry for the lag on this page) or doesn't support WebGL2, a short preview video can be seen on Mastodon. I'm guessing the wizardry of the code has confused many people so we're going to dive through the making-of together. Overall, this demo is a particularly dense and entangled compilation of different techniques, where each aspect could mandate a dedicated article. For that reason, some parts will prefer to link to external resources when the literacy is verbose on the subject. Warning Some demos in this article will start "decaying" over time due to floating point variables getting too large. Reloading the page should fix that. The base template The code is written in GLSL and is executed for each pixel (technically each fragment) on a simple quad geometry (to be accurate it's even a single big triang ## performance of random floats DevFeed: [performance of random floats]() Original publisher: [Read original article]() Published: 2025-06-08T02:08:35Z Content type: article Language: en Sources: [Tony Finch's blog]() Topics: [floating-point](), [Benchmark](), [Code](), [Arm](), [Compiler]() Tags: [arm](), [benchmark](), [code](), [compiler](), [floating-point](), [performance]() ### AI overview This article benchmarks two methods for converting random integers into floating-point values between 0.0 and 1.0: bit manipulation and shift-convert-multiply. It discusses their generated amd64 and Arm64 code, including notably compact Arm64 translations produced by recent Clang versions, and describes tests on Apple M1 Pro and AMD Ryzen 7950X systems. ### Source excerpt A couple of years ago I wrote about random floating point numbers. In that article I was mainly concerned about how neat the code is, and I didn't pay attention to its performance. Recently, a comment from Oliver Hunt and a blog post from Alisa Sireneva prompted me to wonder if I made an unwarranted assumption. So I wrote a little benchmark, which you can find in pcg-dxsm.git. (Note 2025-06-09: I've edited this post substantially after discovering some problems with the results.) recap code bithack multiply benchmark results conclusion recap Briefly, there are two basic ways to convert a random integer to a floating point number between 0.0 and 1.0: Use bit fiddling to construct an integer whose format matches a float between 1.0 and 2.0; this is the same span as the result but with a simpler exponent. Bitcast the integer to a float and subtract 1.0 to get the result. Shift the integer down to the same range as the mantissa, convert to float, then multiply by a scaling factor that reduces it to the desired range. This produces one more bit of randomness than the bithacking conversion. (There are other less basic ways.) code The double precision code for the two kinds of conversion is below. (Single precision is very similar so I'll leave it out.) It's mostly as I expect, but there are a couple of ARM instructions that surprised me. bithack The bithack function looks like: double bithack52(uint64_t u) { u = ((uint64_t)(1023) << 52) | (u >> 12); return(bitcast(double, u) - 1.0); } It translates fairly directly to amd64 like this: bithack52: shr rdi, 12 movabs rax, 0x3ff0000000000000 or rax, rdi movq xmm0, rax addsd xmm0, qword ptr [rip + .number] ret .number: .quad 0xbff0000000000000 On arm64 the shift-and-or becomes one bfxil instruction (which is a kind of bitfield move), and the constant -1.0 is encoded more briefly. Very neat! bithack52: mov x8, #0x3ff0000000000000 fmov d0, #-1.00000000 bfxil x8, x0, #12, #52 fmov d1, x8 fadd d0, d1, d0 ret multiply The shift-conv ## Understanding Gradient Noise with WebGL2 and GLSL DevFeed: [Understanding Gradient Noise with WebGL2 and GLSL]() Original publisher: [Read original article]() Published: 2025-06-06T14:45:38Z Content type: tutorial Language: en Sources: [The Last Static Blog RSS]() Topics: [glsl](), [GPU](), [Code](), [hashing]() Tags: [code](), [complexity](), [cpu](), [floating-point](), [function](), [glsl](), [graphics](), [hashing](), [math](), [performance](), [procedural](), [prog]() ### AI overview This tutorial explains gradient noise, beginning with its one-dimensional form and progressing through higher dimensions and complexity. It uses a GPU-oriented approach with WebGL2 and GLSL, including deterministic coordinate-based pseudo-random values and hashing considerations. ### Source excerpt You've most likely heard about gradient noise through the name Perlin noise, which refers to one particular implementation with various CPU optimizations. Because it's an incredible tool for creative work, it's used virtually everywhere: visual effects, video games, procedural mathematical art, etc. While getting it right can sometimes be subtle, a "broken" implementation can still look good or interesting. After all, "it looks fine, and I'm an artist". In order to gain a deeper and more meaningful understanding we will start studying the 1D version (a case often omitted in the literature), then slowly climb our way up in dimensions and complexity. We'll also work from a GPU perspective rather than a CPU-based one, hence all code snippets and visuals here are implemented in WebGL2/GLSL (hopefully without being too heavy on performance). They should run on most modern devices; let me know if you run into issues. Before we begin, credit where it's due: most of the material here are nothing new. This article is the result of weeks of studying and experimenting with the maths from Inigo Quilez's incredible pages and other scattered resources over the Internet. But as rich and valuable these resources are, they sometimes move quickly over the details, assuming they're obvious. This post is an attempt to fill those gaps. A welcoming wavy 1D gradient noise signal Hashing function and pseudo-random values At the most elementary level, we need a deterministic coordinate based pseudo-random system. More specifically, for any given integer coordinate we need a random value, and as uniformly distributed as possible. Something like: \begin{aligned} h(-3) &= -0.006124 \\ h(-2) &= -0.996686 \\ h(-1) &= 0.200864 \\ h(0) &= -1.000000 \\ h(1) &= 0.053313 \\ h(2) &= -0.893312 \\ h(3) &= 0.854923 \\ \text{...} \end{aligned} Perlin's implementation relies on a permutation table, which is convenient when working on the CPU, but more awkward for a shader. On the GPU, most people rely on v ## Falcon-Edge: A series of powerful, universal, fine-tunable 1.58bit language models. DevFeed: [Falcon-Edge: A series of powerful, universal, fine-tunable 1.58bit language models.]() Original publisher: [Read original article]() Author: Younes B; Qiyang Zhao; Hang Zou; Rhaiem; Ilyas Chahed; Maksim Velikanov; Jingwei Zuo; Mike Lubinets; Hakim Hacid; Falcon LLM TII UAE Published: 2025-05-15T13:13:45Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [Large Language Model](), [LLM Techniques](), [quantization](), [Compression](), [Fine-tuning](), [Training AI Models](), [hugging face](), [AI Inference]() Tags: [compression](), [fine-tuning](), [floating-point](), [hugging-face](), [language-models](), [precision](), [quantization](), [train](), [training]() ### AI overview The article introduces Falcon-Edge, a series of 1.58-bit language models based on the BitNet architecture. The models use ternary weights during training to reduce memory use and improve deployment efficiency, and are offered in 1-billion- and 3-billion-parameter base and instruction-tuned variants. The article describes their training approach, fine-tuning variants, and evaluation on the former Hugging Face leaderboard v2 benchmark. ### Source excerpt A Blog post by Technology Innovation Institute on Hugging Face ## CPU Performance Optimization notes DevFeed: [CPU Performance Optimization notes]() Original publisher: [Read original article]() Author: Graham King Published: 2025-03-29T16:15:00Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [cpu](), [Optimization](), [performance-optimization](), [Cache](), [Code](), [data](), [floating-point]() Tags: [array](), [arrays](), [cache](), [code](), [cpu](), [cpu-optimization](), [data](), [floating-point](), [hardware](), [loops](), [memory](), [optimization](), [performance](), [performance-optimization](), [software]() ### AI overview Raw notes on CPU performance optimization covering data locality, cache behavior, memory alignment, data layout, prefetching, integer and floating-point types, powers of two, vectorization, and predictable branching. ### Source excerpt Raw notes on CPU optimization ## The Dangers of Testing in SQLite as a Postgres User DevFeed: [The Dangers of Testing in SQLite as a Postgres User]() Original publisher: [Read original article]() Author: Brian Holt Published: 2025-02-17T18:46:05Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Testing](), [PostgreSQL](), [SQLite](), [SQL](), [Databases]() Tags: [floating-point](), [gotchas](), [latency](), [postgres](), [postgresql](), [sql](), [sqlite](), [testing]() ### AI overview The article explains why SQLite is convenient for isolated tests and warns that SQLite-based tests can create false confidence for PostgreSQL users. It highlights differences in SQL dialects, client-server behavior, performance, and type enforcement, including SQLite accepting a floating-point value in an INTEGER column where PostgreSQL raises an error. ### Source excerpt SQLite is genuinely an incredible piece of technology. Instead of having a list of which companies used the database, the SQLite site simply tells you its on every Android phone, every iPhone, in every browser, in every Mac, in every Windows machine. "Billions and billions of cop... ## A Java Conversion Puzzler: Understanding Implicit Casting and Overflow DevFeed: [A Java Conversion Puzzler: Understanding Implicit Casting and Overflow]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-07T22:23:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [floating-point](), [Code]() Tags: [code](), [critical](), [exercise](), [floating-point](), [info](), [java](), [performance](), [puzzles]() ### AI overview This article explains a Java conversion puzzle involving compound assignment, implicit casting, floating-point rounding, and integer overflow. It shows why adding 0.0f can produce different results for int and long values, including a conversion to Integer.MIN_VALUE when the rounded value is cast back to int. ### Source excerpt This article explores a subtle Java conversion puzzle that challenges assumptions about how arithmetic operations, implicit casting, and floating-point conversions interact. Inspired by complexities often encountered in low-latency and high-performance environments, it demonstrates why a keen understanding of Java's type system is essential for building reliable and efficient applications. Introduction The following example demonstrates a scenario where an innocuous-looking arithmetic operation leads to a surprising result. While such questions are rare and arguably impractical, they highlight subtle behaviours that can affect correctness and performance, especially in critical systems like high-frequency trading platforms or complex data-processing pipelines. The Problem: A Surprising Print Statement Consider the following code: int i = Integer.MAX_VALUE; i += 0.0f; int j = i; System.out.println(j == Integer.MAX_VALUE); // true At first glance, one might assume that adding 0.0f to an int should not change its value. Indeed, the output true reinforces this notion. However, if you change int i for long i, things get weird: long i = Integer.MAX_VALUE; // only the type of i is changed i += 0.0f; int j = (int) i; System.out.println(j == Integer.MAX_VALUE); // false System.out.println(j == Integer.MIN_VALUE); // true What is going on, you might wonder? Let me start by explaining why using a long gives such a strange result. Understanding the Implicit Casting The key detail lies in how Java handles the += operator. It is not strictly equivalent to a = a + b; but rather: a += b; has a subtle difference which most of the time doesn't matter: // has an implicity cast here a = (typeOf(a)) (a + b); Another subtle feature of addition is that the result is the "wider" of the two types. This means that: i += 0.0f; is actually: i = (int) ((float) i + 0.0f); // or i = (long) ((float) i + 0.0f); The result of (float) i can be imprecise due to floating-point rounding. A float has a 2 ## Why Does Math.round(0.49999999999999994) Round to 1? DevFeed: [Why Does Math.round(0.49999999999999994) Round to 1?]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-07T21:02:00Z Content type: tutorial Language: en Sources: [Vanilla Java]() Topics: [floating-point](), [Java](), [Programming](), [implementation]() Tags: [article](), [code](), [exercise](), [floating-point](), [info](), [java](), [precision](), [programming](), [puzzles]() ### AI overview This article explains why Java 6 can return 1 when Math.round() is applied to a value slightly below 0.5. It attributes the result to binary floating-point representation, rounding behavior, and implementation details, and contrasts Java 6 with Java 7. ### Source excerpt 1. Defining the Problem In many numerical computations, one would reasonably expect that rounding 0.499999999999999917 should yield 0, since it appears to be slightly less than 0.5. Yet, in Java 6, calling Math.round() on this value returns 1, a result that may initially seem baffling. This seemingly minor discrepancy stems from the interplay of binary floating-point representation, rounding modes, and the particular internal implementation details of Math.round() in earlier Java releases. For professionals in performance-sensitive environments--such as those working in financial technology or high-precision scientific applications--understanding these subtleties is more than just an academic exercise. Even tiny rounding differences can influence trading algorithms, pricing models, or simulations. Moreover, developers and enthusiasts who appreciate the low-level mechanics behind Java's numeric types will find valuable insights into how these internal workings affect everyday programming tasks. This article delves into why this unexpected rounding occurs, sheds light on the constraints of double-precision arithmetic, and contrasts the behaviour in Java 6 against newer versions like Java 7. Consider, for instance, the closely related question: Why does Math.round(0.49999999999999994) return 1 rather than 0? Although it might initially seem like a bug, it is, in fact, a predictable outcome once we acknowledge the inherent imprecision of floating-point arithmetic. By the end, you will have a clearer understanding of why these rounding anomalies happen, and how to avoid or mitigate their effects in your own code. 2. The IEEE 754 64-bit Double-Precision Format Component Bit Count Interpretation Sign 1 Determines the sign of the number: 0 indicates a positive value, 1 indicates a negative value. Exponent 11 Encodes the exponent using a bias of 1023. The stored value E is interpreted as E - 1023 for the actual exponent. Mantissa (Fraction) 52 Represents the significand (fract ## Why pg\_dump Is Useful for PostgreSQL Data Migration and Troubleshooting DevFeed: [Why pg\_dump Is Useful for PostgreSQL Data Migration and Troubleshooting]() Original publisher: [Read original article]() Author: Robert Haas (noreply@blogger.com) Published: 2024-11-01T15:56:00Z Content type: opinion Language: en Sources: [Robert Haas]() Topics: [PostgreSQL](), [postgresql clusters](), [Databases](), [cpu](), [floating-point]() Tags: [backup](), [backups](), [cpu](), [database](), [floating-point](), [pg-dump](), [postgresql](), [sql](), [version]() ### AI overview The article explains why pg_dump is useful beyond full-cluster backups. Its human-readable SQL output can support database migration, major-version changes, CPU architecture changes, and troubleshooting, although it may require manual modification and can incur performance costs or fail in some cases. ### Source excerpt I wrote a blog post a couple of weeks ago entitled Is pg_dump a Backup Tool?. In that post, I argued in the affirmative, but also said that it's probably shouldn't be your primary backup mechanism. For that, you probably shouldn't directly use anything that is included in PostgreSQL itself, but rather a well-maintained third-party backup tool such as barman or pgbackrest. But today, I want to talk a little more about why I believe that pg_dump is both amazingly useful for solving all kinds of PostgreSQL-related problems and also just a great piece of technology. Read more " ## Optimizing Digit Counting for Kotlin Long Values DevFeed: [Optimizing Digit Counting for Kotlin Long Values]() Original publisher: [Read original article]() Author: Romain Guy Published: 2024-05-27T00:00:00Z Content type: article Language: en Sources: [Posts on Romain Guy]() Topics: [Code](), [Optimization](), [Kotlin]() Tags: [android](), [assembly](), [code](), [developer](), [floating-point](), [graphics](), [kotlin](), [numbers](), [operator](), [optimization](), [performance]() ### AI overview This article explores ways to count the decimal digits in positive Kotlin Long values without relying on floating-point log10, which cannot represent every Long value exactly. It compares a straightforward branching approach with a binary-search solution and reports faster execution for the latter on a Pixel 6. ### Source excerpt Jake Wharton recently caused me to go down yet another silly optimization rabbit hole when he nonchalantly linked to a piece of code used to count the number of digits in a Long during a Slack conversation about Kotlin's lack of ternary operator. This of course triggered folks like Madis Pink and me to want to optimize it... Counting digits Link to heading The simplest way to count the number of digits would be to compute log10(n).toInt() + 1, where n is our input number. Unfortunately logarithmic functions like Kotlin's log10 are only defined for floating point numbers. If our input is an Int or a Long, we could first convert to Double and then call log10, but not all Long values can be stored in a Double (any value above 2^53), and we would have to special case 0. We must therefore find a different solution1. ## Thread Count Scaling Part 2. Blender and Clang DevFeed: [Thread Count Scaling Part 2. Blender and Clang]() Original publisher: [Read original article]() Author: Denis Bakhvalov Published: 2024-05-10T04:00:00Z Content type: article Language: en Sources: [Denis Bakhvalov]() Topics: [Benchmark](), [benchmarking](), [Concurrency](), [C++](), [Processes]() Tags: [benchmark](), [blender](), [book-chapters](), [c-plus-plus](), [clang](), [compilation](), [concurrency](), [floating-point](), [parallel](), [parallelism](), [performance](), [performance-analysis](), [process](), [scale](), [thread](), [threads]() ### AI overview This article examines thread-count scaling in Blender and Clang. Blender scales across the available threads because its rendering workload is highly parallelizable, but scaling declines as E-cores and SMT sibling threads are used. Clang compilation is also massively parallel, though its scaling is affected by cache and branch behavior, core differences, SMT, and frequency throttling. ### Source excerpt Subscribe to my newsletter, support me on Patreon, Github, or by PayPal donation. This blog is an excerpt from the book. More details in the introduction. Blender is the only benchmark in our suite that continues to scale up to all 16 threads in the system. The reason for this is that the workload is highly parallelizable. The rendering process is divided into small tiles, and each tile can be rendered independently. However, even with this high level of parallelism, the scaling is only . ## Subpixel GUI DevFeed: [Subpixel GUI]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2023-08-09T13:32:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [GUI](), [floating-point](), [API](), [test]() Tags: [3d](), [4k](), [components](), [floating-point](), [gui](), [pairs](), [points](), [precision](), [scale](), [subpixel]() ### AI overview The article explains how Red/View addressed a GUI dragging glitch caused by converting integer coordinates to floating-point values on displays using scaling above 100%. It introduces point2D! and point3D! datatypes to represent decimal positions and sizes. ### Source excerpt Maybe you didn't notice, but Red/View, our GUI engine, has subpixel precision from the beginning! Unfortunately, that level of precision was not directly accessible to end users, until now. Actually, it would be more accurate to say that we had subpixel resolution only so far. The guilty part is the pair! datatype being limited to integer components only, while subpixel precison requires decimal numbers. So we have recently introduced new datatypes to cope with that. What urged us to make those changes now was a very peculiar visual glitch caused by that dissonance. That glitch happens during face dragging operations. Here is an example using our View test script: As you can see, on some positions, the face starts shaking while the mouse cursor remains still. This affects any type of face. The shaking is about ±2 pixels. It is caused by the difference in precision between the /offset facet expressed in integer numbers and the backend API, which only deals with floating point numbers. The accumulated error when converting integer->float->integer gives a 2 pixels difference. Such error happens on displays where the scaling factor is different from 100%. With the rise of 2K, 3K and 4K displays, a scaling factor > 100% has become the norm, making this glitch more frequent. You might think that this is not a big issue until you start building custom scrollbars and see your entire scrolled content shaking massively... New point datatypes In order to provide decimal positions and sizes for View faces, extending the existing pair! datatype was considered, though, the pair syntax can hardly scale up for such needs: 2343.122x54239.44 2343.122x54239.44x6309.332 2343.122x54239.44x6309.332x442.3321 2.33487e9x54239.44 2.33487e9x54239.44x9.83242e17 2.33487e9x54239.44x9.83242e17x5223.112 1.#infx1.#infx1.#inf As you can notice there, it quickly becomes difficult to read and identify the individual components. So we opted for adding a new literal form (hence a new datatype) that matc ## Restricted TextFields In SwiftUI - A Reusable Implementation DevFeed: [Restricted TextFields In SwiftUI - A Reusable Implementation]() Original publisher: [Read original article]() Author: Balazs Toth Published: 2023-04-17T14:24:20Z Content type: tutorial Language: en Sources: [QuickBird Studios Blog]() Topics: [SwiftUI](), [implementation](), [Forms]() Tags: [floating-point](), [forms](), [guide](), [implementation](), [ios](), [post](), [swiftui](), [validation]() ### AI overview This tutorial explains how to implement reusable restricted input fields in SwiftUI. It models constrained values with types and ranges, uses string state for TextField bindings, and discusses moving parsing and validation logic out of the view. ### Source excerpt SwiftUI may lack built-in restricted textfield functionality, but our in-depth guide is here to fill the gap! This guide helps you to implement reusable, versatile restricted input fields in SwiftUI. The post Restricted TextFields In SwiftUI - A Reusable Implementation appeared first on QuickBird Studios. ## Basic values in Kotlin DevFeed: [Basic values in Kotlin]() Original publisher: [Read original article]() Published: 2023-02-27T00:01:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Kotlin](), [Compiler]() Tags: [compiler](), [floating-point](), [format](), [kotlin](), [literals](), [number](), [operations](), [precision](), [readability](), [types](), [values](), [workshop-learning-programming]() ### AI overview This tutorial introduces Kotlin's basic value types and literals, including numbers, booleans, characters, strings, and arrays. It explains Kotlin's object model, compiler optimization of some types, numeric ranges and precision, explicit type conversions, and underscore formatting in number literals. ### Source excerpt Learn about the basic Kotlin values, types and operations. ## Always use feenableexcept() when doing floating point math DevFeed: [Always use feenableexcept() when doing floating point math]() Original publisher: [Read original article]() Published: 2022-12-24T20:28:43Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [floating-point](), [C](), [C++](), [exceptions](), [Optimization](), [gcc](), [Linux]() Tags: [c](), [c-plus-plus](), [compiler](), [exceptions](), [floating-point](), [linux](), [math](), [optimization](), [programming]() ### AI overview This tutorial explains how floating-point exceptions, infinities, and NaNs can occur silently in C and C++ programs, especially under compiler optimization. It describes enabling floating-point exceptions under Linux with feenableexcept() and notes remaining issues involving SIMD optimization. ### Source excerpt This is a refreshed & expanded copy of a very old page I hosted outside of this blog. I recently ran into "silent NaNs" again, and thought it might be a good idea to republish this advice here. A small post that documents something that almost no one appears to know. And if you do anything with floating point, you do need to know. Exceptions In C or C++, try this: [Next page]()