Friday, 11 July 2014

Part IV in the Trilogy of Scientific Research

After over a year of silence, the story continues! Where are they now... deep inside a 150g box of Roses. (A rose by any other weight...) Three boxes matched this pattern consistently:

* 1 Chocolate Bliss
* 1 Hazelnut Praline Crisp
* 1 Strawberry Cream
* 1 Classic Fudge
* 1 Chocolate Supreme
* 2 Caramel Deluxe
* 1 Orange Chocolate Delight
* 1 Hazelnut Whirl
* 1 Turkish Delight
* 1 Vanilla Butter Caramel
* 2 Peppermint Cream
* 1 Cherry Heaven

We also have an unusual case of a statistical outlier. With some research into two 450g boxes, one perfectly matched the distribution from last episode, but the other had one extra Turkish Delight! Apparently the Cadbury authorities approve of our research, sending us a bonus of the best type of the entire set. Close with a Looney Tunes style focus on the FIVE Turkish Delight in a lovely small pile!

Friday, 9 May 2014

Christianity and physics

I came across a new blog recently, written by a man whose username is "Salt and Light": naclhv. He posts about Disney's "Frozen", about physics, about Christianity and salvation, and the future of science. Makes for great reading... go have a look!

What I want to focus on here is his predictions about science, based on a Christian world view. Among other statements, he declares that people are special - that we're more than just bags of chemicals or sophisticated neural algorithms. I want to go one further: This universe was built for people to observe. Yes, this entire universe has us as its focus - we are the pinnacle of God's creation, and as such, we are central to everything that this world, this solar system, this galaxy, this universe, has to show us. The heavens declare the glory of God, but it's to us, and not to animals or rocks or computers, that they declare it.

(Caveat: I am not a scientist, and some of the details of the science here may be wrong. Most of my "research" has just been reading Wikipedia. This is not meant to be a scientific analysis, but a philosophical one.)

What does that mean for science? Start with the well-known double-slit experiment: whether something's a wave or a particle depends on whether you're looking or not. Even more so, it's possible to "un-observe" between when the equipment sees something and when a person does. That is to say, it's not enough for a photon to pass through a known location based on which slit it went through; that state has to be collected and understood by a person.

In theory, it should be possible to construct an experiment in which the which-way information can be observed by a human, or by a monkey, or by a rock, or by a computer - and that, in each case, the other three entities will be unable to know which slit the photon went through. I predict that a human seeing something will collapse the quantum state, but the other three will not. That is how we are special: it is only a human's observation that "counts". Yes, this is a bald claim without any scientific basis. I might be proven wrong, but that's what science is all about anyway - make a prediction, see if you're right :)

This is similar to how virtual worlds are often built. Ray-tracing would be infinitely complex if every photon of light were simulated, so instead the simulation works backward, seeing what could possibly reach the observer (camera). In a MUD, it's common to represent connected users (observers) as primary references, and then quietly drop from memory anything that isn't referenced (directly or indirectly) from one of them; so, for instance, the room you're sitting in has to exist, because you can see it, and objects in that room have to exist in order to compose that room, but an art gallery with nobody looking at it (that's most of them, right?) could be flushed from memory and loaded the next time someone walks in. Maybe this universe is the same - if nobody's looking at that particular photon, it doesn't bother to collapse it, but if someone is, well, it needs to properly exist.

Adam's sin cursed the entire universe; if there were anything else as important as we are, then it'd be horribly unfair on it/them to have been tarred with our brush. We're not simply the next evolutionary level after monkeys, and we're definitely not just another evolutionary step along the way to an even better type of being; we are the masters of this universe. This isn't man's universe, but it's a universe for man to be king of; and it would make logical sense for the universe to take some shortcuts when it won't affect its king.

Maybe I'm right, maybe I'm wrong (more likely, a combination of both); but this is what my understanding of God leads me to expect of the universe, and that, at its heart, is science.

Wednesday, 29 January 2014

Installing Google Chrome on Debian Jessie

Today I installed the latest unstable Debian Linux (Jessie) on one of our computers, in order to be able to use a particular flat-bed scanner (needed a newer version of something than Debian Wheezy ships). That part worked beautifully, but as this is a workstation, I needed to install Google Chrome - which didn't, because of a dependency problem: Jessie ships libudev1, Chrome depends on libudev0.

So far, it appears that Chrome will run just fine with libudev1, which means that this is all that's necessary to run Chrome on Jessie:
Section: misc
Priority: optional
Standards-Version: 3.9.2
Package: libudev0
Version: 147
Depends: libudev1
Description: libudev0 dummy for Google Chrome

Run that through equivs-build (from the 'equivs' package), then install the resulting package. Chrome will then install (you may need 'sudo apt-get -f install'), but not run. Then locate libudev.so.1 (in /lib somewhere - for me, /lib/x86_64-linux-gnu/libudev.so.1) and symlink it to libudev.so.0:
sudo ln -s /lib/x86_64-linux-gnu/libudev.so.{1,0}

Et voila! Chrome working with Jessie.

Friday, 3 January 2014

RosMud version 1.7.0 - and probably last

Now that Gypsum has launched (see previous post!), I don't feel bad about not having released a new RosMud for a while. Today's release marks seven years of the project, and picks up the changes done in the last 18 months - namely, not many. One small bugfix and one small feature enhancement to the TinyURL plugin, and that's it. RosMud++ is now a working, stable product, and I'll support it for as long as is practical in terms of technical assistance and maybe bug fixes, but I'm not going to add major new features to it. Gypsum is where it's at, now!

Gypsum: New MUD client!

For some time I've been working on the official successor to RosMud. Seven years after RosMud started (to the day), I can now proudly announce version 1.0 of Gypsum!

Gypsum is intended to "feel right" to RosMud and Gmud users, and like them, it runs on Windows. Unlike them, though, it also runs and is officially supported on Linux and Mac OS (note however that Mac support is dependent on Mac testers, so I can't currently guarantee that everything works). Gypsum is open source and easy to work on, so new features can be added efficiently.

Why use Gypsum?
* Infinite scrollback (like RosMud, and unlike Gmud)
* Idle killer (ditto) - maintains a connection even when your router would kick you off, but doesn't disrupt the server's notion of idle time
* Can be updated without disconnecting from the server
* Inbuilt URL shortener will intelligently handle a number of easily-shortened addresses, and pass the rest on to TinyURL
* Comes with a character sheet engine for Dungeons and Dragons
* Handles statistical analysis and party loot splitting automatically
* Can tune out annoying people on OOC channels (Threshold RPG specific)
* Includes a pop-up editor (needs some server-side support, ideally)
* Supports simple aliases; more complicated ones (eg regular expressions) may be implemented later if there's demand
* Inline calculator: put an expression into your commands and have it evaluated, eg "say Six times nine is $[6*9], not 42!"
* Auto-synchronizing clock showing Threshold game time

For RosMud users, this is mostly "RosMud for Linux/Mac", and doesn't offer a huge number of cool features yet. But that'll change!

Download Gypsum v1.0.0, or download the most current version, or clone the repository with git clone git://github.com/Rosuav/Gypsum.git - the latter is the easiest way to keep up-to-date, if you're familiar with git.

You will need a Pike interpreter. Try your package manager first, if you have one; otherwise try pike.lysator.liu.se for your platform.

If you need help, find me on Threshold RPG - the trivia channel is perfect for this.

Tuesday, 31 December 2013

About Python 3: A response

This is a response to Alex Gaynor's blog post of similar subject line. I have to say, Alex's information is showing a very strong inherent bias toward Py2-binding. When scripts have minimal dependencies, it's really easy to switch them across, and it's often not hard to make a single codebase that will run on either Py2 or Py3.

On most Linux installations, the 'python' command will run Python 2, and Python 3 has to be called for explicitly with 'python3'. Yes, this may make it look like Py2 is the standard and Py3 is the upstart, and it means that a lot of code that's compatible with both versions will be running under Py2, both of which make it look like we're not using Py3 all that much yet. But that's just skewed stats, not reality. Alex claims that "almost no code is written for Python 3", and while that may be true in his own personal experience, it's definitely not true of the whole world.

Alex then makes two points, which I shall juxtapose. "Why aren't people using Python 3? ... lack of urgency" and "Here's an idea: let's release a Python 2.8". The problem here is that that's the exact attitude that creates the lack of urgency. Here's an alternative idea: Let's NOT release a Python 2.8, so that there really will be no new features in the 2.x line. And let's keep on releasing cool new features in 3.x (how about an async I/O package, support for enumerations, and a library of statistical functions, that's a good start), so there's a strong incentive to switch.

I do understand that it's hard to switch. For someone who's grown up thinking that a character is a byte and that ASCII is all we need, getting your head around Unicode and the need to distinguish what you work with from what you store/transmit does take some effort; but it's something you'd have to do anyway, the only difference is that Py2 lets you defer the distinction until you get a non-ASCII character but Py3 forces you to think about it up-front. Same goes for other changes - the Python 3 way is definitely better, or it wouldn't have been done; if anyone feels strongly enough that a change was wrong, then maybe a "from __past__ import" statement might be implemented. But I'd like to see a solid argument against any of the Py3 changes (I personally disagree with int/int -> float, since float is not a superset of int, but we have int//int -> int so it's just a matter of choosing the operator) - would make a great thread for python-list.

We live in a world, not a series of separate countries. It's high time we had Unicode by default - not "hey, look, this is a Unicode string over here, isn't it special", but "all text is Unicode, and we can also manipulate streams of bytes". Python 3 gives us that. It's high time Python 2 was treated as the legacy interpreter it is - all new code should be written with Py3 in mind. Yes, I understand that some people choose to support older versions of interpreters, for various reasons - I do it myself, in ways that sometimes warp my codebase somewhat - but that should be a conscious choice and not just "here's how to write Python code". Unicode 2.0 was released nearly two decades ago, so it's time to acknowledge that characters aren't bytes, and aren't 16-bit units either. Never mind about "bridg[ing] the gap" between Py2 and Py3 - leave the gap there, and jump over it.

Wednesday, 18 December 2013

Alice in Wonderland book with new illustrations

Regular readers of my blog will be at least faintly aware of my love interest, Alice Liddell. She's a lovely lady, smart and very interesting, and not afraid to take up a Vorpal blade against the Red Queen if the situation demands it. And anyone who's read the books will know the famous John Tenniel art, the iconic images that for many people define Alice.

But what if there were other images illustrating the book? And what if those images were put together into something so beautiful that you cherish it and pass it along to your children or grandchildren? An artist by the name of David Delamere has put together a set of paintings giving a somewhat different take on the art of Alice (though not as different as, say, American McGee's version!), and they're being put together into a book that promises to be something magnificent.

As I write this, there are two weeks to go on their Kickstarter project, from which you could get a copy of the book for $60. Yes, it's not cheap. This is not a basic paperback that you could pick up for $10 at your local bookshop, this is something made by people with a passion for quality. Plus, there's more than just the book in there; as the project has more than its baseline minimum to succeed, the artist and publisher are offering some extras with every copy of the book - check out what's included, as it may well change as time goes on (their $55,000 stretch goal is almost reached!).

It's strange for someone like me to be advocating a dead-tree book. Very strange. Normally I'd do everything electronically if at all possible. Why am I buying this book? Because it promises to be that awesome. Now go! Shoo! Check out that campaign!

http://www.kickstarter.com/projects/1954507197/alice-in-wonderland-book-illustrated-by-david-dela