# pairs Published articles for pairs. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Tabulation Tribulations DevFeed: [Tabulation Tribulations]() Original publisher: [Read original article]() Author: Bartosz Milewski Published: 2026-05-23T16:05:49Z Content type: article Language: en Sources: [Bartosz Milewski's Programming Cafe]() Topics: [Graphs]() Tags: [category-theory](), [double-categories](), [graph](), [mapping](), [object](), [pairs](), [profunctor-equipment](), [profunctors]() ### AI overview This article explains tabulations in double categories by relating them to graphs of functions, relations, and profunctors. It describes the category of elements of a profunctor and introduces tabulation through projections and a universal property, including conditions for morphisms and 2-cells. ### Source excerpt Previously: Bending, Yanking, and Cartesian Squares in Double Categories. We all know what a graph of a function is: it's a set of pairs , where . Similarly, a graph of a relation is a set of pairs where is related to . A profunctor can be viewed as a proof-relevant relation. So a graph [...] ## Finding near-duplicates with Jaccard similarity and MinHash DevFeed: [Finding near-duplicates with Jaccard similarity and MinHash]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2024-07-03T23:00:00Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [dataset](), [Website]() Tags: [dataset](), [pairs](), [pipeline](), [range](), [scale]() ### AI overview This article explains approximate document deduplication using Jaccard similarity and the MinHash approximation technique. It discusses defining similarity between document pairs, setting a threshold for approximate duplicates, and why approximate similarity is not transitive. ### Source excerpt Suppose we have a large collection of documents, and we wish you identify which documents are approximately the same as each other. For instance, we may have crawled the web over some period of time, and expect to have fetched the "same page" several times, but to see slight differences in metadata, or that we have several revisions of a page following small edits. In this post I want to explore the method of approximate deduplication via Jaccard similarity and the MinHash approximation trick. ## 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 ## Ideas and Solutions for Advent of Code 2021 in Kotlin -- Part 3/4 DevFeed: [Ideas and Solutions for Advent of Code 2021 in Kotlin -- Part 3/4]() Original publisher: [Read original article]() Author: Yev Kanivets Published: 2021-12-26T14:22:49Z Content type: tutorial Language: en Sources: [xorum.io - Medium]() Topics: [Advent of Code](), [Kotlin](), [Programming](), [competitive-programming](), [Graphs](), [math]() Tags: [advent-of-code](), [algorithms](), [array](), [code](), [competitive-programming](), [data-structures](), [graph-theory](), [kotlin](), [memory](), [pairs](), [programming](), [solutions](), [time]() ### AI overview This article presents high-level ideas and Kotlin solutions for Advent of Code 2021 tasks from days 13 to 15. It discusses folding a 2D array, modeling polymer growth with dynamic programming, and finding a shortest path in a 2D array. ### Source excerpt Ideas and Solutions for Advent of Code 2021 in Kotlin -- Part 3/4 The third week of Advent of Code requires more time and even some competitive programming knowledge like dynamic programming and graph theory. In this article, I share some high-level ideas and my solutions if you need a hint or a few to get that gold star. Ideas and Solutions for tasks 1 to 6 can be found here, for tasks 7 to 12 -- here. Day 13: Transparent Origami The 2D array contains two types of symbols -- . and #. This array can be folded horizontally and vertically multiple times. When folding # symbols replace . symbols, but not vice versa. Here is the complete task. This is a modeling task, which you can do on the 2D array itself, but the possible range is quite large, so you can hit a memory limit. The smarter solution would be to fold the # symbols (the initial input, actually). Such folding can be done with Kotlin's fold function using the initial value of # symbol positions and mapNotNull, which mirrors X or Y coordinates depending on the fold direction. Here is my solution. Day 14: Extended Polymerization We get the initial string (template) consisting of uppercase letters, which describe the initial state of the polymer. The list of pair insertion rules allows growing the initial polymer step by step exponentially. We need to model this growth during 10 (first sub-task) and 40 (second sub-task) steps. Here is the complete task. The first sub-task can be solved just by modeling, but even 20 steps are too long and require too much memory and time. The (much) better solution is based on dynamic programming. You can easily see that every pair grows independently of others (new elements are always added inside the pair). It means that the solution can be found for each pair separately and then combined. It doesn't speed up things sufficiently though. But makes the solution easier? Yes. Now, let's grow each pair step by step. So at each step, every pair (usually) produces two more pairs, which h ## Encore's approach to simplifying distributed tracing with static analysis DevFeed: [Encore's approach to simplifying distributed tracing with static analysis]() Original publisher: [Read original article]() Author: André Eriksson Published: 2021-05-04T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [tracing](), [distributed-systems](), [Instrumentation](), [telemetry](), [Graphs]() Tags: [distributed](), [distributed-systems](), [instrumentation](), [observability](), [pairs](), [tracing]() ### AI overview The article explains why distributed tracing can be difficult to use in distributed systems: generic span data is hard to interpret, and instrumentation requires error-prone context propagation. It presents Encore's approach of using static analysis to provide more useful tracing insights out of the box. ### Source excerpt Everything's on fire! Oh that's fine, that's normal. ## Pairing Guidelines DevFeed: [Pairing Guidelines]() Original publisher: [Read original article]() Published: 2021-01-17T00:00:00Z Content type: article Language: en Sources: [Robert C. Martin](), [The Clean Code Blog]() Topics: [Programming](), [Code]() Tags: [bug](), [pairs](), [programming](), [projects](), [team](), [time]() ### AI overview The article presents practical guidelines for pair programming. Pairing is most valuable for non-trivial but not deeply difficult programming work, while very deep problems may require concentration and trivial tasks usually do not justify pairing. It recommends voluntary, informal, short sessions and emphasizes balancing collaboration with individual work and team familiarity. ### Source excerpt Everybody pairs from time to time. It is a rare programmer who has not sat down with another programmer to look something over or help find a bug. Deep problems, that require much heavy thinking, do not often lend themselves to pairing. The interaction between the programmers tends to disrupt the necessary concentration. On the other hand, it is not uncommon for programmers to get caught in a problem that they think is deep, but for which there is a much simpler solution that another programmer could quickly see. So it is wise to start deep problems with a pair, or even a mob, but then break it up when it becomes clear that the problem is irreducible. On the other side of the spectrum, there is no good reason to pair on trivial matters. Fleshing out a list of error messages, or loading fifty fields into a form are relatively mindless activities that do not require the scrutiny afforded by pairing. Then there is the vast middle. This is where pairing/mobbing are most valuable. These are problems that are non-trivial, but also not particularly deep. This is 90% of all programming. Pairing on this type of code keeps that code well tested, well structured, and as simple as possible. Pairing should always be voluntary, never be forced, never be scheduled by a manager, and never tracked. It is an informal process that is entirely under the control of the individual programmers. Some people can't, or won't do it. That's ok; but it may require that their participation in certain projects be curtailed. Pairing sessions should be short-ish. 20-40 minutes at a time. (Tomato sized) With no more than three or four consecutive sessions of that length. This is not a rule, just an informal guideline. Not all code that would benefit from pairing, should be written by pairs. A mature team might pair 50% of the time, or even less. During the pairing sessions, a large amount of code will be reviewed; far more than the pair is actively writing; and thus the benefits of pairing will be s