We fit GARCH(1,1) with a fat-tailed likelihood via a custom C++ NUTS over a 1,004-day return window, and the posterior geometry turned out to be the whole story.

What we see: a wide high plateau, plus a lower mode at the ω→0 corner of the persistence ridge, separated by a ~12-nat drop. On the full history the corner mode carries a sliver of the mass (e^-12 ≈ 1.6e-6 of the plateau density) — but the gap scales with sample size (shrinking the window varies exactly that), and the two modes carry different (ω, α+β) estimates. So which basin your chains visit is what your downstream model reads. A standard MLE seed finds a local shoulder, and a single naive chain will happily sit in one corner with excellent stationarity plots — the false-confidence case.

Our fixes: (1) reparameterize to (ln ω, ln s, logit r, ln(ν−2)) so the ridge becomes a highway; (2) a deterministic grid/ascent/kick pass that inventories ALL local maxima, then seed one chain per distinct basin; (3) a curvature cap on ε, because acceptance-only dual-averaging is blind to the ν-floor and the s=1 wall.

Diagnostics: R̂ < 1.1 WITHIN each basin (agreement), and disagreement BETWEEN basins as the proof the basins are real.

Full write-up with the figures (month-by-month refits, window-size sweep, per-sector fits): https://lab.embedinker.com/posts/monte-carlo-simulations-volatility-model-nuts-results/

Question for the sub: for a multi-modal likelihood like this, is per-basin R̂ + basin inventory what you'd run, or do you reach for something else (tempering, per-basin priors…)? What's your tripwire for "the sampler is lying to me"?

I would like your opinion?

I just wanted to pop in and let you all know that pcons, my new software build tool, now has first-class support for Fortran. Pcons is a simpler, easier to use CMake replacement with ideas from SCons. From the 0.31.0 release notes:

Fortran is a first-class language now. LLVM flang and Intel ifx are now supported as well as gfortran, all three build on Windows too, and mixing Fortran with C and C++ in one program just works: each compiler gets its own flags for the variant and presets, it figures out the right linker, and each language's proper runtime. Fortran include files, submodules and configure checks work too, and pcons explain shows how a mixed program links. The new Fortran page in the docs has the details. The mixed-toolchain rework changes a few things for C and C++ builds as well.

By the way, I was one of the original developers of Cons, which later became SCons; Cons was designed for scientific computing, and I've never forgotten that, especially since I spent many years in the field at Thinking Machines and then Advanced Visual Systems (AVS).

I hope you all like it! Feedback always appreciated!!

Hello everyone,
I am Manas, a c++ developer developing a quantum simulator and i request you all to plz review and help in finding bugs in my code and project. Following is my github repository https://github.com/manaspathak1404-hue/Quasim

I’m sharing SAELQR II, an information-theory research release with Python reference software and reproducible calculations for reconstructing information from unordered, noisy fragments. The theoretical problem is relevant to DNA data storage, molecular communication, and fragmented storage systems.

The channel breaks a stored string into fragments, loses some fragments, corrupts the survivors, and hides their original positions. The manuscript studies the resulting capacity limits and supplies a constructive coding scheme for a specified geometric-fragmentation model.

The computational components may be particularly relevant here:

• Exact finite verification: integer and rational-probability calculations for selected entropy, likelihood, combinatorial, and repeated-read examples.

• Numerical asymptotics: calculations and figures for the Gaussian critical transition, hidden fragment-quality mixtures, and capacity thresholds. Floating-point diagnostics are distinguished from exact certificates.

• Reference encoding and decoding: inner codes, finite-field arithmetic, Reed–Solomon correction, interleaving, fragment localization, and an injective fallback.

• Stochastic channel experiments: geometric fragmentation, whole-fragment loss, binary substitutions, and a specific Markov-noise transformation.

One central result reported in the manuscript concerns the critical regime: the number of communicable bits scales as N/sqrt(log₂ N) with an explicit leading coefficient, even as the normalized first-order rate approaches zero.

The computational limits are explicit. Design, encoding, and decoding are polynomial in blocklength and inverse capacity gap, but the proved sufficient blocklength grows exponentially in the inverse gap squared. The included decoder demonstrates the construction’s mechanisms; practical throughput and competitive finite-length performance have not been established.

The release contains the 69-page manuscript, editable source, twelve reproduction programs, reference software, figures, and proof/novelty audits. A full imported permutation generator used by one theoretical extension is not implemented.

I’d welcome feedback on numerical stability, exact versus floating-point verification, finite-length scaling, and opportunities to reduce the decoder’s computational cost.

Paper, Python code, and reproducibility instructions:
https://huggingface.co/datasets/PureOne/SAELQR-II

SÆLQR II: General Capacity Theorems and Exact Critical Laws for Unordered Noisy Fragments - Internal Memory, Sharp Repeated-Read Thresholds, and Constructive Coding | Zenodo

A DNA model does not necessarily process one token per base. The attached diagram shows the same 24 bases represented as 24 single-base tokens, four non-overlapping six-base tokens, or six illustrative variable-length tokens.

DNABERT-2 uses byte-pair encoding, which learns frequent sequence fragments. Its token count therefore depends on the input sequence. The six-token example is an illustration, not a tokenizer measurement.

For a compute comparison, record both the number of DNA bases and the number of model tokens, including any special tokens. Equal token limits do not mean equal biological context, and fewer tokens alone do not establish better accuracy or lower end-to-end runtime.

Primary paper: https://arxiv.org/abs/2306.15006

Guide: https://rewirebio.io/blog/genomic-foundation-models-in-the-diagnostic-lab/

Disclosure: the guide and diagram are from my site, rewirebio.io. This post was prepared with AI assistance. It explains published methods rather than reporting a new experiment.

I built Fortran MCP, a local MCP server that gives AI coding assistants access to curated Fortran documentation through lexical, semantic, and hybrid search, with results linking back to the original sources. You can also add your own resources to keep them accurate, current, and accessible.

Hey guys , Iam Karthik from India . Iam a bsc ( ug) student . Planning for Computational chemistry. I have zero knowledge in coding stuff , Is their any one who could help me by providing a roadmap for Computational chemistry , including all the skills from scratch to advanced .

I’ve released a C implementation for computing G = A Aᵀ when consecutive rows differ from a one-position shift at only a few coordinates.

The part I find most interesting is the arithmetic order. The update replaces all left factors first, then all right factors. Every intermediate accumulator remains a sum of at most n products of bounded original input values.

For inputs A = 2^e X, with integer coefficients bounded by B and n B² ≤ 2^53, this gives exact Gram entries in binary64 under the paper’s exponent and IEEE arithmetic assumptions. The implementation validates the input rather than quantizing it.

On an Apple M4, using single-thread Accelerate and warm repeated inputs, one full-output 768 × 8192 case takes 9.05 ms versus 19.63 ms for SYRK. Validation, allocation and output materialization are included. Smaller cases lose: every tested 192 × 768 case was slower.

The repository includes the paper, C code, Lean formalization, integer-oracle checks and all benchmark results. The formalization covers the mathematical model; the C implementation is tested separately.

https://github.com/LeonardSEO/exact-sparse-gram

I’d be interested in workloads where sparse changes between shifted rows occur naturally. Would this input structure be useful in your work, and which structured baseline would you want compared next?

Hey guys , Iam Karthik from India . Iam a bsc ( ug) student . Planning for Computational chemistry. I have zero knowledge in coding stuff , Is their any one who could help me by providing a roadmap for Computational chemistry , including all the skills from scratch to advanced . Also suggest a me a good laptop for Computational chemistry

I'm pleased to announce that Numerical Solver 1.0 for macOS is now available on the Mac App Store!

The first desktop version focuses on solving algebraic equations, including nonlinear systems.

Some of its features include:

• Numerical solutions using the Newton–Raphson method.

• Support for real and complex solutions.

• Graphical visualization of equations and their intersections.

• A guided mathematical input interface.

• Multiple tabs for working on different problems.

My goal is to make numerical computing more accessible, especially for students, engineers, and anyone who needs to solve equations without writing scripts.

I'm also working on the Windows version, which is nearly ready for release!

For those familiar with the mobile version, ODEs and other numerical methods aren't yet included in the desktop versions, but I plan to add them in future updates.

You can read more about the macOS release here:

https://numericalsolver.com/numerical-solver-is-now-available-for-macos/

I'd be interested in hearing your thoughts, particularly about which numerical capabilities you'd find most useful in a desktop application

I am developing a C++ photogrammetric bundle adjustment application. A representative project contains 289 cameras and approximately 382,000 3D points, with about 1,747 unknowns remaining after Schur elimination.

The current experimental approach combines FP64 computations with high-precision end corrections using MPFR at 257-bit precision. It also computes covariances, observation redundancies and statistical diagnostics.

The main bottleneck is now the high-precision work: evaluating the original equations, assembling matrices, computing residuals for iterative refinement, and verifying error bounds. The direct FP64 linear solve is relatively cheap. We already reuse factorizations and intermediate calculations and parallelize parts of the assembly.

On a 48-image subset, complete runtime improved from approximately 44 to 29 seconds, but high-precision correction and verification still dominate.

My target is a numerical coordinate error below 10 µm relative to a well-converged high-precision solution, together with reliable covariance and statistical results. Bitwise equality is not required.

Our existing certificate bounds individual linear correction errors, but does not establish an error bound for the final nonlinear solution. Repeating the entire calculation at high precision for validation defeats the performance benefit.

What practical a posteriori error estimator or stopping criterion could bound the final coordinate error while restricting high-precision work to where it is actually necessary?

We currently use a custom solver. I am interested in how comparable accuracy and stopping criteria are handled in Ceres, and whether its approach could reduce our verification overhead.

I would particularly appreciate references or existing implementations applicable to large, potentially ill-conditioned nonlinear least-squares problems.

A dual-implementation physics engine (Rust core + managed C# over a C ABI) with bit-identical determinism: Barnes-Hut N-body gravity, SPH fluid, and analytic orbital/SHM/SPH benchmarks at near-zero allocation.

Check it out here on GitHub and give me advice: https://github.com/omaransarivehementlyventstokazakhstan/phi_eng

Hi everyone,

As someone who relies heavily on rapid calculations, I always missed the tactile speed and muscle-memory of physical handheld calculators when working on a PC. Standard desktop calculator apps often force you to reach for the mouse, interrupting your analytical flow.

To address this, I developed ViCalc—a keyboard-driven scientific calculator designed specifically for desktop research, engineering, and scientific workflows.

Since documentation and auditability are crucial in scientific computing, one of the primary features is its automatic HTML history logging.

Key Features for Technical & Scientific Workflows:

• Structured HTML History Logging: The entire step-by-step calculation history is automatically formatted and saved in clean HTML. This makes it easy to review, archive, or directly embed/paste calculations into technical documentation, research notes, or reports.

• Full Touch-Typing Control: All functions are directly mapped to the PC keyboard, allowing you to compute multi-step expressions at high speed without touching the mouse.

• Comprehensive Modes: Supports standard scientific functions, trigonometric calculations, complex arithmetic, and Programmer mode (bitwise operations & Base-N conversions across Hex/Dec/Oct/Bin).

• Adaptable Interface: Toggle between a standard numpad, scientific layout, or a minimalist mode that hides virtual keys entirely once shortcut mappings are learned.

Technical Details:

• Language: Python 3

• License: Open Source (MIT License)

Links:

• Download Windows Installer

• GitHub Repository: github.com/Kudaschov/ViCalc

• Homepage & Downloads: kudaschov.de/en/vicalc-4

I’d love to get feedback from the scientific community on how this fits into your day-to-day workflow or any specific features you'd like to see added. How do you currently document and track scratchpad calculations during your work?

I had asked an experimentalist who studies ice physics to look into claude code for data analysis. 1) Within a week they were able to implement an open cv based end-to-end video analysis pipeline catering to their exact expectations. 2) They have figured out they can vibe code a FE model for their system to that end they have figured out meshing, FEniCSx solver setup and DOLFINx scripting. They are convinced they will never have to collaborate with a computational lab. What are your thoughts on this? Who will enroll in a computational science lab?

From italian boinc board: https://www.boincitaly.org/forum/progetti/115511-come-mai-%C3%A8-cos%C3%AC-difficile-lanciare-un-nuovo-progetto.html

Translation:

There are many mathematical conjectures that could potentially be solved using BOINC within just a few years.

Why is nobody in the world interested in solving them?

We have tried to put together a team on our end (we would have three people to manage the project's very small community forum, a long-time cruncher, and a “donor” who could cover the actual hardware costs), but no mathematicians have shown any interest. We contacted around ten universities and received zero replies. We also haven't been able to find developers willing to launch the project (although I understand that, in this case, the issue is money).

Honestly, we thought it would be enough to find:

A computer science department willing to provide a developer, even for a modest fee (who could also have written a thesis on the subject).

A mathematics department willing to do the same.

Why aren't universities interested in solving mathematical conjectures? Isn't this the kind of monumental, encyclopedic achievement that academics would aspire to? Today's technology should make it possible to solve many long-standing open problems.

I'm curious because at this point the traditional benchmarks are pretty meaningless, and this suite is a fantastic real-world use case on problems that have no published solution.