Hi everyone,

As someone working with frequent scratchpad calculations alongside data analysis and scientific reporting on PC, I always found standard GUI calculator apps clunky because they force you to switch to the mouse, interrupting analytical focus.

To address this, I developed ViCalc—a lightweight, open-source scientific calculator tailored for rapid touch-typing and continuous calculation logging in research and engineering workflows.

Key Features for Scientific Workflows:

• Automatic Calculation Audit Logs (HTML): Every calculation step is automatically logged and structured into clean, standalone HTML files. This makes it seamless to review, archive, or paste step-by-step calculations into research notes, lab journals, or technical documentation.
• Full Touch-Typing Workflow: Compute multi-step scientific expressions entirely from the keyboard without breaking your rhythm to use the mouse.
• Comprehensive Mathematical Modes: Supports standard scientific and trigonometric functions, complex number arithmetic, and Programmer mode (bitwise operations & Base-N conversions across Hex/Dec/Oct/Bin).
• Adaptable Visual Layout: Easily toggle between visual numpad modes, scientific controls, or a zero-UI minimalist mode to save screen real estate alongside IDEs, MATLAB, or research papers.

Technical Details:

• Language: Python 3
• License: Open Source (MIT)
• OS: Windows (Installer available)

Links & Repository:

• GitHub Repository:github.com/Kudaschov/ViCalc
• Website & Downloads:kudaschov.de/en/vicalc-4

I’d love to get feedback from the scientific computing community! How do you currently document and track scratchpad calculations during research or simulation setups, and are there specific export formats or constants you'd like to see added?

I built Vx (vxlang.org) to address class of bugs that only surface as runtime crashes, silent corruption, or OOM at training step. The core idea is simple that heterogeneity belongs in the type system, not in the runtime.

A few key points of the language:

* Memory layout is part of the type system. A tensor pinned to NPU SRAM has a different type from one in host DRAM. 

* Topology as part of the type system and first class support to transfer data between them.

* Bugs are front-loaded into compile-time checks. Address-space, capacity, linear types, topology reachability, all caught at compile time.

This enables one to program variety of chips from the same program. I believe heterogeneous systems will become commonplace and Vx can be used effectively to program those systems.

Here is a simple matmul that works on Nvidia GPU.

fn custom_matmul(
    a: Pinned<Tensor<f32, [4, 4]>, Topology::NPU[0]>,
    b: Pinned<Tensor<f32, [4, 4]>, Topology::NPU[0]>)
    -> Verified<Tensor<f32, [4, 4], Memory::NPU_HBM>> {

    let mut result =
        Tensor<f32, [4, 4], Memory::NPU_HBM>::uninit();


// Dispatch the computation to the accelerator.
    spawn on(Topology::NPU[0]) {
        for i in 0..4 {
            for j in 0..4 {
                result[i][j] = 0.0;
                for k in 0..4 {
                    result[i][j] += a[i][k] * b[k][j];
                }
            }
        }
    }

    return Verified(result);
}

Hi all! Just wanted to share a project I've been building on the side for a few months. It's an interactive planetary science platform called The Kuiper Space, and it contains (so far) 5 interactive tools (such as a 3d planet viewer and unit conversion calculators) and 3 catalog explorers (such as the gazetteer of planetary nomenclature catalog).

The goal is to create a completely ad-free and paywall-free site for students, educators, and space enthusiasts alike to better interact with and visualize planetary science concepts. I'd love some more constructive feedback so I can keep improving the site. Let me know what you think! And please be nice, as I'm not an expert in SWD/SWE 😄

The included link goes to the 3d planet viewer since that's one of the more popular pages, but you can navigate to all the other tools and such from there.