Author Archive: ebvalaim

A new domain

I'm not particularly rich, so when I was creating this blog, I preferred a free domain. It just so happened that my hosting was offerring free subdomains under its own domain (username.mydevil.net). I decided to use the opportunity and this is how my blog got the address ebvalaim.mydevil.net.

Unfortunately, a problem emerged. There were changes in the hosting company some time ago and the free domains changed their endings from .mydevil.net to .usermd.net. Existing domains were still working as long as nothing had to be changed about them. A few days ago, though, such a necessity appeared - my SSL certificate from Let's Encrypt expired and renewing it proved to be impossible on the old domain. I had to switch to a new one, without a possibility of even creating a redirection.

I used the domain ebvalaim.usermd.net, but I knew it had to be only temporary. In order to avoid similar situations in the future (either due to internal changes in the hosting company or having to change the hosting for some reason), I had to get an external domain.

As of today, then, welcome to the brand new domain ebvalaim.pl :)

An adventure with a microcontroller

At the beginning of May I digged up an old toy of mine, from about 2002-2004 - a "test computer" based on the 80C535 microcontroller. The computer consists almost exclusively of the controller, the memory (EPROM + RAM), a power connector and a serial port (RS-232) and some I/O ports. The serial port serves as a means of communication with a PC, allowing for uploading to it programs written in a simple assembly language.

80C535 test computer

80C535 test computer

Two problems appeared, though. The first one was that modern computers rarely have an RS-232 port, and laptops probably don't have them at all. This one was easy to solve by ordering a USB adapter from the internet. The second one was more serious.

In 2003 I was 15 years old, so as you can probably guess, I didn't have much influence on the design of the computer. It was designed by my teacher, who also provided us (me and the other students in the electronics club) with some software for writing and uploading programs. The problem is, during the 14 years that passed since that time, I lost the software and I have no contact with the teacher. Well, I said to myself, I'm an adult now and I'm quite good at programming, so I can probably figure this out ;)

And so began my adventure with reverse-engineering a toy from the electronics club.

(more…)

Rust: applications with plugin API

Some applications let their users modify their functionality. In most cases, it is done via plugins - small libraries that are being loaded by the main program, and then called in some specific circumstances. A well-known example would probably be the instant-messaging programs like Pidgin. They can communicate using various protocols (Jabber, Facebook, ...), have custom themes or provide additional functions thanks to the plugins that are available for them. In the Orbiter simulator the users can add new spaceships in the form of plugins. There are a lot of possible use cases. In this blog entry I'm going to present a way of achieving a similar effect in the Rust language. My way isn't probably the only one or the best, but I find it simple and convenient :)

(more…)

Making fun with Ithkuil easier

During the last few days I've been improving a tool I created a long time ago, which was supposed to make it easier to have fun with Ithkuil. But let's start at the beginning

Ithkuil

Ithkuil is a constructed language created by John Quijada. Constructed languages (or "conlangs") are usually associated with children (I myself was creating my own languages when I was 10-12), but in this case you couldn't be further from the truth. Even though Ithkuil doesn't really have practical applications, I think it is unusually interesting.

Ithkuil emphasizes conveying as much information as possible, as concisely as possible. As a result, it has 45 consonants and 13 vowels, and almost every sound in a word carries a separate bit of information. How was this achieved?

In Ithkuil there are two main classes of words - formatives and adjuncts. Formatives function as nouns or verbs, adjuncts convey additional information about formatives and sometimes mimic the personal pronouns. Let's focus on formatives: each one consists of a root, which carries main information about the meaning of the word (like, for example, "oral sound"), which then can be inflected by over 20 different grammatical categories using numerous affixes. For example, the root for "oral sound" (-l-) can be inflected by adding "e-" in front -> "el-", making it "spoken utterance". To get the smallest possible word, we need another vowel and a consonant -> "elal". "a" marks the Oblique case, which is pretty neutral. "-l" on the other hand means that we are speaking of a single object, functioning as a separate whole, we mean it in its entirety and as a concrete object and not its mental representation. This way, "elal" can be translated just as "spoken utterance".

(more…)

Calculating sunrise and sunset times

Today is the winter solstice - the shortest day in the year and the longest night. It is not a well-known fact, though, that although the days will only be longer now, the Sun will still rise a bit later. It is caused by the shape of the Earth's orbit, which is not perfectly round, but elliptical. The Earth will reach its closest point to the Sun in a little while, and it also moves faster than usual because of that. This in turn delays the solar noon by a few seconds each day, causing the times of sunrise and sunset to be later and later.

When is the latest sunrise and the earliest sunset, then, if not on the day of the solstice? I could probably check somewhere on the internet, but why should I, if I can calculate it myself with my computer ;)

I chose Haskell for the task - mostly because I still don't grok it, and I think it is a very interesting language that changes the way one thinks. I decided then to exercise it a bit.

(more…)

Differential geometry in Rust

During the last few weeks I've been working on a library that would let the user do some differential-geometric calculations in Rust. By differential geometry I mean mostly the tensor calculus in curved spaces or space-times. I've already created something like that in C++, but I wanted to try and use some of the Rust features to create an improved version.

What could Rust do better?

The most convenient representation of tensors for doing calculations is in the form of arrays of numbers. The problem is that representing a tensor numerically requires choosing a coordinate system. Various operations, like for example addition of two tensors, only make sens when the tensors involved are expressed in the same coordinate system. The only possibility of enforcing this rule in C++ was to encode the coordinate system as a property of the tensor object and checking for compatibility in the operator code. This way any errors will be detected at runtime.

Ok, so the errors were detectable, so what could be done better? Well, for examples the tensors expressed in different coordinate systems could not only have a different value of some property, but be objects of different types. This way the error can be detected at compile time, before the program is even translated into an executable form. It wouldn't be very practical in C++, but the Rust type system allows to do it quite interestingly.
EDIT: It has been brought to my attention that C++'s templates also allow for this kind of thing. Nevertheless, doing it in Rust was a fun experiment :)

(more…)

Generic arrays in Rust


Recently, I decided to try and "translate" the black hole simulator into Rust as an exercise. Initially I wanted to create a library implementing differential geometry, like tensor calculus, metric etc. I quickly encountered a problem.

Rust and arrays

Tensors are objects with some constant number of coordinates, depending on the dimension of the space they function in. For example, in an n-dimensional space, vectors have n coordinates, rank-2 tensors have n^2 etc. Arrays are perfect for representing such objects.
Rust handles arrays without problems. An array of N elements of type T is written in Rust as [T; N]. Everything would be fine, except for one tiny detail - I would like my code not to depend on the dimension of the space.

The problem

It is possible to define so-called generic types in Rust. They are datatypes that have internal details parametrized by some other type. For example, we could easily create a generic 3-dimensional vector:

What if we wanted to create an n-dimensional vector, though?

Nope. You can't express an integer type parameter in Rust.
It looked hopeless, but I accidentally stumbled upon some code that suggested the existence of a solution.
(more…)

Rust version has caught up to the C one

It took a while, but the Rust version of the code generating the positions of galaxies has finally reached the level of functionality of the C version. Meanwhile, I have gathered quite a bit of interesting experience, which I'm now going to share.

Rust vs other languages

Programming in Rust is nothing like programming in any other language I've had contact with (which means mainly the C family and Python). One remotely similar experience was experimenting with Haskell, but even that generally due to incompatibility between my intuition and the language (although Rust has many functional features, but as will be mentioned later, one shouldn't overuse them...).

(more…)

Progress of the Universe project

I made some progress in rewriting the Universe project in Rust during the last few days.

Before I started with the project itself, I had to make some preparations. The order of magnitude of the numbers appearing in the program caused the need for the GMP and MPFR libraries, allowing for calculations on arbitrarily big numbers. I also used the xxhash algorithm. The problem? All 3 pieces of code were written in C.

It's not actually that big of a problem, since one of the advantages of Rust is the ease of using it with C libraries. The only thing to do was to find or create modules (or, in Rust terms - crates) which would make it more straightforward, so I started searching.

I focused on GMP and MPFR first. There were 2 crates for GMP and one for MPFR, created by the author of one of the GMP crates. After having a look at them I decided that the GMP module without corresponding MPFR one is more straightforward to use, which left me with the task of writing my own crate for MPFR. Moreover, the GMP module was old and didn't even compile with the latest version of the language.

I started working. Fixing the GMP crate turned out to be tedious, but not very hard. Writing the MPFR module was similar, but needed a bit more work (like writing many similar functions that only served to call their C counterparts...). Both modules are available on GitHub (click, click). I created a pull request for the author of the GMP crate, but he turned out not to be interested in maintaining the project any longer.

Then it was time for xxhash. Here, like with GMP, a crate existed, but it didn't compile. A few hours of work later everything was fixed and the library worked.

So, now I have working dependencies for the project. I also started to rewrite the code of the project itself, but for now only a small part of it is done. More news about the project progress - (hopefully) soon.

Thoughts about light bending

I had a sudden moment of clarity recently when thinking about how to remove a graphical artifact from the Black Hole Simulator.

The problem

artifact

The current simulator has one ugly aspect of the rendered image. Exactly 90 degrees from the direction to the black hole a graphical artifact appears - a strip of smudged, incorrectly calculated pixels (see the picture to the right). The reason is hidden deeply in the rendering mechanism.

In short, it looks like this - you can't efficiently calculate the color of every pixel by raytracing. Taking advantage of the symmetry of the Schwarzschild black hole, I created a table of angles of light deflection. Thanks to the symmetry, I can describe each ray of light by only one parameter - simply put, the minimal distance from the black hole along its path (actually, the impact parameter). To calculate the deflection, I need one more thing, and that is the distance from the black hole at which I send/receive it - the greater part of the whole path the ray has to travel, the greater the deflection.

Such a table was being sent to the graphics card. Then, during rendering, a direction of the ray was calculated for each pixel, and this was converted into the impact parameter. The distance was known independently. Appropriate deflection was being read from the table and this was used to calculate the color of the pixel.

In theory everything is fine, but one problem appeared - the light rays sent in directions close to 90 degrees from the black hole have very similar impact parameters. This gives nearly identical deflection angles, which makes many pixels the same color. An ugly strip appears.

(more…)