# floating-point Floating-point arithmetic is a computing method involving numeric formats and arithmetic operations, including binary and decimal formats, in computer programming environments. 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 и как раз о новинках и хочется рассказать. Читать далее ## Mapping Strings to Float Arrays in Go: How Fast Can We Go? DevFeed: [Mapping Strings to Float Arrays in Go: How Fast Can We Go?]() Original publisher: [Read original article]() Author: Daniel Lemire Published: 2026-05-05T19:01:09Z Content type: article Language: en Sources: [Daniel Lemire]() Topics: [Go Language](), [Benchmark](), [Data structures](), [floating-point]() Tags: [go](), [harness](), [memory](), [performance](), [vectors]() ### AI overview This article examines mapping strings to small float arrays in Go using the constmap library. It explains an immutable map based on a binary fuse filter and compares index-based and pointer-based value storage with a standard Go map. In the reported benchmark, the indexed constmap was twice as fast as the Go map, while raw pointers reduced lookup time further, with important garbage-collector and serialization limitations. ### Source excerpt A common pattern in modern software is to map a string key to a small array of floating-point numbers. Word embeddings, feature vectors, lookup tables for physical constants: all variations on the same theme. In Go, the obvious way to write this is a map[string][]float32. But how fast is it, really, and can we do ... Continue reading Mapping Strings to Float Arrays in Go: How Fast Can We Go? ## 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 ## 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. ## 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 ## 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 ## 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 ## 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 ## 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: ## Animating fonts in Jetpack Compose DevFeed: [Animating fonts in Jetpack Compose]() Original publisher: [Read original article]() Author: sinasamaki Published: 2022-11-03T06:32:43Z Content type: tutorial Language: en Sources: [sinasamaki]() Topics: [Jetpack Compose](), [Compose](), [floating-point]() Tags: [animation](), [article](), [behavior](), [code](), [color](), [compose](), [extend](), [floating-point](), [function](), [jetpack](), [jetpack-compose](), [object](), [optional](), [state]() ### AI overview A tutorial on animating between TextStyles in Jetpack Compose. It explains using lerp with a float animation and introduces a helper function that manages animation state and completion callbacks to reduce repetitive code. ### Source excerpt Jetpack compose offers many different animation helper functions. We can easily animate floats, colors, density-pixels, etc. These helper functions are usually called like this: val animatedColor by animateColorAsState( targetValue = color, animationSpec = tween(durationMillis = 300, easing = LinearEasing) ) The animateColorAsState function returns a state object and we can simply listen to ## Calculating Middle Points for Integer and Floating-Point Numbers DevFeed: [Calculating Middle Points for Integer and Floating-Point Numbers]() Original publisher: [Read original article]() Published: 2020-10-28T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Programming](), [floating-point](), [math](), [Code]() Tags: [exception](), [floating-point](), [function](), [programming](), [test]() ### AI overview This programming article examines how to calculate the middle point between two numbers. It discusses representable numeric subsets, input ordering and equality, integer cases with odd distances, and floating-point numbers. ### Source excerpt Introduction Working with numbers in programming never was a simple thing. In math, we deal with various sets of numbers - whole numbers, rational, complex. All these sets are infinite - that means that for any number we can find another smaller one and one which is bigger. In programming when we work with numbers we deal with some subset of these sets - that many that can be represented with a given amount of bits. When we want to work with whole numbers we can use e.g. Integer, which are the numbers being able to be represented usually with 4 bits. For floating-point numbers - say Double - it is 8 bits. There is no plus or minus infinity (in Double there are +/- infinity, though they are used for special cases). ## Ice Lake AVX-512 Downclocking DevFeed: [Ice Lake AVX-512 Downclocking]() Original publisher: [Read original article]() Author: Travis Downs (travis.downs@gmail.com) Published: 2020-08-19T00:00:00Z Content type: article Language: en Sources: [Performance Matters]() Topics: [cpu](), [intel](), [floating-point](), [Rocket]() Tags: [avx](), [avx512](), [blog](), [cpu](), [floating-point](), [icelake](), [intel](), [performance](), [x86]() ### AI overview This technical post investigates AVX2- and AVX-512-related license-based downclocking on Intel Ice Lake and Rocket Lake CPUs. Measurements from an Ice Lake i5-1035G4 indicate little frequency reduction from wider instructions, with a reported 100 MHz decrease in one single-core case. ### Source excerpt Examining the extent of AVX related downclocking on Intel's Ice Lake CPU ## The Floppy Disk of Floating Point DevFeed: [The Floppy Disk of Floating Point]() Original publisher: [Read original article]() Author: Evan Miller Published: 2020-07-13T13:35:00Z Content type: opinion Language: en Sources: [Evan Miller]() Topics: [Computing](), [floating-point](), [x86](), [Assembly](), [cpu]() Tags: [architecture](), [assembly](), [computing](), [cpu](), [floating-point](), [precision](), [standard](), [x86]() ### AI overview An essay reflecting on the x87 floating-point instruction set and its 80-bit extended-precision design. It describes the architecture's historical hardware support for mathematical functions and considers its eventual obsolescence. ### Source excerpt An essay that bids farewell to x87, a computing architecture too long for this world: The Floppy Disk of Floating Point ## Comparing Haskell and Julia for High-Performance Numerical Code DevFeed: [Comparing Haskell and Julia for High-Performance Numerical Code]() Original publisher: [Read original article]() Author: Dominic Steinitz Published: 2017-06-02T15:47:12Z Content type: opinion Language: en Sources: [Maths, Stats & Functional Programming]() Topics: [Haskell](), [The Julia Language](), [Programming](), [floating-point]() Tags: [analysis](), [code](), [haskell](), [llvm](), [numerical-methods](), [numerics](), [programming]() ### AI overview The article compares Julia with a Haskell approach using the Accelerate domain-specific embedded language for numerical computing. It discusses the goal of combining type safety with high performance and the motivation of supporting statistical inference methods. ### Source excerpt Introduction Summary Back in January, a colleague pointed out to me that GHC did not produce very efficient code for performing floating point abs. I have yet to produce a write-up of my notes about hacking on GHC: in summary it wasn't as difficult as I had feared and the #ghc folks were extremely helpful. ... Continue reading Haskell for Numerics? ## Beal's Conjecture Revisited DevFeed: [Beal's Conjecture Revisited]() Original publisher: [Read original article]() Published: 2015-10-20T00:00:00Z Content type: article Language: en Sources: [Peter Norvig]() Topics: [floating-point]() Tags: [errors](), [floating-point](), [number-theory](), [precision](), [program]() ### AI overview An update on a program that searches for counterexamples to Beal's Conjecture, explaining why apparent counterexamples caused by floating-point arithmetic are invalid. The page also catalogs common errors in purported proofs and counterexamples. ### Source excerpt Updating the work I did in 2000 to search for counterexamples to Beal's Conjecture. Lists some of the things that people do wrong in trying to settle the conjecture. ## Rounding and integer math DevFeed: [Rounding and integer math]() Original publisher: [Read original article]() Published: 2015-05-16T00:00:00Z Content type: tutorial Language: en Sources: [Front Page on ReactOS Website]() Topics: [math](), [floating-point]() Tags: [c](), [floating-point](), [free](), [math](), [open-source](), [os](), [react](), [reactos](), [win32](), [winapi]() ### AI overview This article examines whether integer arithmetic can reproduce rounding results without using floating-point math. It simplifies the problem to unsigned values and analyzes the formulas for even and odd divisors. ### Source excerpt It sometimes happens that in your program you need to divide integer values and then round the result. Something like int result = lrint((double)int_a / (double)int_b); But sometimes it is desirable to not use floating point math at all. The question is: Can we do the same calculation with integer math and get exactly the same result? Let's simplify our case, by limiting to unsigned values (for signed values it is very similar, only the formulas get a bit more complex). ## NTVDM progress DevFeed: [NTVDM progress]() Original publisher: [Read original article]() Published: 2014-03-13T00:00:00Z Content type: news Language: en Sources: [Front Page on ReactOS Website]() Topics: [Emulator](), [ReactOS](), [Operating system](), [cpu](), [x86](), [bios](), [floating-point](), [Arm]() Tags: [arm](), [bios](), [cpu](), [emulator](), [floating-point](), [free](), [memory](), [open-source](), [os](), [performance](), [react](), [reactos](), [win32](), [winapi](), [x86]() ### AI overview This progress update describes ReactOS NTVDM, a virtual machine for running 16-bit programs. It reports implemented support for a 486-compatible CPU, basic video, memory management, sound, a 32-bit BIOS, and 32-bit DOS, while noting missing features and incomplete operating-system integration. ### Source excerpt A while back Aleksander Andrejevic began working on a NTVDM implementation for ReactOS to support 16bit programs. This was one of the more often requested features by the community, which was met with some ambivalence by the developers themsleves since it entailed a significant amount of work. Aleksander then appeared and instead of simply asking for the feature, rolled up his sleeve to do the actual work. Since then NTVDM has made significant progress and other developers like Hermès Bélusca-Maïto and community member Vampyre have joined in to help. ## Newsletter 44 DevFeed: [Newsletter 44]() Original publisher: [Read original article]() Published: 2008-08-06T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [bug](), [Filesystems](), [floating-point](), [Kernel](), [x86](), [Arm](), [Assembly](), [boot]() Tags: [arm](), [assembly](), [boot](), [bug](), [developer](), [filesystem](), [floating-point](), [free](), [kernel](), [newsletter](), [open-source](), [os](), [react](), [reactos](), [win32](), [winapi](), [x86]() ### AI overview ReactOS Newsletter 44 reports a handle-creation crash fix, ongoing filesystem-checking work, kernel-side floating-point changes for Win32 on x86, an appearance at Linuxworld, and progress toward ARM boot support. ### Source excerpt General Development There was an interesting bug involving handle creation a while back. When creating the 4100th handle, the system would crash. This bug was exposed through VLC and was eventually fixed by Christoph von Wittich. The problem was the result of an incorrect calculation, where the code attempted to access an index higher than 4099 on the first table. Such values are out of bounds and are supposed to be found in the second table and higher.