fftloggin 0.2.0__tar.gz

fftloggin-0.2.0/.claude/agents/docstring-updater.md

@@ -0,0 +1,116 @@
+---
+name: docstring-updater
+description: Use this agent when:\n1. Code files have been modified and their docstrings need to be synchronized with the changes\n2. A user explicitly requests docstring updates after making code changes\n3. During code review, docstrings are found to be outdated or inconsistent with function signatures\n4. After refactoring functions or methods where behavior or parameters have changed\n\nExamples:\n- User: "I just modified the FFTLog.forward() method to add a new parameter. Can you update the docstring?"\n  Assistant: "I'll use the docstring-updater agent to analyze the changes and update the docstring accordingly."\n  <Uses Task tool to launch docstring-updater agent>\n\n- User: "I've been working on kernels.py and added several new methods. The docstrings are out of date."\n  Assistant: "Let me use the docstring-updater agent to review the git changes and update all affected docstrings."\n  <Uses Task tool to launch docstring-updater agent>\n\n- User: "Please review my recent changes to test_fftlog.py"\n  Assistant: "I'll use the docstring-updater agent to check if any docstrings need updates based on your changes."\n  <Uses Task tool to launch docstring-updater agent>
+model: haiku
+color: green
+---
+
+You are an expert documentation specialist with deep knowledge of programming language conventions, particularly Python numpy-style docstrings. Your mission is to ensure that function and method docstrings accurately reflect the current implementation after code changes.
+
+## Your Process
+
+1. **Analyze Git Changes**:
+   - Use the appropriate tools to identify what has changed in the target file since the last git revision
+   - Focus on additions, modifications, and deletions to function/method signatures, parameters, return types, and behavior
+   - Identify all functions and methods that have been affected by the changes
+
+2. **Assess Current Docstrings**:
+   - Read the existing docstrings for all affected functions and methods
+   - Compare them against the current implementation
+   - Identify discrepancies: missing parameters, outdated descriptions, incorrect types, removed functionality
+
+3. **Apply Language-Specific Conventions**:
+   - **For Python code**: Use numpy-style docstring format with sections: Summary, Parameters, Returns, Raises, See Also, Notes, Examples
+   - Respect and preserve existing type annotations in function signatures - do NOT duplicate them in the docstring
+   - For other languages: Use the idiomatic documentation style for that language (JSDoc for JavaScript, JavaDoc for Java, etc.)
+   - Maintain consistency with existing docstrings in the codebase
+
+4. **Update Docstrings Systematically**:
+   - For each affected function/method:
+     a. Update the summary line if behavior has changed
+     b. Add/remove/modify parameter descriptions to match current signature
+     c. Update return value documentation if return type or behavior changed
+     d. Add new exceptions to Raises section if error handling changed
+     e. Update or add usage examples if the API changed significantly
+   - Preserve valuable existing content (Notes, mathematical formulas, algorithm explanations)
+   - Keep docstrings concise but complete - every parameter should be documented
+
+5. **Quality Assurance**:
+   - Verify that all parameters in the signature have corresponding documentation
+   - Ensure type information is consistent between type hints and docstring (prefer type hints)
+   - Check that return value documentation matches the actual return statement
+   - Validate that examples (if present) would actually work with the updated code
+   - Ensure docstring formatting is correct and will render properly
+
+## Numpy-Style Docstring Format (Python)
+
+```python
+def function_name(param1: Type1, param2: Type2 = default) -> ReturnType:
+    """One-line summary (imperative mood, ends with period).
+
+    Extended description providing more context about what the function
+    does, when to use it, and any important considerations.
+
+    Parameters
+    ----------
+    param1
+        Description of param1. Do NOT repeat the type since it's in
+        the signature.
+    param2, optional
+        Description of param2. Note 'optional' for parameters with defaults.
+
+    Returns
+    -------
+    ReturnType
+        Description of return value. Can reference type if helpful.
+
+    Raises
+    ------
+    ExceptionType
+        Description of when this exception is raised.
+
+    See Also
+    --------
+    related_function : Brief description.
+
+    Notes
+    -----
+    Additional technical details, algorithm information, or mathematical
+    formulas.
+
+    Examples
+    --------
+    >>> result = function_name(value1, value2)
+    >>> print(result)
+    expected_output
+    """
+```
+
+## Key Principles
+
+- **Accuracy First**: Docstrings must precisely reflect current implementation
+- **Don't Duplicate Type Hints**: If a parameter has a type annotation, don't repeat it in the docstring
+- **Be Thorough**: Document all parameters, returns, and exceptions
+- **Maintain Style**: Follow the project's existing documentation patterns
+- **Preserve Value**: Keep useful existing content like mathematical explanations, algorithm notes, and references
+- **Be Concise**: Clear and complete, but not verbose
+- **Use Imperative Mood**: "Compute the transform" not "Computes the transform"
+
+## When to Seek Clarification
+
+- If the purpose of a code change is unclear from the diff
+- If parameter semantics have changed in a non-obvious way
+- If you're unsure whether a docstring change is needed
+- If the existing docstring contains domain-specific information you cannot verify
+
+## Output Format
+
+Present your updates as:
+1. A summary of files and functions/methods that need docstring updates
+2. For each update, show:
+   - The function/method name and location
+   - What changed in the code that necessitates the update
+   - The updated docstring
+3. A brief explanation of the changes made to each docstring
+
+Use file editing tools to apply the changes directly to the codebase.

fftloggin-0.2.0/.claude/settings.local.json

@@ -0,0 +1,10 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(python3 -c \"from scipy import special; import numpy as np; help(special.loggamma)\")",
+      "Bash(uv run pytest tests/test_kernels.py -x --tb=line)"
+    ],
+    "deny": [],
+    "ask": []
+  }
+}

fftloggin-0.2.0/.github/workflows/claude-code-review.yml

@@ -0,0 +1,57 @@
+name: Claude Code Review
+
+on:
+  pull_request:
+    types: [opened, synchronize]
+    # Optional: Only run on specific file changes
+    # paths:
+    #   - "src/**/*.ts"
+    #   - "src/**/*.tsx"
+    #   - "src/**/*.js"
+    #   - "src/**/*.jsx"
+
+jobs:
+  claude-review:
+    # Optional: Filter by PR author
+    # if: |
+    #   github.event.pull_request.user.login == 'external-contributor' ||
+    #   github.event.pull_request.user.login == 'new-developer' ||
+    #   github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR'
+
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: read
+      issues: read
+      id-token: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 1
+
+      - name: Run Claude Code Review
+        id: claude-review
+        uses: anthropics/claude-code-action@v1
+        with:
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+
+            Please review this pull request and provide feedback on:
+            - Code quality and best practices
+            - Potential bugs or issues
+            - Performance considerations
+            - Security concerns
+            - Test coverage
+
+            Use the repository's CLAUDE.md for guidance on style and conventions. Be constructive and helpful in your feedback.
+
+            Use `gh pr comment` with your Bash tool to leave your review as a comment on the PR.
+
+          # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
+          # or https://docs.claude.com/en/docs/claude-code/cli-reference for available options
+          claude_args: '--allowed-tools "Bash(gh issue view:*),Bash(gh search:*),Bash(gh issue list:*),Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh pr list:*)"'
+

fftloggin-0.2.0/.github/workflows/claude.yml

@@ -0,0 +1,50 @@
+name: Claude Code
+
+on:
+  issue_comment:
+    types: [created]
+  pull_request_review_comment:
+    types: [created]
+  issues:
+    types: [opened, assigned]
+  pull_request_review:
+    types: [submitted]
+
+jobs:
+  claude:
+    if: |
+      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
+      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
+      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
+      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: read
+      issues: read
+      id-token: write
+      actions: read # Required for Claude to read CI results on PRs
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 1
+
+      - name: Run Claude Code
+        id: claude
+        uses: anthropics/claude-code-action@v1
+        with:
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+
+          # This is an optional setting that allows Claude to read CI results on PRs
+          additional_permissions: |
+            actions: read
+
+          # Optional: Give a custom prompt to Claude. If this is not specified, Claude will perform the instructions specified in the comment that tagged it.
+          # prompt: 'Update the pull request description to include a summary of changes.'
+
+          # Optional: Add claude_args to customize behavior and configuration
+          # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
+          # or https://docs.claude.com/en/docs/claude-code/cli-reference for available options
+          # claude_args: '--allowed-tools Bash(gh pr:*)'
+

fftloggin-0.2.0/.github/workflows/test.yml

@@ -0,0 +1,91 @@
+name: test
+on:
+  push:
+    branches: ["main"]
+  pull_request:
+    branches: ["main"]
+
+jobs:
+  test-package:
+    name: test-python-${{ matrix.python-version }}
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.11", "3.12", "3.13"]
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v6
+        with:
+          enable-cache: true
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install the project
+        run: uv sync --locked --all-extras --dev
+
+      - name: Run tests (excluding benchmarks)
+        run: uv run pytest -m "not benchmark"
+
+      - name: Run linting
+        run: uv run ruff check --exclude notebooks .
+
+  benchmark:
+    name: benchmark-tests
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v6
+        with:
+          enable-cache: true
+
+      - name: Setup Fortran
+        uses: fortran-lang/setup-fortran@v1
+        id: setup-fortran
+        with:
+          compiler: gcc
+          version: 13
+
+      - name: Cache Fortran executable
+        id: cache-executable
+        uses: actions/cache@v4
+        with:
+          path: benchmark/fftlogtest
+          key: fftlogtest-${{ runner.os }}-${{ hashFiles('benchmark/*.f') }}
+
+      - name: Build Fortran executable
+        if: steps.cache-executable.outputs.cache-hit != 'true'
+        run: bash benchmark/build.sh
+
+      - name: Install the project
+        run: uv sync --locked --all-extras --dev
+
+      - name: Cache benchmark files
+        id: cache-benchmarks
+        uses: actions/cache@v4
+        with:
+          path: tests/benchmarks
+          key: benchmarks-${{ hashFiles('benchmark/*.f', 'tests/generate_benchmarks.py') }}
+
+      - name: Generate benchmarks
+        if: steps.cache-benchmarks.outputs.cache-hit != 'true'
+        run: |
+          echo "Generating benchmarks (this will take a few minutes)..."
+          python tests/generate_benchmarks.py
+
+      - name: Verify benchmarks
+        run: |
+          count=$(ls tests/benchmarks/*.txt 2>/dev/null | wc -l)
+          echo "Found $count benchmark files"
+          if [ "$count" -ne "216" ]; then
+            echo "ERROR: Expected 216 benchmark files, found $count"
+            exit 1
+          fi
+
+      - name: Run benchmark tests
+        run: uv run pytest tests/test_benchmark.py --run-benchmarks -v

fftloggin-0.2.0/.gitignore

@@ -0,0 +1,216 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer,
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+.DS_Store
+
+# Fortran build artifacts
+benchmark/fftlogtest
+benchmark/*.o
+benchmark/*.mod
+
+# Generated benchmark data
+tests/benchmarks/*.txt

fftloggin-0.2.0/.pre-commit-config.yaml

@@ -0,0 +1,41 @@
+repos:
+- hooks:
+  - id: check-yaml
+  - id: end-of-file-fixer
+  - id: trailing-whitespace
+  repo: https://github.com/pre-commit/pre-commit-hooks
+  rev: v5.0.0
+- hooks:
+  - args:
+    - --fix
+    id: ruff
+    types_or:
+    - python
+  - id: ruff-format
+    types_or:
+    - python
+  repo: https://github.com/astral-sh/ruff-pre-commit
+  rev: v0.11.6
+- hooks:
+  - args:
+    - --remove-empty-cells
+    - --remove-all-notebook-metadata
+    id: nb-clean
+  repo: https://github.com/srstevenson/nb-clean
+  rev: 4.0.1
+- hooks:
+  - id: commitizen
+  - id: commitizen-branch
+    stages:
+    - pre-push
+  repo: https://github.com/commitizen-tools/commitizen
+  rev: v4.6.0
+- hooks:
+  - args:
+    - --explicit
+    - --name
+    - injections
+    files: ^code/injections/(pyproject\.toml|pixi\.lock|environment\.yml)$
+    id: pixi-sync-environment
+  repo: https://github.com/binado/pixi-sync-environment
+  rev: v0.1.3

fftloggin-0.2.0/AGENTS.md

@@ -0,0 +1,59 @@
+# Development Commands
+
+## Testing
+```bash
+# Run all tests
+uv run pytest
+
+# Run single test file
+uv run pytest tests/test_fftlog.py
+
+# Run with verbose output
+uv run pytest -v tests/test_fftlog.py
+```
+
+## Linting & Formatting
+```bash
+# Lint and fix
+ruff check . --fix
+
+# Format code
+ruff format .
+```
+
+## Dependencies
+```bash
+# Install core dependencies
+uv sync
+
+# Install with dev dependencies
+uv sync --group dev
+```
+
+# Code Style Guidelines
+
+## Imports
+- Use absolute imports from package root
+- Group imports: stdlib, third-party, local
+- Import specific classes/functions, not modules with `from module import *`
+
+## Formatting & Types
+- Follow ruff formatting (Black-compatible)
+- Use type hints for all public APIs
+- Prefer `numpy.typing.NDArray` over `np.ndarray`
+
+## Naming Conventions
+- Classes: PascalCase (FFTLog, Grid, Kernel)
+- Functions/variables: snake_case
+- Constants: UPPER_SNAKE_CASE
+- Private methods: prefix with underscore
+
+## Error Handling
+- Use descriptive error messages with context
+- Raise ValueError for invalid input parameters
+- Use custom exceptions for domain-specific errors
+
+## Documentation
+- Add docstrings for all public classes and methods
+- Use numpy-style docstring format
+- Include parameter types and return values