Follow @PistonDeveloper at Twitter!

Here are some of the things that happened since the last post:

AdvancedResearch

Advanced research focuses on making conceptual breakthroughs in system thinking. The previous advanced research under the Piston project is moving to this new open source organization. You can read about the rationale of separating this research from the Piston project here.

Some bullet points of the overall progress:

• New approach to mathematical foundation of friendly artificial intelligence nicknamed “golden rationality”
• Some progress on path semantics and generalizations to probability theory
• Gini solvers could balance economic inequality (can be tested in MMOs)
• Established contact with scientists and engineers about mitigating climate change

Golden rationality is a very recent topic, where I try avoiding the scary first order approximation to friendly superintelligence and instead focus on human value approximation concerning group strategies. This means it is not about superintelligence “in a box”, but about beating the efficiency of individual rational agents in a world where AI is standardized and utilized by many people. For discussion and questions, open up an issue here.

Normal research related to gamedev will continue under the Piston project.

Conrod

• New CollapsibleArea widget
• Improved performance
• Added crates.io categories
• Various bug fixes and improvements

List of contributors (59)

Image

There is an internal compiler bug on Rust 18 Beta, so if you have troubles compiling your project, you might want to use Right stable or nightly instead.

• Simple BMP support
• PPM support
• New constructor for adjusting quality of JPEG encoding

List of contributors (89)

Imageproc

• Improved performance, incluing better parallization using Rayon
• Added more benchmarks
• Ellipse and bezier drawing
• Various bug fixes and improvements

List of contributors (14)

Dyon

• New intrinsics
• Optional namespaces with shared aliases
• Link loop (a loop that concatenates body expressions using Dyon’s link data structure)
• Try expressions (turning errors into result)
• Various bug fixed and improvements

List of contributors (4)

VisualRust

• Cargo support
• Support for both Visual Studio 2015 and 2017
• Various bug fixes and improvements

List of contributors (14)

Other projects

• New versions of Gfx has been updated through the ecosystem
• resize has gotten nice upgrades and performance improvements
• music now supports sound clips

The Piston project is pleased to announce Dyon-Snippets, a place to share Dyon source code and discuss library design!

Dyon is scripting programming language started in 2016 by myself (Sven Nilsen, bvssvni).

Dyon started as an experiment in a period I had a lot of time, while waiting for some important Gfx redesigns. After a week of coding, I discovered that it was possible to use a lifetime checker (like Rust), but without borrow semantics (unlike Rust) instead of a garbage collector. Combined with copy-on-write for non-stack references, this creates a very limited memory model but sufficient enough for many practical applications. It is difficult to write object oriented code in Dyon, but it is very nice for iterating over arrays.

• Built-in support for 4D vectors and HTML colors
• Packed loop for mathematical index notation
• Secrets (more about this later)

The language uses dynamic loading of modules to organize code, where you have full control over module dependencies. It is very common to write a loader script, a program that runs before you run the actual program.

Here is an example:

fn main() {
    foo := unwrap(load("foo.dyon")) // Load `foo`.
    bar := unwrap(load(source: "bar.dyon", imports: [foo])) // Load `bar` with `foo` as dependency.
    call(bar, "main", []) // Run the function `main` on the `bar` module.
}

This allows a kind of programming where you easily control how stuff gets loaded, e.g. check for for updates or refresh a module every Nth second.

I often use Dyon for problem solving, because the language has a feature called “secrets”. A secret is a hidden array of values associated with a bool or f64. The type is sec[bool] or sec[f64]. The indexed loops in Dyon are integrated with secrets.

For example, you have a 2D array v and compute the maximum value:

m := max i, j {v[i][j]}
println(m) // Prints maximum value of `v`.

Dyon infers the range from the loop body. The code above is equivalent to:

m := max i [len(v)), j [len(v[i])) {v[i][j]}

This is a packed loop which is equivalent to:

m := max i [len(v)) {max j [len(v[i])) {v[i][j]}}

The notation max i, j {v[i][j]} is inspired by mathematics. In mathematics and physics it is very common to use indices and custom loops. It is easy to translate back and forth between equations and Dyon code, and it helps you learn mathematics as well!

The type of m is sec[f64]. You can write the following:

where_max := where(max)
println(where_max) // Prints `[i, j]`.

This is how it works:

1. The inner max loop returns the maximum value with a secret [j].
2. The outer max loop finds the maximum inner value and changes the secret to [i, j].

A secret propagates from the left argument in binary operators. This means you can combine any and all loops with max and min:

// Is there any list which maximum value is larger than 10?
m := any i {max j {v[i][j]} > 10}
if m {
    println(why(m)) // Prints `[i, j]`.
}

In problem solving this is very convenient, because many problems can be thought of as formulating a question. When you know the right question to ask, the answer is often easy to find.

This blog post is about a new experimental uniform binary format for particle physics: Piston-Binpool

Background

Currently I am diving deep into marine cloud brightening to understand how humanity can avoid some severe effects of climate change by using some form of clean and reversible geoengineering. If you did not know already, there have been some very worrisome observations in 2016-2017, so I thought it was a good idea to educate myself a bit and perhaps get some input on what technological challenges there are. The scientists and engineers working on this have been quite open and even sent me papers to read! Thanks guys.

While reading about this, which seems to require understanding of climate modelling (it is understandable if you take your time), I figured doing some basic virtual physics experiments could help my brain along the way. Nothing advanced yet, just freshing up some of the things I played around with over the years.

One thing I discovered, that it is not obvious what kind of analysis you want to do with a virtual experiment. Instead of running simulations over and over, I would like to collect the raw data and later run algorithms that computes some functional relationship.

The advantage of this method is that you can exploit some physical similarites between systems. For example, it is commonly known that certain physical behaviors can transfer knowledge between a model and the full size system. So, collecting data about some few particles colliding in a slow motion simulation, can give you knowledge about particles colliding in high velocities and over a huge area. This way you can save both time and energy, because you do not have to simulate every detail of a full system.

This is also interesting because I came across similar ideas when researching path semantics. Studying physics could help design algorithms that predict approximate behaviors of other algorithms. One long term goal is to develop a constraint solver that can assist with engineering tasks.

Motivation and design

I could not find a standard format for storing and reading particle data in a such way that you can reuse algorithms between projects, so I made my own experimental one.

Here is the format:

type format == 0 => end of stream
type format: u16, property id: u16
|- bytes == 0 => no more data, next property
|- bytes: u64, offset instance id: u64, data: [u8; bytes]

The first flag is a type format, which supports 10 common Rust numerical primitives, with vector and matrix dimensions up to 80x80.

The second flag is a unique property id that identifies the property of the particle system. This is also used to define time, e.g. a f32 scalar.

Next the format stores the number of bytes in the data block and an offset instance id, such that you can read and write parts of the particle system (e.g. only the part that is dynamic or needed for analysis).

The number of particles in the block is derived from the number of bytes and the type format. You can also specify a custom binary format, in which case a general purpose analysis tool can just skip the block.

For each frame in a simulation, you simply write out a set of properties, and when reading back a frame you use a loop that breaks when all properties are set. More information about the usage is in the README file.

Future work

My hope is that I am able to reuse realgorithms across projects, for example a command line tool that computes the energy or the number of collisions.