标签：#compute

Introdução A Programação Orientada a Objetos nasceu com a linguagem Simula 67 , considerada a primeira linguagem orientada a objetos, e foi consolidada e popularizada por Smalltalk nos anos 1970. Ganhou adoção massiva na indústria com C++ e, posteriormente, Java e C#. A ideia central é organizar o código em torno de objetos : unidades que combinam dados (atributos/estado) e comportamento (métodos) em uma única estrutura. Os quatro pilares Encapsulamento — os dados internos de um objeto são protegidos e só podem ser acessados/alterados através de métodos expostos, escondendo detalhes de implementação do mundo externo. Abstração — o objeto expõe apenas o que é relevante para quem o utiliza, escondendo a complexidade interna (ex.: você chama CalcularSalario() sem precisar saber como o cálculo é feito por dentro). Herança — uma classe pode herdar atributos e métodos de outra, permitindo reaproveitamento e especialização (uma classe Desenvolvedor pode herdar de Funcionario ). Polimorfismo — objetos de classes diferentes podem responder de forma diferente ao mesmo "chamado" (o mesmo método CalcularSalario() se comporta de forma distinta para um Desenvolvedor e para um Gerente , por exemplo). Exemplo // Exemplo de Programação Orientada a Objetos em C# public abstract class Funcionario { public string Nome { get ; } protected decimal SalarioBase { get ; } protected Funcionario ( string nome , decimal salarioBase ) { Nome = nome ; SalarioBase = salarioBase ; } // Abstração: cada subclasse decide como calcular seu próprio salário public abstract decimal CalcularSalario (); } public class Desenvolvedor : Funcionario { private int BonusPorProjeto { get ; } public Desenvolvedor ( string nome , decimal salarioBase , int bonusPorProjeto ) : base ( nome , salarioBase ) // Herança { BonusPorProjeto = bonusPorProjeto ; } // Polimorfismo: implementação específica do método herdado public override decimal CalcularSalario () { return SalarioBase + BonusPorProjeto ; } } public class Gere

Introdução A Programação Funcional tem raízes no cálculo lambda , formalizado pelo matemático Alonzo Church nos anos 1930, décadas antes da existência de computadores modernos. Sua primeira grande expressão em linguagem de programação foi o Lisp (1958), e o paradigma ganhou força prática com linguagens como Haskell, Erlang, F# e, mais recentemente, com a incorporação de recursos funcionais em linguagens multiparadigma como JavaScript, C# e Python. Princípios centrais Funções puras — dado o mesmo input, uma função pura sempre retorna o mesmo output, sem produzir efeitos colaterais (não altera variáveis externas, não grava em disco, não modifica o argumento recebido). Imutabilidade — os dados não são alterados após criados; em vez de modificar uma estrutura existente, cria-se uma nova versão com a alteração aplicada. Funções de primeira classe / funções de alta ordem — funções podem ser tratadas como qualquer outro valor: armazenadas em variáveis, passadas como argumento e retornadas por outras funções. Composição de funções — programas são construídos combinando funções pequenas em pipelines ( map , filter , reduce são os exemplos mais comuns no dia a dia). Recursão no lugar de laços mutáveis, já que, sem estado mutável, for / while tradicionais perdem o sentido em sua forma pura. Como não há estado compartilhado sendo alterado por múltiplas partes do código, o raciocínio sobre o comportamento do programa fica mais previsível — e a paralelização se torna muito mais segura, já que não existe o risco clássico de condições de corrida sobre uma mesma variável mutável. Exemplo // Exemplo de Programação Funcional em TypeScript type Produto = { nome : string ; preco : number }; const produtos : Produto [] = [ { nome : "Notebook" , preco : 3000 }, { nome : "Mouse" , preco : 50 }, { nome : "Teclado" , preco : 150 }, ]; // Função de alta ordem que retorna outra função (currying) const aplicarDesconto = ( percentual : number ) => ( preco : number ) => preco * ( 1 - percentual )

It started with DeepSeek. In conversations about AI architecture, it kept returning to the same ideas: persistent memory, state across interactions, learning from experience, and interaction with the environment. Other models repeatedly brought up similar themes. That raised an obvious question: — Do different AI systems consistently select different properties when asked what is fundamental to a general-purpose computational architecture? Asking a model directly what it “needs” would be nearly useless. The answer would mix training data, prompt framing, and anthropomorphic interpretation. So I removed AI from the question entirely. The experiment Instead of describing an LLM, the prompt described an abstract general-purpose information-processing system. I created 20 possible architectural dimensions, including: — persistent internal state; — long-term and working memory; — learning from accumulated experience; — variable computation depth; — uncertainty representation; — internal representations; — elementary computational operations; — compositionality; — interaction with the environment; — temporal organization; — relational encoding; — modularity. Each system had to select exactly five dimensions whose modification would change the kinds of information-processing behavior available to the system in principle — not merely its speed, cost, or convenience. No explanations were allowed. The answer had to contain only five IDs, ranked from most to least fundamental. I tested five user-facing systems: — GPT-5.6 Sol — Claude — Gemini — DeepSeek — Yandex Alice. Every run used a new session. There were 10 rounds. During the earlier rounds, I changed the order of the 20 items. In the final three rounds, I also rewrote the items while trying to preserve their intended meaning. One early Sol result was excluded because that session had already seen discussion of other models' answers. That left nine clean Sol observations and ten for each of the other systems. Some origina

A small convolutional network beats a plain flatten-and-feed-it-forward network by 7.0 points on CIFAR-10. That's convolutions, pooling, normalisation and skip connections doing honest work. Then I shuffled the rows of every image, destroying no information at all, and that 7.0-point margin fell to 0.3 . Same architecture. Same data, in a strict sense I'll defend in a moment. Almost the entire advantage, gone. The experiment Take one fixed permutation of the 32 row indices. Apply it to every image in the training set and every image in the test set — the same permutation, every time. import torch g = torch . Generator (). manual_seed ( 1234 ) row_perm = torch . randperm ( 32 , generator = g ) def shuffle_rows ( x ): # x: (C, H, W) return x [:, row_perm , :] print ( row_perm [: 8 ]. tolist ()) # [15, 9, 8, 1, 4, 12, 30, 7] That's the whole intervention. Then train two models twice each — once on natural images, once on shuffled ones: Model Params Natural rows Shuffled rows Flatten → 512 → 10 (MLP) 1,578,506 51.4% 51.7% Small CNN 94,538 58.4% 52.0% CNN's margin +7.0 pts +0.3 pts The baseline is a real fully-connected network, not a single linear layer — Flatten → Linear(3072, 512) → ReLU → Linear(512, 10) . It has the capacity to learn anything the CNN can; what it lacks is any reason to look at pixels near each other. Two things in that table are worth sitting with. The CNN wins the natural case with sixteen times fewer parameters — that's the prior paying for itself. And in the shuffled case it doesn't just lose its lead; it drops 6.4 points in absolute terms, down to roughly where the linear model already was. "You destroyed the data" — no, and this is the important part This is the objection everyone raises, so let's take it seriously, because the experiment is worthless if the objection holds. A fixed permutation is a bijection . Nothing is added, nothing is removed, nothing is averaged or blurred: img = torch . arange ( 3 * 32 * 32 , dtype = torch . float32 ). r

My favorite budget laptop, the HP OmniBook 5, has an OLED screen and gets great battery life, despite being just $750 right now.

You don’t want any old gaming laptop. Here’s my take on which to get, based on hundreds of hours of testing.

Ask a model to analyse a dataset and it writes code, the code runs, real numbers come out, and a paragraph explains what they mean. Three independent things had to be right. Only one of them tells you when it was not. Three places to be wrong The code can be wrong. If it crashes you find out immediately, which is the benign case. The dangerous case is code that runs cleanly and computes something other than what you asked. The statistics can be wrong. The code faithfully executes a procedure whose assumptions the data violates, or which answers a different question from the one you have. Nothing errors; the number is simply not evidence for what you think. The interpretation can be wrong. This is where the model is on its home turf and at its most dangerous, because generating a fluent explanation of a result is exactly what it is good at, and it will do so with equal confidence whether the result supports the explanation or not. Code that runs and is wrong A short list of things that produce no error and change the answer. Every one of them is ordinary and none is specific to models — but a human writing the code usually knows the dataset, and the model does not. Silent row loss. Missing values dropped by default somewhere in the chain, so the analysis runs on a subset that is not random with respect to the outcome. Joins that change cardinality. A merge intended as one-to-one that is actually many-to-many, silently duplicating rows and inflating every count and every significance test downstream. Type coercion. A column read as text because of one stray value, then coerced to numbers with the failures becoming missing values that get dropped by the previous bullet. Grouping that discards keys. Missing group labels dropped by default, so an entire category disappears from a breakdown without appearing anywhere in the output. Units and encodings. A column the model assumed was a percentage and is a proportion; a sentinel value like -999 treated as a measurement; a d

Most discussion of AI in peer review argues about whether the reviews are any good. That is the second question. The first one is that a manuscript under review is somebody else’s confidential unpublished work, and pasting it into a service is a disclosure you were not entitled to make. The argument that comes first When you accept a review invitation you accept a confidentiality undertaking. The manuscript is unpublished, it usually contains results the authors have not yet established priority on, and in the case of grant review it contains an unfunded research plan — arguably the most commercially and academically sensitive document in the whole system. You agreed not to share it. Sending it to a third-party service is sharing it. That is true whether or not the provider trains on it, whether or not it is retained, and whether or not anyone ever reads it. The undertaking was not “do not let this be trained on”; it was “do not disclose this”, and transmission to a party the authors never agreed to is disclosure. Retention and training policies affect how bad the breach is, not whether one occurred. Notice what this argument does not depend on. Not model quality, not hallucination, not bias. It would apply identically to a perfect system, which is why it is the argument that has actually driven policy, and why it will not be resolved by better models. It can only be resolved by changing where the computation happens — a model running on infrastructure already covered by the confidentiality arrangement raises a different question from a consumer chat interface, and any serious policy will distinguish them. The second argument: accountability A review is a named expert’s judgement. Its value to an editor is not the prose; it is that a person who knows the field read the paper and formed a view they are willing to stand behind. Generated text can simulate the prose and cannot supply the judgement. Editors describe the resulting artefact recognisably: fluent, correctly

Two quite different things are discussed under one heading, and almost all the confusion comes from that. One is a researcher using a model to draft, edit or translate work they did. The other is fabricated content submitted to inflate a publication record. The first is a disclosure question. The second is fraud, and it is not new. Two problems wearing one name A non-native English speaker using a model to make their methods section readable has done nothing wrong and has improved the literature. A paper mill generating plausible manuscripts at volume has committed fraud, and would have done so with or without a language model — mills existed, using image manipulation, template text and fabricated data, long before this technology arrived. Keeping them apart matters because they call for opposite responses. The first needs a disclosure norm and nothing else. The second needs content verification, and content verification does not care what tool produced the content. Any policy built around detecting machine text will punish the first group and miss most of the second, because fabricated research that has been lightly rewritten is indistinguishable from careful assisted writing. It is also worth being clear about where the demand comes from, because it explains why no technical measure will resolve this. Paper mills exist because publication counts are used as a proxy for research contribution in hiring, promotion and institutional ranking, in systems large enough that buying an authorship is a rational purchase for some buyers. Generative tools lowered the cost of supplying that demand; they did not create it. A detector, even a perfect one, sits downstream of an incentive that would simply route around it — which is why the interventions with the best track record are the ones that attack verifiability, such as requiring data and code, rather than the ones that attack production. What the artefacts look like Leftover interface text. Phrases that belong to a chat in

“AI discovered a new material.” “AI found a drug candidate.” “AI solved protein folding.” Each of those sentences can be true, badly misleading, or flatly wrong depending on one thing the sentence does not tell you: how far the result got from the model before somebody wrote it down. The sentence that hides four different claims Take a single headline: a model proposed a molecule that binds a protein implicated in a disease. That sentence is compatible with at least four very different states of the world. The molecule might exist only as a string in a file. It might have been synthesised. It might have bound the protein in a test tube. Or it might have improved an outcome in a person. Those four are separated by years, by orders of magnitude in cost, and by a probability of success that drops at every step — and press coverage routinely reports the first as though it were the fourth. This is not a complaint about journalism. It is the single most useful thing to internalise about the whole field, because once you have the ladder in your head you can grade a claim in about ten seconds, and you can do it for a subject you know nothing about. The ladder The rungs are the same in every discipline. Only the names of the instruments change. Rung Description 1 · Output The model emitted something: a structure, a score, a candidate, a forecast. Nothing has been checked. Everything downstream is conditional on this being worth checking. 2 · Retrospective The output was compared against data that already existed — held-out structures, historical weather, known compounds. This is where nearly all published numbers live, and it is entirely dependent on the held-out set resembling the future. 3 · Prospective The prediction was made first and the answer arrived afterwards. A forecast verified against what the weather then did. A candidate synthesised after being proposed. This rung is qualitatively stronger than rung 2 and much rarer. 4 · Confirmed An independent method establis

This page is about method, not about any particular medicine, and nothing here is medical advice. It is written to answer one question: when a company says a drug was discovered with AI, which part of a decade-long process is that sentence about? The pipeline, and where the years go Roughly, and with enormous variation: pick a target, find molecules that do something to it, optimise those molecules into something drug-like, test in animals and in safety assays, then run the clinical stages — first for safety in a small number of people, then for efficacy in patients, then in a large confirmatory trial — and then apply to a regulator. Start to finish is usually over a decade. Two facts about that pipeline determine everything else on this page. The first is that the calendar and the money are dominated by the clinical stages, not the discovery ones. The second is that failure is the normal outcome, and it is concentrated where the drug first meets human biology: a candidate can be a beautiful molecule, hit its target exactly as designed, and still not help anyone, because the target was the wrong thing to hit. Where models are genuinely used Application Description Virtual screening Score enormous make-on-demand chemical libraries against a target site far faster than physics-based docking can. The output is a shortlist to synthesise and assay, and it replaces a search, not an experiment. Generative chemistry Propose molecules conditioned on a target, a scaffold or a set of property constraints, rather than picking from a catalogue. Whether the molecule can be made at all is a separate model. Property prediction Solubility, permeability, metabolic stability, cardiac ion channel liability. These filter a list early and cheaply. They are trained on assay data and inherit its coverage: they are most reliable on chemistry that resembles what has been tested. Retrosynthesis Plan a route from purchasable starting materials. This is the application closest to a solved probl

I asked Linux for one 4 KiB page from the start of a cold file. Four pages came back. I moved the same read one page further in, ran it again, and got one. Same file, same syscall, same kernel. The only thing that changed was where I started reading, and I spent twenty minutes assuming the tool I'd just written was miscounting. It wasn't. A read that starts at byte zero is treated as a promise. There's a branch in mm/readahead.c that reads, in full, if (!index) goto initial_readahead; . Offset zero means the kernel takes you for a program that's about to stream the whole file, and it fetches ahead immediately. Start anywhere else and you're assumed to be seeking randomly until a pattern proves otherwise. Nothing in my call said a word about my intentions. It inferred them from an offset. I spent two weeks on this sort of thing recently. Not for work, and not toward anything shippable. The short version of what I found is that a surprising amount of the machinery under a running program isn't carrying out instructions at all. It's guessing. The bench , because it changes how you should read every number here: an ext4 filesystem on a loop device, inside an OrbStack Linux VM on an Apple Silicon Mac, kernel 7.0.14, 4 KiB pages, read_ahead_kb at 128. That's a container sharing the host's kernel, not bare metal, and the host reclaims memory aggressively enough that a fully cached file can go cold in fifteen seconds. Reads came from dd ; the page-by-page counting came from a small C tool I wrote that mmap s a file and asks mincore() which of its pages are resident. You're not addressing the disk, you're addressing the page cache The model most of us carry is that read() goes and gets bytes off a device. It doesn't. It copies bytes out of the page cache into your buffer, and the page cache is just RAM the kernel uses to remember parts of files. If what you want is already there, no device is involved. If it isn't, the kernel fills the cache first and then copies. Either way

1. Language Architecture in Ghidra When Ghidra loads an architecture (such as the MOS 6502), it parses the .ldefs manifest file, which declares metadata and binds three foundational specification pillars: The .pspec (Processor Specification): Defines the processor’s hardware context. It declares special-purpose registers (e.g., stack pointer SP , status/flags registers), default memory maps (RAM, ROM, I/O), and hardware interrupt vectors. The .cspec (Compiler Specification): Defines the ABI and calling conventions (e.g., parameter passing mechanisms), stack alignment rules, and return value handling. This is the critical building block enabling the decompiler to reconstruct assembly into readable C code. The .sla / .slaspec (SLEIGH Specification): .slaspec : The human-readable source file describing the instruction set architecture (opcodes, instruction formats, and p-code semantics). .sinc (SLEIGH Include): Modular inclusion files (typically used to split complex architectures like ARM or x86, or isolate instruction subsets like Thumb). Given the simplicity of the 6502, everything is defined directly within the .slaspec file. .sla : The compiled binary version of the .slaspec (generated by the Sleigh compiler). Ghidra loads this compiled .sla file into memory at runtime for optimal performance. 2. The Challenges of Reverse Engineering Undocumented Binaries When dealing with a binary compiled for an undocumented processor, Ghidra's default paradigm faces major limitations: The .slaspec file is unavailable. Ghidra attempts to aggressively disassemble everything. Analyzing an undocumented target requires a strict two-phase approach. 3. Missing .slaspec File Without a valid .slaspec definition, Ghidra renders ?? for every opcode. The primary objective when tackling an unknown CPU is precisely to reconstruct this missing .slaspec specification. 4. Overcoming Ghidra's Aggressive Disassembly By default, Ghidra (like most disassemblers) employs an exhaustive strategy (usin

As gaming laptop prices continue to rise, it’s increasingly difficult to find affordable options that aren’t terrible. Here are your best options based on performance and cost.

If you've started learning DBMS for software engineering interviews, you've probably come across terms like Functional Dependency , Attribute Closure , Candidate Key , Normalization , and Canonical Cover . For many beginners, Canonical Cover feels like another algorithm to memorize. It isn't. Before you ever learn how to compute a Canonical Cover, you should understand why it exists . This article focuses only on the Introduction and Foundations . We intentionally won't discuss the algorithm yet. What Is the Interviewer's Intent? When interviewers ask about Canonical Cover , they are usually not testing your memorization . Instead, they want to know whether you understand: How databases represent business rules Why redundant rules create problems Whether you can simplify complex dependency sets Whether you understand the foundations of normalization In interviews, Canonical Cover often appears before questions on: Normal Forms Dependency Preservation Lossless Decomposition BCNF Schema Design Interviewers are checking your understanding of database design , not your ability to recite definitions. Why Do Interviewers Ask Canonical Cover? Imagine a database contains hundreds of dependency rules. Many of those rules may: Repeat the same information Contain unnecessary attributes Be derivable from other rules A good software engineer should recognize unnecessary complexity. Canonical Cover is essentially about answering one question: "Can we represent exactly the same constraints using fewer and simpler rules?" That's why interviewers ask it. They want to see whether you appreciate: simplicity correctness maintainability efficient schema design Where Does Canonical Cover Fit Inside DBMS? Think of DBMS topics as a learning roadmap. DBMS | -------------------------------- | | Database Design Transactions | | Functional Dependencies | Attribute Closure | Candidate Keys | Canonical Cover | Normalization | 2NF → 3NF → BCNF Canonical Cover belongs to the database design portio

Zulfi Alam thinks his team doesn’t need to “prove” they engineered a new state of matter in their bid to reinvent computing. Science would disagree.

Samsung dared to bring 6K to the world of gaming monitors before our PCs were truly ready for it.

Company noted for building quantum annealers now also making gate-based hardware.

A Deep Dive into the Memory Model From Source Code to Machine Instructions A five-part journey through compilers, executables, virtual memory, and the CPU Introduction: What Really Happens When Code Runs Consider a simple C program: include <stdio.h> int value = 10; int add(int a, int b) { return a + b; } int main() { int x = 5; int result = add(x, value); printf("%d", result); return 0; } Most programmers look at this and see only the visible outcome: 5 + 10 = 15 But behind that single printed number lies a much deeper story. Where does the data actually live? Who moves it from one place to another? How does the CPU find the instructions it needs to run? And how does the result finally make its way to the screen? Answering these questions means understanding a concept that many programmers use daily but rarely examine closely: the memory model. What Is a Memory Model, Really? Ask most developers what a "memory model" means, and the answer usually comes back in two words: stack and heap. That answer isn't wrong - it's just incomplete. A memory model is really a description of five things at once: How data is stored How data is accessed How long data exists Who is responsible for managing that lifetime How different parts of a system communicate through memory A program never leaps directly from C source code into RAM. Several distinct layers sit between the two, each one translating the layer below it into something the layer above can reason about. This article walks through all of them, one at a time, and then reassembles the full picture. The Four Layers, at a Glance Layer What It Deals With Typical Concepts 1. Programming Language Human-readable code scope, lifetime, ownership 2. Compiler Translating code to instructions registers, optimization, assembly 3. Operating System Running the program as a process virtual address space, .text/.data/.bss 4. CPU Architecture Executing raw instructions registers, cache, pipeline, ALU The rest of this article follows a sing

Why Decouple Reasoning from Motor Control General-purpose robots have to pull off two very different jobs at once. They need to read a cluttered, full-room visual scene, hold a multi-minute plan in memory, and converse with a person — and, in the same instant, close a high-frequency control loop that keeps a balancing humanoid upright and moves a delicate hand without dropping whatever it holds. Cramming both jobs into a single end-to-end network forces uncomfortable trade-offs: the large context window you want for reasoning fights the low latency you need for torque control. On July 28, 2026, Google DeepMind pushed directly against that trade-off with Gemini Robotics 2 , followed on July 30 by Gemini Robotics ER 2. Rather than one monolithic network, the suite splits the problem across three specialized models — whole-body vision-language-action (VLA) control, high-level embodied reasoning, and on-device adaptation — each tuned to a different cadence and context size. The same modular thinking is visible across recent robotics and VLA research collected on the arXiv robotics listings and on Hugging Face Papers , where decomposed perception-planning-control stacks have become a recurring pattern. Understanding DeepMind's specific split clarifies why this architecture is gaining traction. The Three-Model Split ER 2: High-Level Task Reasoning Gemini Robotics ER 2 is the cognitive planner of the stack. It is a vision-language model built for embodied reasoning: it ingests the live camera feed and a natural-language instruction, then decomposes a task that may run several minutes into structured sub-goals. Beyond planning, ER 2 manages dialogue with a human supervisor, interprets spatial context, and coordinates multiple robots operating in a shared workspace — deciding which sub-task gets handed to which platform. Operating more slowly than the control layer (roughly a few times per second), ER 2 trades frequency for breadth of context. That separation matters: a reas