https://mklab.gr/ Mon, 19 Oct 2026 03:19:18 +0000 MyBB https://mklab.gr/showthread.php?tid=2320 Thu, 01 Oct 2026 21:36:06 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=2320 numerical differentiation, which approximates derivatives using finite differences and can suffer from truncation and round-off errors, and symbolic differentiation, which manipulates mathematical expressions and can lead to enormous intermediate expressions, AD systematically applies the chain rule while executing the program. It can compute derivatives to approximately machine precision with only a small constant-factor increase in arithmetic work. This makes it useful in optimization, sensitivity analysis, physical modeling, probabilistic inference, and machine learning.

The article first explains forward-mode automatic differentiation using dual numbers of the form $x+\epsilon x'$, where $\epsilon^2=0$. The ordinary value and its derivative are propagated simultaneously through every operation in a program. For example, multiplication automatically produces $(x+\epsilon x')(y+\epsilon y')=xy+\epsilon(xy'+x'y)$, reproducing the product rule. Because the chain rule is automatically respected, the coefficient of $\epsilon$ at the end is the desired derivative or directional derivative. In terms of linear algebra, forward mode efficiently computes products of the Jacobian with vectors, $J_xf\cdot v$, without explicitly constructing the potentially enormous Jacobian matrix. 

The complementary technique, reverse-mode automatic differentiation, is particularly important when a function has many inputs but relatively few outputs—for example, when computing the gradient of a scalar objective function. Instead of propagating derivative information forward, reverse mode first records the intermediate computations in a structure commonly called a tape and then propagates gradient information backward. This makes it highly effective for computing gradients, but it introduces additional memory and implementation complexity because intermediate values must generally be stored. The author also discusses important difficulties such as perturbation confusion when differentiations are nested, the treatment of higher-order functions and data structures, and the fact that AD differentiates the actual computational procedure rather than necessarily the ideal mathematical function being approximated.

Finally, Radul examines the implementation and software-engineering challenges of AD. Simply using dual numbers can introduce substantial runtime overhead through memory allocation and operator dispatch, while reverse mode requires careful management of stored computation. The article also warns about cases where differentiating an approximation can produce a poorer derivative than directly implementing a known approximation to the derivative.

Different AD systems—including operator overloading, source-to-source transformation, and programming languages with AD built into their design—make different trade-offs concerning performance, nesting, higher-order functions, custom derivatives, and abstraction. Overall, the article presents AD not merely as a faster way to calculate derivatives, but as a meeting point between calculus, numerical computation, and programming-language design. [/url]


[url=https://alexey.radul.name/ideas/2013/introduction-to-automatic-differentiation/]ARTICLE]]> numerical differentiation, which approximates derivatives using finite differences and can suffer from truncation and round-off errors, and symbolic differentiation, which manipulates mathematical expressions and can lead to enormous intermediate expressions, AD systematically applies the chain rule while executing the program. It can compute derivatives to approximately machine precision with only a small constant-factor increase in arithmetic work. This makes it useful in optimization, sensitivity analysis, physical modeling, probabilistic inference, and machine learning.

The article first explains forward-mode automatic differentiation using dual numbers of the form $x+\epsilon x'$, where $\epsilon^2=0$. The ordinary value and its derivative are propagated simultaneously through every operation in a program. For example, multiplication automatically produces $(x+\epsilon x')(y+\epsilon y')=xy+\epsilon(xy'+x'y)$, reproducing the product rule. Because the chain rule is automatically respected, the coefficient of $\epsilon$ at the end is the desired derivative or directional derivative. In terms of linear algebra, forward mode efficiently computes products of the Jacobian with vectors, $J_xf\cdot v$, without explicitly constructing the potentially enormous Jacobian matrix. 

The complementary technique, reverse-mode automatic differentiation, is particularly important when a function has many inputs but relatively few outputs—for example, when computing the gradient of a scalar objective function. Instead of propagating derivative information forward, reverse mode first records the intermediate computations in a structure commonly called a tape and then propagates gradient information backward. This makes it highly effective for computing gradients, but it introduces additional memory and implementation complexity because intermediate values must generally be stored. The author also discusses important difficulties such as perturbation confusion when differentiations are nested, the treatment of higher-order functions and data structures, and the fact that AD differentiates the actual computational procedure rather than necessarily the ideal mathematical function being approximated.

Finally, Radul examines the implementation and software-engineering challenges of AD. Simply using dual numbers can introduce substantial runtime overhead through memory allocation and operator dispatch, while reverse mode requires careful management of stored computation. The article also warns about cases where differentiating an approximation can produce a poorer derivative than directly implementing a known approximation to the derivative.

Different AD systems—including operator overloading, source-to-source transformation, and programming languages with AD built into their design—make different trade-offs concerning performance, nesting, higher-order functions, custom derivatives, and abstraction. Overall, the article presents AD not merely as a faster way to calculate derivatives, but as a meeting point between calculus, numerical computation, and programming-language design. [/url]


[url=https://alexey.radul.name/ideas/2013/introduction-to-automatic-differentiation/]ARTICLE]]> https://mklab.gr/showthread.php?tid=2312 Thu, 01 Oct 2026 19:21:30 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=2312 “What Stronger Mathematical Language Can Reveal About Computation, Sets, and Infinity”, by Louis D’Alotto and Dmitri E. Kvasov, examines the idea that some apparent mathematical limitations may arise not from the objects themselves, but from the language and notation used to describe them. The authors begin with examples such as Roman numerals, where the absence of zero makes certain calculations awkward, and the Pirahã numeral system, which reportedly distinguishes only a few exact quantities before using the general concept of “many.” They use these examples to argue that richer mathematical languages can reveal distinctions that weaker systems conceal. This perspective is then extended to the mathematical treatment of infinity, where the authors introduce Yaroslav Sergeyev’s grossone numeral, written as ①, as an alternative framework for representing infinite and infinitesimal quantities.

The central mathematical example is Turing’s diagonal argument, traditionally used to demonstrate the existence of uncomputable functions. In the standard formulation, all computable binary functions can be arranged in an infinite square table, and changing each diagonal element produces a new function that differs from every function in the table. The article argues that this construction depends crucially on how infinity is represented. Sergeyev’s grossone system treats ① as the number of elements of the natural numbers and permits expressions such as $①-1$, $①$, and $①+1$. In this framework, the natural numbers can be represented as a finite-looking sequence extending to ①, while the number of binary functions is represented as $2^{①}$. 

From this perspective, the table used in Turing’s argument is interpreted not as a square table but as a rectangular table with ① columns and $2^{①}$ rows. The function constructed by diagonalization can therefore appear explicitly as another row of the table rather than as an uncomputable object outside it. The authors emphasize that this resembles the finite case, where diagonalization over a finite collection of binary functions does not produce an uncomputable function because the resulting function is simply another member of the complete finite table. The grossone framework is also presented as allowing finer distinctions among infinite quantities—for example, distinguishing $①$, $①+1$, $2①$, and $2^{①}$—where conventional cardinal arithmetic often identifies quantities such as $\aleph_0$, $\aleph_0+1$, and $\aleph_0-1$.

The article ultimately presents Infinity Computing based on grossone as a proposed extension of mathematical language that could affect both pure mathematics and computer science. The authors describe possible applications involving infinite sets, Turing machines, computation, optimization, and numerical analysis, arguing that richer notation may make previously invisible distinctions observable and computationally expressible. Importantly, the article presents this as a new mathematical paradigm and research program, rather than as an established replacement for classical computability theory. Its central philosophical message is that changing the mathematical language can change what distinctions we are able to formulate and investigate, while the grossone approach challenges readers to reconsider whether some conclusions traditionally associated with infinity reflect properties of infinity itself or limitations of the formal systems used to represent it.

ARTICLE]]> “What Stronger Mathematical Language Can Reveal About Computation, Sets, and Infinity”, by Louis D’Alotto and Dmitri E. Kvasov, examines the idea that some apparent mathematical limitations may arise not from the objects themselves, but from the language and notation used to describe them. The authors begin with examples such as Roman numerals, where the absence of zero makes certain calculations awkward, and the Pirahã numeral system, which reportedly distinguishes only a few exact quantities before using the general concept of “many.” They use these examples to argue that richer mathematical languages can reveal distinctions that weaker systems conceal. This perspective is then extended to the mathematical treatment of infinity, where the authors introduce Yaroslav Sergeyev’s grossone numeral, written as ①, as an alternative framework for representing infinite and infinitesimal quantities.

The central mathematical example is Turing’s diagonal argument, traditionally used to demonstrate the existence of uncomputable functions. In the standard formulation, all computable binary functions can be arranged in an infinite square table, and changing each diagonal element produces a new function that differs from every function in the table. The article argues that this construction depends crucially on how infinity is represented. Sergeyev’s grossone system treats ① as the number of elements of the natural numbers and permits expressions such as $①-1$, $①$, and $①+1$. In this framework, the natural numbers can be represented as a finite-looking sequence extending to ①, while the number of binary functions is represented as $2^{①}$. 

From this perspective, the table used in Turing’s argument is interpreted not as a square table but as a rectangular table with ① columns and $2^{①}$ rows. The function constructed by diagonalization can therefore appear explicitly as another row of the table rather than as an uncomputable object outside it. The authors emphasize that this resembles the finite case, where diagonalization over a finite collection of binary functions does not produce an uncomputable function because the resulting function is simply another member of the complete finite table. The grossone framework is also presented as allowing finer distinctions among infinite quantities—for example, distinguishing $①$, $①+1$, $2①$, and $2^{①}$—where conventional cardinal arithmetic often identifies quantities such as $\aleph_0$, $\aleph_0+1$, and $\aleph_0-1$.

The article ultimately presents Infinity Computing based on grossone as a proposed extension of mathematical language that could affect both pure mathematics and computer science. The authors describe possible applications involving infinite sets, Turing machines, computation, optimization, and numerical analysis, arguing that richer notation may make previously invisible distinctions observable and computationally expressible. Importantly, the article presents this as a new mathematical paradigm and research program, rather than as an established replacement for classical computability theory. Its central philosophical message is that changing the mathematical language can change what distinctions we are able to formulate and investigate, while the grossone approach challenges readers to reconsider whether some conclusions traditionally associated with infinity reflect properties of infinity itself or limitations of the formal systems used to represent it.

ARTICLE]]> https://mklab.gr/showthread.php?tid=1876 Mon, 07 Sep 2026 20:24:40 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1876 system design, architectural thinking, debugging, performance, security, reliability, and accountability. Instead of measuring skill by how much code someone can write, companies increasingly care about whether engineers can understand complex requirements, make sound technical decisions, anticipate failures and edge cases, and turn AI-generated code into maintainable production systems. 

The author recommends strengthening computer-science fundamentals, building realistic systems rather than tutorial projects, becoming excellent at debugging, using AI as a fast assistant rather than blindly trusting it, and creating strong public proof of work through serious projects and open-source contributions. In this new model, code becomes more of an output of engineering judgment than the main skill itself: the modern engineer must understand what to build, why it matters, how it should be designed, and how AI can accelerate the process without replacing human responsibility. 

ARTICLE]]> system design, architectural thinking, debugging, performance, security, reliability, and accountability. Instead of measuring skill by how much code someone can write, companies increasingly care about whether engineers can understand complex requirements, make sound technical decisions, anticipate failures and edge cases, and turn AI-generated code into maintainable production systems. 

The author recommends strengthening computer-science fundamentals, building realistic systems rather than tutorial projects, becoming excellent at debugging, using AI as a fast assistant rather than blindly trusting it, and creating strong public proof of work through serious projects and open-source contributions. In this new model, code becomes more of an output of engineering judgment than the main skill itself: the modern engineer must understand what to build, why it matters, how it should be designed, and how AI can accelerate the process without replacing human responsibility. 

ARTICLE]]> https://mklab.gr/showthread.php?tid=1873 Mon, 07 Sep 2026 20:15:49 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1873 The author also warns that AI can increase “comprehension debt”—teams may produce more code while understanding less of it—and cites studies suggesting more code churn, duplication, weaker debugging knowledge, and sometimes even lower real productivity despite developers feeling faster. The conclusion is not that more abstraction is always better: premature or poorly designed abstractions can hurt performance and flexibility. Instead, developers should use AI to generate straightforward implementations quickly, allow patterns to emerge, and then refactor toward clear, human-readable abstractions, because in the AI era the cost of writing code has fallen dramatically while the cost of understanding bad code has not. 

ARTICLE]]> The author also warns that AI can increase “comprehension debt”—teams may produce more code while understanding less of it—and cites studies suggesting more code churn, duplication, weaker debugging knowledge, and sometimes even lower real productivity despite developers feeling faster. The conclusion is not that more abstraction is always better: premature or poorly designed abstractions can hurt performance and flexibility. Instead, developers should use AI to generate straightforward implementations quickly, allow patterns to emerge, and then refactor toward clear, human-readable abstractions, because in the AI era the cost of writing code has fallen dramatically while the cost of understanding bad code has not. 

ARTICLE]]> https://mklab.gr/showthread.php?tid=1871 Mon, 07 Sep 2026 20:11:30 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1871 “Learn Software Design Basics: Key Phases and Best Practices” explains that effective software development begins well before coding, with a structured design process that makes systems easier to maintain, test, debug, and scale. It outlines five core stages: clearly defining the problem and scope, identifying realistic use cases, specifying detailed requirements, creating a high-level architecture, and developing a detailed component-level design. 

Using a Python-based financial expense categorization system as an example, the article demonstrates principles such as modularity, separation of concerns, loose coupling, encapsulation, well-defined interfaces, error handling, telemetry/logging, appropriate data structures, and Test-Driven Development (TDD). It also stresses the importance of explicitly documenting assumptions and design decisions, arguing that thoughtful software design reduces technical debt, prevents costly redesigns, improves collaboration, and produces software that can evolve more easily as requirements grow. 

ARTICLE]]> “Learn Software Design Basics: Key Phases and Best Practices” explains that effective software development begins well before coding, with a structured design process that makes systems easier to maintain, test, debug, and scale. It outlines five core stages: clearly defining the problem and scope, identifying realistic use cases, specifying detailed requirements, creating a high-level architecture, and developing a detailed component-level design. 

Using a Python-based financial expense categorization system as an example, the article demonstrates principles such as modularity, separation of concerns, loose coupling, encapsulation, well-defined interfaces, error handling, telemetry/logging, appropriate data structures, and Test-Driven Development (TDD). It also stresses the importance of explicitly documenting assumptions and design decisions, arguing that thoughtful software design reduces technical debt, prevents costly redesigns, improves collaboration, and produces software that can evolve more easily as requirements grow. 

ARTICLE]]> https://mklab.gr/showthread.php?tid=1811 Thu, 03 Sep 2026 23:02:54 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1811
Brilliant argues that AI is making the mechanical act of writing code increasingly cheap, so the most valuable programming skills are shifting away from simply knowing syntax. The developer’s role increasingly becomes deciding what should be built, how it should be designed, how AI should be directed, and how to determine whether the resulting software is actually correct. Brilliant organizes these abilities around seven areas: Taste, Incrementality, Specification & Design, Build, Verify, Security, and Abstraction. 

A central idea is that developers should work in small, understandable, verifiable increments. AI can generate code much faster than humans can review or understand it, creating what Brilliant calls comprehension debt: software may appear to work while nobody fully understands its assumptions, dependencies, or failure modes. The solution is to build thin end-to-end pieces, test risky assumptions early, use version control, keep changes reversible, and make sure each increment can be explained before moving on. 

The biggest change comes in the traditional development loop of specify → build → verify. As AI performs more of the build stage, Brilliant expects human expertise to concentrate increasingly on specification and verification. Developers need to define observable success criteria, design good data models and interfaces, decompose systems into independent components, understand dependencies and constraints, and then rigorously test AI-generated work. Brilliant therefore portrays the future programmer less as someone who types thousands of lines of code and more as a software architect, problem solver, reviewer, and director of AI systems. 

Key takeaways

• Writing code is becoming less scarce; good judgment is becoming more valuable.
  
• Knowing the problem domain remains essential because AI cannot reliably tell you when its own plausible-looking answer is wrong. 
  
• Specification may become as important as programming: clearly define behavior, constraints, architecture, and tests before asking AI to implement something.
  
• Verification becomes the bottleneck. Generating software is easy; proving that it is correct, secure and maintainable is much harder. 
  
• Developers should avoid blindly accepting large AI-generated changes and instead work in small, testable increments.
  
• Traditional CS foundations—algorithms, data structures, functions, abstraction, efficiency and reasoning about correctness—still matter because they give developers the knowledge needed to evaluate AI-generated solutions. 
  

Overall: Brilliant's thesis is compelling: AI probably does not eliminate the need to understand programming. Instead, it moves expertise one level higher—from “Can you write this code?” toward “Can you design the right system, instruct AI to build it, understand what it produced, and prove that it works?”

ARTICLE]]>
Brilliant argues that AI is making the mechanical act of writing code increasingly cheap, so the most valuable programming skills are shifting away from simply knowing syntax. The developer’s role increasingly becomes deciding what should be built, how it should be designed, how AI should be directed, and how to determine whether the resulting software is actually correct. Brilliant organizes these abilities around seven areas: Taste, Incrementality, Specification & Design, Build, Verify, Security, and Abstraction. 

A central idea is that developers should work in small, understandable, verifiable increments. AI can generate code much faster than humans can review or understand it, creating what Brilliant calls comprehension debt: software may appear to work while nobody fully understands its assumptions, dependencies, or failure modes. The solution is to build thin end-to-end pieces, test risky assumptions early, use version control, keep changes reversible, and make sure each increment can be explained before moving on. 

The biggest change comes in the traditional development loop of specify → build → verify. As AI performs more of the build stage, Brilliant expects human expertise to concentrate increasingly on specification and verification. Developers need to define observable success criteria, design good data models and interfaces, decompose systems into independent components, understand dependencies and constraints, and then rigorously test AI-generated work. Brilliant therefore portrays the future programmer less as someone who types thousands of lines of code and more as a software architect, problem solver, reviewer, and director of AI systems. 

Key takeaways

• Writing code is becoming less scarce; good judgment is becoming more valuable.
  
• Knowing the problem domain remains essential because AI cannot reliably tell you when its own plausible-looking answer is wrong. 
  
• Specification may become as important as programming: clearly define behavior, constraints, architecture, and tests before asking AI to implement something.
  
• Verification becomes the bottleneck. Generating software is easy; proving that it is correct, secure and maintainable is much harder. 
  
• Developers should avoid blindly accepting large AI-generated changes and instead work in small, testable increments.
  
• Traditional CS foundations—algorithms, data structures, functions, abstraction, efficiency and reasoning about correctness—still matter because they give developers the knowledge needed to evaluate AI-generated solutions. 
  

Overall: Brilliant's thesis is compelling: AI probably does not eliminate the need to understand programming. Instead, it moves expertise one level higher—from “Can you write this code?” toward “Can you design the right system, instruct AI to build it, understand what it produced, and prove that it works?”

ARTICLE]]> https://mklab.gr/showthread.php?tid=1802 Thu, 03 Sep 2026 03:18:08 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1802
David Goldberg’s classic 1991 paper explains why floating-point arithmetic is fundamentally approximate and why programmers cannot safely treat floating-point numbers like exact real numbers. Computers have only a finite number of bits, so many ordinary numbers—most famously decimal $0.1$—cannot be represented exactly in binary. Consequently, arithmetic operations usually require rounding. Goldberg introduces important ways of measuring this error, including relative error, machine epsilon, and ULPs (units in the last place). He also explains catastrophic cancellation, where subtracting two nearly equal quantities can destroy most meaningful digits. Algebraically equivalent formulas can therefore behave very differently numerically; rewriting expressions can dramatically improve accuracy. 

A major part of the paper discusses the IEEE 754 floating-point standard, which was designed to make numerical computation more predictable across computer systems. IEEE arithmetic specifies rounding behavior for basic operations and introduces special values such as $+\infty$, $-\infty$, NaN (Not a Number), $+0$, $-0$, and denormalized/subnormal numbers. These are not merely technical curiosities: infinities allow computations to continue after overflow, NaNs propagate invalid results, signed zero preserves useful mathematical information, and subnormal numbers provide gradual underflow, avoiding an abrupt jump from very small numbers directly to zero. The standard also defines exceptions including overflow, underflow, division by zero, invalid operations, and inexact results. 

Goldberg’s broader message is that reliable numerical computing depends not only on hardware precision but also on algorithms, compilers, programming languages, and system design. Compiler optimizations that are mathematically valid over real numbers may be unsafe for floating-point arithmetic because associativity and other familiar algebraic identities do not always hold after rounding. Even IEEE-compliant computers are not guaranteed to produce identical results in every situation because intermediate precision, decimal conversions, mathematical libraries, and compiler behavior can differ. Programmers therefore need to understand numerical stability rather than assuming that simply using more precision will eliminate floating-point problems. 

Key takeaways

• Floating-point numbers are approximations, not exact real numbers.
  
• Numbers such as $0.1$ generally cannot be represented exactly in binary.
  
• Rounding errors are normally tiny, but algorithms can amplify them dramatically.
  
• Subtracting nearly equal calculated quantities can cause catastrophic cancellation.
  
• Numerically stable reformulations of formulas are often more important than simply increasing precision.
  
• IEEE 754 provides standardized rounding plus special values such as NaN, $\pm\infty$, $\pm0$, and subnormal numbers.
  
• Floating-point arithmetic does not always obey ordinary algebraic rules; for example, $(a+b)+c$ need not equal $a+(b+c)$.
  
• Reliable scientific software requires cooperation between algorithms, hardware, compilers, and programming languages.
  

Overall: Goldberg's central lesson is that floating-point arithmetic is not defective arithmetic—it is a carefully designed approximation system. Problems arise mainly when programmers assume it behaves exactly like mathematics over the real numbers. The paper remains one of the foundational introductions to numerical computing and IEEE floating-point arithmetic. 

ARTICLE]]>
David Goldberg’s classic 1991 paper explains why floating-point arithmetic is fundamentally approximate and why programmers cannot safely treat floating-point numbers like exact real numbers. Computers have only a finite number of bits, so many ordinary numbers—most famously decimal $0.1$—cannot be represented exactly in binary. Consequently, arithmetic operations usually require rounding. Goldberg introduces important ways of measuring this error, including relative error, machine epsilon, and ULPs (units in the last place). He also explains catastrophic cancellation, where subtracting two nearly equal quantities can destroy most meaningful digits. Algebraically equivalent formulas can therefore behave very differently numerically; rewriting expressions can dramatically improve accuracy. 

A major part of the paper discusses the IEEE 754 floating-point standard, which was designed to make numerical computation more predictable across computer systems. IEEE arithmetic specifies rounding behavior for basic operations and introduces special values such as $+\infty$, $-\infty$, NaN (Not a Number), $+0$, $-0$, and denormalized/subnormal numbers. These are not merely technical curiosities: infinities allow computations to continue after overflow, NaNs propagate invalid results, signed zero preserves useful mathematical information, and subnormal numbers provide gradual underflow, avoiding an abrupt jump from very small numbers directly to zero. The standard also defines exceptions including overflow, underflow, division by zero, invalid operations, and inexact results. 

Goldberg’s broader message is that reliable numerical computing depends not only on hardware precision but also on algorithms, compilers, programming languages, and system design. Compiler optimizations that are mathematically valid over real numbers may be unsafe for floating-point arithmetic because associativity and other familiar algebraic identities do not always hold after rounding. Even IEEE-compliant computers are not guaranteed to produce identical results in every situation because intermediate precision, decimal conversions, mathematical libraries, and compiler behavior can differ. Programmers therefore need to understand numerical stability rather than assuming that simply using more precision will eliminate floating-point problems. 

Key takeaways

• Floating-point numbers are approximations, not exact real numbers.
  
• Numbers such as $0.1$ generally cannot be represented exactly in binary.
  
• Rounding errors are normally tiny, but algorithms can amplify them dramatically.
  
• Subtracting nearly equal calculated quantities can cause catastrophic cancellation.
  
• Numerically stable reformulations of formulas are often more important than simply increasing precision.
  
• IEEE 754 provides standardized rounding plus special values such as NaN, $\pm\infty$, $\pm0$, and subnormal numbers.
  
• Floating-point arithmetic does not always obey ordinary algebraic rules; for example, $(a+b)+c$ need not equal $a+(b+c)$.
  
• Reliable scientific software requires cooperation between algorithms, hardware, compilers, and programming languages.
  

Overall: Goldberg's central lesson is that floating-point arithmetic is not defective arithmetic—it is a carefully designed approximation system. Problems arise mainly when programmers assume it behaves exactly like mathematics over the real numbers. The paper remains one of the foundational introductions to numerical computing and IEEE floating-point arithmetic. 

ARTICLE]]> https://mklab.gr/showthread.php?tid=1791 Thu, 03 Sep 2026 01:41:00 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1791 Author: Gergely Orosz — The Pragmatic Engineer
Published: January 6, 2026

Gergely Orosz argues that software engineering may have reached an important turning point: the newest generation of coding models can now generate a very large proportion of production code with surprisingly little human intervention. He points particularly to Claude Opus 4.5, GPT-5.2 and Gemini 3, released in late 2025, and cites experienced engineers who report that AI agents can complete substantial tasks, create pull requests, write tests, refactor code and sometimes produce entire implementations from relatively high-level instructions. Orosz says that in his own work, AI can already generate roughly 90% of the code he would otherwise write himself, especially for greenfield applications using mainstream technologies. 

This does not necessarily mean software engineers become unnecessary. Instead, the value of different engineering skills changes. Routine implementation, prototyping, knowing the precise syntax of several programming languages, and narrow frontend/backend specialization may become less valuable because an AI agent can perform much of this work. What becomes more important is understanding architecture, defining the correct problem, evaluating trade-offs, testing and validating systems, debugging difficult failures, understanding product requirements and deciding what should actually be built. In other words, the valuable engineer increasingly resembles a technical lead or product-minded engineer supervising AI, rather than someone whose primary skill is manually producing code. 

There are significant downsides. If generating code becomes extremely cheap, organizations may generate far more software and therefore far more potential bugs, security problems and technical debt. Weak testing, poor observability and bad architectural decisions could become painful much faster because AI amplifies the speed at which code is created. At the same time, the boundaries between product management and software engineering may blur: product managers can increasingly prototype software themselves, while engineers equipped with AI can take more responsibility for deciding product direction. Orosz therefore sees AI less as the end of software engineering than as a shift from writing code to making good engineering decisions at much greater scale. 

Key takeaways

• AI-generated code may become the norm: for some developers and greenfield projects, 90%+ AI-generated code is already plausible. 
  
• Coding syntax becomes less important; engineering judgment becomes more important.
  
• Architecture, testing, product thinking and technical leadership gain value, while narrow language or framework specialization may lose some value.
  
• AI will not eliminate engineering problems—it may multiply them, making strong engineering practices even more necessary. 
  

Central idea:When producing code becomes cheap, the scarce resource is no longer code itself—it is knowing what to build, how to design it, and whether the AI-generated system can actually be trusted.

ARTICLE]]> Author: Gergely Orosz — The Pragmatic Engineer
Published: January 6, 2026

Gergely Orosz argues that software engineering may have reached an important turning point: the newest generation of coding models can now generate a very large proportion of production code with surprisingly little human intervention. He points particularly to Claude Opus 4.5, GPT-5.2 and Gemini 3, released in late 2025, and cites experienced engineers who report that AI agents can complete substantial tasks, create pull requests, write tests, refactor code and sometimes produce entire implementations from relatively high-level instructions. Orosz says that in his own work, AI can already generate roughly 90% of the code he would otherwise write himself, especially for greenfield applications using mainstream technologies. 

This does not necessarily mean software engineers become unnecessary. Instead, the value of different engineering skills changes. Routine implementation, prototyping, knowing the precise syntax of several programming languages, and narrow frontend/backend specialization may become less valuable because an AI agent can perform much of this work. What becomes more important is understanding architecture, defining the correct problem, evaluating trade-offs, testing and validating systems, debugging difficult failures, understanding product requirements and deciding what should actually be built. In other words, the valuable engineer increasingly resembles a technical lead or product-minded engineer supervising AI, rather than someone whose primary skill is manually producing code. 

There are significant downsides. If generating code becomes extremely cheap, organizations may generate far more software and therefore far more potential bugs, security problems and technical debt. Weak testing, poor observability and bad architectural decisions could become painful much faster because AI amplifies the speed at which code is created. At the same time, the boundaries between product management and software engineering may blur: product managers can increasingly prototype software themselves, while engineers equipped with AI can take more responsibility for deciding product direction. Orosz therefore sees AI less as the end of software engineering than as a shift from writing code to making good engineering decisions at much greater scale. 

Key takeaways

• AI-generated code may become the norm: for some developers and greenfield projects, 90%+ AI-generated code is already plausible. 
  
• Coding syntax becomes less important; engineering judgment becomes more important.
  
• Architecture, testing, product thinking and technical leadership gain value, while narrow language or framework specialization may lose some value.
  
• AI will not eliminate engineering problems—it may multiply them, making strong engineering practices even more necessary. 
  

Central idea:When producing code becomes cheap, the scarce resource is no longer code itself—it is knowing what to build, how to design it, and whether the AI-generated system can actually be trusted.

ARTICLE]]> https://mklab.gr/showthread.php?tid=1789 Thu, 03 Sep 2026 01:04:03 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1789 Author: Lance Fortnow
Published: September 2, 2026
Topic: Theoretical computer science / foundations of computation

Lance Fortnow argues that computer science really is about computers—but only if we use a much broader definition of “computer.” Responding to a Quanta essay asking whether computer science needs computers, he challenges the famous saying attributed to Edsger Dijkstra that “computer science is no more about computers than astronomy is about telescopes.” Fortnow suggests that this analogy is backwards: computers are not merely the telescopes of computer science; they are more like its stars, the actual objects being studied. Historically, the word computer originally referred to a person who performed calculations, long before it came to mean an electronic machine. 

For Fortnow, a computer is essentially any system or process that performs computation, regardless of whether it is electronic, mechanical, biological, social, or even human. A postal service routing a letter, an auction determining a price, or a person carrying out a mathematical procedure can all be viewed computationally. The Church–Turing thesis provides the theoretical foundation: any effectively computable process can, in principle, be represented by a Turing machine. Fortnow therefore argues that theoretical computer science must keep some notion of computation or process at its center; otherwise it simply becomes mathematics. Electronic computers are not strictly necessary for computer science, but computation itself is indispensable. 

Key takeaways

• A computer is broader than a digital machine: it can be any system carrying out a computational process.
  
• The central subject of computer science is therefore computation, not necessarily physical computers.
  
• The Church–Turing thesis connects these diverse computational processes to the abstract Turing-machine model.
  
• Fortnow draws a useful boundary: theoretical work that completely removes computation from the picture may be mathematics, but not necessarily computer science. 
  

ARTICLE]]> Author: Lance Fortnow
Published: September 2, 2026
Topic: Theoretical computer science / foundations of computation

Lance Fortnow argues that computer science really is about computers—but only if we use a much broader definition of “computer.” Responding to a Quanta essay asking whether computer science needs computers, he challenges the famous saying attributed to Edsger Dijkstra that “computer science is no more about computers than astronomy is about telescopes.” Fortnow suggests that this analogy is backwards: computers are not merely the telescopes of computer science; they are more like its stars, the actual objects being studied. Historically, the word computer originally referred to a person who performed calculations, long before it came to mean an electronic machine. 

For Fortnow, a computer is essentially any system or process that performs computation, regardless of whether it is electronic, mechanical, biological, social, or even human. A postal service routing a letter, an auction determining a price, or a person carrying out a mathematical procedure can all be viewed computationally. The Church–Turing thesis provides the theoretical foundation: any effectively computable process can, in principle, be represented by a Turing machine. Fortnow therefore argues that theoretical computer science must keep some notion of computation or process at its center; otherwise it simply becomes mathematics. Electronic computers are not strictly necessary for computer science, but computation itself is indispensable. 

Key takeaways

• A computer is broader than a digital machine: it can be any system carrying out a computational process.
  
• The central subject of computer science is therefore computation, not necessarily physical computers.
  
• The Church–Turing thesis connects these diverse computational processes to the abstract Turing-machine model.
  
• Fortnow draws a useful boundary: theoretical work that completely removes computation from the picture may be mathematics, but not necessarily computer science. 
  

ARTICLE]]> https://mklab.gr/showthread.php?tid=1735 Fri, 28 Aug 2026 16:57:34 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1735 Author: Ben Brubaker
Publication:Quanta Magazine
Date: August 28, 2026 (Quanta Magazine)

The article examines the provocative claim often associated with Edsger Dijkstra that “computer science is no more about computers than astronomy is about telescopes.” Theoretical computer science certainly supports this view: many of its central questions concern abstract ideas such as algorithms, computability and computational complexity rather than physical machines. Alan Turing’s 1930s work, for example, developed the mathematical concept of the Turing machine before modern general-purpose electronic computers existed. Turing was originally trying to understand the limits of mathematical calculation, not design hardware. This theoretical tradition leads to two fundamental questions: What can be computed? and How can it be computed efficiently? 

The second question gave rise to computational complexity theory, which studies why some problems admit fast algorithms while others seem inherently difficult. The crucial distinction is not simply whether a faster computer can solve a problem, but whether the mathematical structure of the problem allows an efficient algorithm at all. This perspective has produced ideas that reach far beyond conventional computing, including interactive proofs and zero-knowledge proofs, where someone can demonstrate that a statement is true without revealing the underlying information. Computational thinking has also become a way of studying physics, biology, evolution and even questions in quantum gravity.

Yet Brubaker ultimately argues that Dijkstra’s slogan is only partly correct. Although theoretical computer science can exist mathematically without physical computers, many of its deepest questions arose precisely because people were building and experimenting with real machines. Complexity theory became compelling when researchers confronted practical computational limitations during the 1960s. The relationship therefore runs both ways: theory creates technology, but technology also reveals questions that pure theorists might never have thought to ask. The better version of the telescope analogy may therefore be that astronomy is not about telescopes, but without telescopes much of astronomy would never have existed. As Ryan Williams summarizes the underlying idea, interesting practical problems often generate profound theoretical questions.

Key takeaways

• Computer science is broader than programming or computers: at its theoretical core it studies computation, algorithms and the limits of efficient problem solving.
  
• Turing machines show that computation is fundamentally a mathematical concept, independent of any particular hardware.
  
• Complexity theory asks why some problems are intrinsically harder than others, not merely whether we have sufficiently powerful computers.
  
• Physical computers nevertheless matter enormously: experimentation with real machines has repeatedly inspired entirely new theoretical questions.
  
• The article’s deeper message is that science and technology develop together. Pure theory can generate new technologies, while practical inventions can reveal previously invisible mathematical structures.
  

Central idea: Computer science may not fundamentally be about computers, but without computers, much of modern computer science might never have been discovered.


ARTICLE [PDF] / ARTICLE]]> Author: Ben Brubaker
Publication:Quanta Magazine
Date: August 28, 2026 (Quanta Magazine)

The article examines the provocative claim often associated with Edsger Dijkstra that “computer science is no more about computers than astronomy is about telescopes.” Theoretical computer science certainly supports this view: many of its central questions concern abstract ideas such as algorithms, computability and computational complexity rather than physical machines. Alan Turing’s 1930s work, for example, developed the mathematical concept of the Turing machine before modern general-purpose electronic computers existed. Turing was originally trying to understand the limits of mathematical calculation, not design hardware. This theoretical tradition leads to two fundamental questions: What can be computed? and How can it be computed efficiently? 

The second question gave rise to computational complexity theory, which studies why some problems admit fast algorithms while others seem inherently difficult. The crucial distinction is not simply whether a faster computer can solve a problem, but whether the mathematical structure of the problem allows an efficient algorithm at all. This perspective has produced ideas that reach far beyond conventional computing, including interactive proofs and zero-knowledge proofs, where someone can demonstrate that a statement is true without revealing the underlying information. Computational thinking has also become a way of studying physics, biology, evolution and even questions in quantum gravity.

Yet Brubaker ultimately argues that Dijkstra’s slogan is only partly correct. Although theoretical computer science can exist mathematically without physical computers, many of its deepest questions arose precisely because people were building and experimenting with real machines. Complexity theory became compelling when researchers confronted practical computational limitations during the 1960s. The relationship therefore runs both ways: theory creates technology, but technology also reveals questions that pure theorists might never have thought to ask. The better version of the telescope analogy may therefore be that astronomy is not about telescopes, but without telescopes much of astronomy would never have existed. As Ryan Williams summarizes the underlying idea, interesting practical problems often generate profound theoretical questions.

Key takeaways

• Computer science is broader than programming or computers: at its theoretical core it studies computation, algorithms and the limits of efficient problem solving.
  
• Turing machines show that computation is fundamentally a mathematical concept, independent of any particular hardware.
  
• Complexity theory asks why some problems are intrinsically harder than others, not merely whether we have sufficiently powerful computers.
  
• Physical computers nevertheless matter enormously: experimentation with real machines has repeatedly inspired entirely new theoretical questions.
  
• The article’s deeper message is that science and technology develop together. Pure theory can generate new technologies, while practical inventions can reveal previously invisible mathematical structures.
  

Central idea: Computer science may not fundamentally be about computers, but without computers, much of modern computer science might never have been discovered.


ARTICLE [PDF] / ARTICLE]]> https://mklab.gr/showthread.php?tid=1430 Thu, 30 Jul 2026 02:36:40 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1430 Why software projects take longer

Summary

In his post, Erik Bernhardsson argues that software project delays are a statistical artifact caused by humans estimating the median time a task will take—where half of outcomes are faster and half are slower—rather than the mean (expected average time). Because software completion times follow a right-skewed, log-normal distribution—where tasks are strictly bounded at zero on the fast side but virtually unbounded on the slow side—a single task experiencing unforeseen complications can blow up by a massive factor and heavily drag down the entire timeline. 

Since overall project schedules depend on adding up means rather than medians, high-uncertainty tasks quietly dominate project deadlines, making simple additive estimates consistently over-optimistic when planning complex software roadmaps.

ARTICLE]]> Why software projects take longer

Summary

In his post, Erik Bernhardsson argues that software project delays are a statistical artifact caused by humans estimating the median time a task will take—where half of outcomes are faster and half are slower—rather than the mean (expected average time). Because software completion times follow a right-skewed, log-normal distribution—where tasks are strictly bounded at zero on the fast side but virtually unbounded on the slow side—a single task experiencing unforeseen complications can blow up by a massive factor and heavily drag down the entire timeline. 

Since overall project schedules depend on adding up means rather than medians, high-uncertainty tasks quietly dominate project deadlines, making simple additive estimates consistently over-optimistic when planning complex software roadmaps.

ARTICLE]]> https://mklab.gr/showthread.php?tid=1415 Thu, 30 Jul 2026 00:25:38 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1415 Quantum computing

Summary

The article explains how quantum computing leverages subatomic phenomena—specifically superposition (where qubits hold multiple states simultaneously) and entanglement (where paired particles influence each other instantly)—to offer exponential leaps in processing power over traditional binary systems. By shifting away from classical physics, quantum computers promise to solve previously intractable problems in fields like optimization and cryptography, where they could simultaneously revolutionize post-quantum security and break traditional encryption algorithms. 

However, practical deployment faces steep engineering obstacles: qubits are highly sensitive to environmental noise, heat, and interference—a vulnerability known as quantum decoherence—requiring ultracold operating conditions and many noisy physical qubits combined to produce single, reliable "logical" qubits.

ARTICLE]]> Quantum computing

Summary

The article explains how quantum computing leverages subatomic phenomena—specifically superposition (where qubits hold multiple states simultaneously) and entanglement (where paired particles influence each other instantly)—to offer exponential leaps in processing power over traditional binary systems. By shifting away from classical physics, quantum computers promise to solve previously intractable problems in fields like optimization and cryptography, where they could simultaneously revolutionize post-quantum security and break traditional encryption algorithms. 

However, practical deployment faces steep engineering obstacles: qubits are highly sensitive to environmental noise, heat, and interference—a vulnerability known as quantum decoherence—requiring ultracold operating conditions and many noisy physical qubits combined to produce single, reliable "logical" qubits.

ARTICLE]]> https://mklab.gr/showthread.php?tid=1161 Thu, 16 Jul 2026 20:06:27 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1161 The New Software Lifecycle


Summary

In “The New Software Lifecycle,” Addy Osmani argues that AI is fundamentally changing how software is built, shifting developers away from writing every line of code and toward designing, guiding, and verifying AI-generated work. Rather than focusing only on smarter AI models, the article emphasizes the importance of the “harness”—the surrounding instructions, tools, workflows, and safeguards that determine an agent’s effectiveness. As AI accelerates coding, the biggest challenges move to defining clear requirements, making sound architectural decisions, and rigorously testing the results. 

Developers increasingly act as reviewers and orchestrators, ensuring that AI-generated code is reliable, secure, and aligned with project goals. The article also highlights that successful AI-assisted development depends on strong evaluation processes, efficient context management, and thoughtful cost control, since poor organization can quickly become expensive. While AI dramatically speeds up implementation and maintenance, it still struggles with complex edge cases that require human judgment. Ultimately, Osmani concludes that the future of software engineering is not about replacing developers, but about evolving their role into one centered on specification, validation, and intelligent collaboration with AI systems. 


ARTICLE]]> The New Software Lifecycle


Summary

In “The New Software Lifecycle,” Addy Osmani argues that AI is fundamentally changing how software is built, shifting developers away from writing every line of code and toward designing, guiding, and verifying AI-generated work. Rather than focusing only on smarter AI models, the article emphasizes the importance of the “harness”—the surrounding instructions, tools, workflows, and safeguards that determine an agent’s effectiveness. As AI accelerates coding, the biggest challenges move to defining clear requirements, making sound architectural decisions, and rigorously testing the results. 

Developers increasingly act as reviewers and orchestrators, ensuring that AI-generated code is reliable, secure, and aligned with project goals. The article also highlights that successful AI-assisted development depends on strong evaluation processes, efficient context management, and thoughtful cost control, since poor organization can quickly become expensive. While AI dramatically speeds up implementation and maintenance, it still struggles with complex edge cases that require human judgment. Ultimately, Osmani concludes that the future of software engineering is not about replacing developers, but about evolving their role into one centered on specification, validation, and intelligent collaboration with AI systems. 


ARTICLE]]> https://mklab.gr/showthread.php?tid=1093 Mon, 13 Jul 2026 04:08:32 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1093 Levenshtein distance

Summary

The Levenshtein distance is a mathematical measure used to determine how different two strings of text are by counting the minimum number of single-character changes needed to transform one into the other. These changes can include inserting a character, deleting a character, or replacing one character with another. Introduced by Vladimir Levenshtein in 1965, the concept has become fundamental in computer science, especially in areas such as spell checking, search engines, DNA analysis, and natural language processing.

The distance is calculated using a dynamic programming approach that compares smaller parts of the strings and builds a solution step by step. A distance of zero means the strings are identical, while larger values indicate greater differences. For example, changing the word “kitten” into “sitting” requires three edits, so their Levenshtein distance is 3. 

The simplicity and flexibility of this method make it one of the most widely used techniques for measuring similarity between sequences of characters. It remains an important tool for improving how computers understand and process human language.


ARTICLE]]> Levenshtein distance

Summary

The Levenshtein distance is a mathematical measure used to determine how different two strings of text are by counting the minimum number of single-character changes needed to transform one into the other. These changes can include inserting a character, deleting a character, or replacing one character with another. Introduced by Vladimir Levenshtein in 1965, the concept has become fundamental in computer science, especially in areas such as spell checking, search engines, DNA analysis, and natural language processing.

The distance is calculated using a dynamic programming approach that compares smaller parts of the strings and builds a solution step by step. A distance of zero means the strings are identical, while larger values indicate greater differences. For example, changing the word “kitten” into “sitting” requires three edits, so their Levenshtein distance is 3. 

The simplicity and flexibility of this method make it one of the most widely used techniques for measuring similarity between sequences of characters. It remains an important tool for improving how computers understand and process human language.


ARTICLE]]> https://mklab.gr/showthread.php?tid=1026 Fri, 10 Jul 2026 21:08:17 +0300 mklabgr]]> https://mklab.gr/showthread.php?tid=1026 Turing machine

Summary

Conceived by British mathematician Alan Turing in 1936, the Turing machine serves as a foundational mathematical model of computation that defines the limits of what a machine can mechanically calculate. Rather than a physical device, this abstract concept represents a computer reduced to its most essential components: an infinitely long memory tape divided into discrete cells, a movable scanning head capable of reading and writing symbols, a state register, and a finite table of instructions. 

As the machine processes symbols according to predetermined rules, it transitions between states and shifts along the tape, demonstrating how complex logical processes can be broken down into elementary mechanical steps. This elegant simplicity belies its extraordinary power, as the model is capable of simulating the logic of any computer algorithm.

The true brilliance of this concept emerged with the formulation of the universal Turing machine, a variation that can read the instructions of any other specialized Turing machine from the tape and simulate its behavior. This revolutionary insight laid the theoretical groundwork for the modern stored-program computer, proving that a single piece of hardware could execute an endless variety of programs. 

Intertwined with Alonzo Church’s lambda calculus, this framework established the Church-Turing thesis, which posits that anything effectively computable by an algorithm can be computed by a Turing machine. By establishing a rigorous definition for algorithms and exposing inherent limitations like the undecidable halting problem, this framework continues to shape contemporary computer science, complexity theory, and our fundamental understanding of what technology can and cannot solve.

ARTICLE

[Video]

How Turing Machines Work 

This video provides a clear, physical explanation of how Alan Turing conceived the machine and the mechanics behind why it successfully models universal computation.

]]> Turing machine

Summary

Conceived by British mathematician Alan Turing in 1936, the Turing machine serves as a foundational mathematical model of computation that defines the limits of what a machine can mechanically calculate. Rather than a physical device, this abstract concept represents a computer reduced to its most essential components: an infinitely long memory tape divided into discrete cells, a movable scanning head capable of reading and writing symbols, a state register, and a finite table of instructions. 

As the machine processes symbols according to predetermined rules, it transitions between states and shifts along the tape, demonstrating how complex logical processes can be broken down into elementary mechanical steps. This elegant simplicity belies its extraordinary power, as the model is capable of simulating the logic of any computer algorithm.

The true brilliance of this concept emerged with the formulation of the universal Turing machine, a variation that can read the instructions of any other specialized Turing machine from the tape and simulate its behavior. This revolutionary insight laid the theoretical groundwork for the modern stored-program computer, proving that a single piece of hardware could execute an endless variety of programs. 

Intertwined with Alonzo Church’s lambda calculus, this framework established the Church-Turing thesis, which posits that anything effectively computable by an algorithm can be computed by a Turing machine. By establishing a rigorous definition for algorithms and exposing inherent limitations like the undecidable halting problem, this framework continues to shape contemporary computer science, complexity theory, and our fundamental understanding of what technology can and cannot solve.

ARTICLE

[Video]

How Turing Machines Work 

This video provides a clear, physical explanation of how Alan Turing conceived the machine and the mechanics behind why it successfully models universal computation.

]]>