IPS9 - Introduction to the Practice of Statistics

From the book Introduction to the Practice of Statistics
Explore the docs »

Report Bug · Request Feature · View Outputs

Table of Contents

1. About the Project
   • Built With
2. Getting Started
   • Prerequisites
   • Installation
3. Usage
4. Roadmap
5. Resources
6. Contributing
7. License
8. Contact

About the Project

This repository contains worked Jupyter notebook examples from the book, Introduction to the Practice of Statistics, ninth edition.

Built With

• Lisp-Stat
• common-lisp-jupyter

Getting Started

To get a local copy up and running follow these steps:

Prerequisites

An ANSI Common Lisp implementation. Developed and tested with SBCL

Installation

1. Install common-lisp-jupyter
2. Clone the repository

   cd ~/quicklisp/local-projects &&
   git clone https://github.com/Lisp-Stat/IPS.git

3. Reset the ASDF source-registry to find the new system (from the REPL)

   (asdf:clear-source-registry)

4. Load the system

   (ql:quickload :ips)

Usage

Run Jupyter-Lab in the IPS directory above. You should see the example notebooks.

VS Code vs. Jupyter Notebooks

common-lisp-jupyter (JupyterLab) and VS Code take different approaches to cell execution, and there isn't (yet) a good VS Code extension for Common Lisp. If you run a notebook in VS Code you should set the cell language to 'clojure', which is the closest language for which VS Code does have support. You'll lose some of the Common Lisp syntax highlighting, but the cells will run. Here's a detailed explanation of the differences:

JupyterLab Approach

• No cell-level language identifiers - cells don't have individual language metadata
• Kernel determines everything - the notebook kernel (Python, R, Julia, Common Lisp, etc.) handles all code execution and language features
• Uniform syntax highlighting - all code cells use the same syntax highlighting based on the kernel language
• Simple model - one kernel = one language for the entire notebook

VS Code Jupyter Support

• Cell-level language metadata - each cell can have its own language identifier
• Hybrid approach - kernel handles execution, but cell language affects editor features
• Per-cell syntax highlighting - each cell can have different syntax highlighting
• More complex - allows mixed-language notebooks (though execution still goes through one kernel)

Why VS Code Does This

VS Code's approach allows for:

• Better editor integration - language servers, IntelliSense, error checking per cell
• Mixed content - you could have SQL in one cell, Python in another (with appropriate kernels)
• Consistent editor experience - same language features as regular files
• Flexibility - syntax highlighting can differ from execution kernel

The Trade-off

JupyterLab's simpler approach:

• No language confusion - kernel = language
• Consistent experience
• No metadata overhead

VS Code's approach:

• More flexible and powerful
• Can create confusion
• Requires language metadata management

For Common Lisp

In JupyterLab with a Common Lisp kernel:

• All cells automatically get Common Lisp syntax highlighting
• No need to specify language per cell
• Kernel handles everything

In VS Code:

• You need to set cell language to the closest syntax (Clojure)

Roadmap

See the open issues for a list of proposed features (and known issues). We will include additional examples in the chapter order of the book

Resources

This system is part of the Lisp-Stat project; that should be your first stop for information. Also see the

community page for more information.

Contributing

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated. Please see CONTRIBUTING for details on the code of conduct, and the process for submitting pull requests.

License

Distributed under the MS-PL License. See LICENSE for more information.

Contact

Project Link: https://github.com/lisp-stat/IPS