Real number approximations in finite space with IEEE 754

Jeffrey Quesnelle

Computer systems often need to represent real numbers as a part of their operation, but how to encode these numbers in fixed, finite space is non-trivial. If the size of the variable in question is bounded then so-called fixed point arithmetic can be used, treating both sides of the decimal point as integer values. In general however it would be useful to have a more flexible method of representing values that can hold both $10$ and $10^{-9}$ in a small, fixed amount of memory.

The current base ten number system is a relatively new invention [1]. We may take for granted that there is a well-defined way of writing down numbers (with only terminating reals having non-unique representations) but the problem of representing an arbitrary real number in fixed space (say, in computer memory) raises several interesting tradeoffs between precision and accuracy; we give an extremely abbreviated overview of the most popular method of representing reals in computers: IEEE 754.

IEEE Standard for Floating-Point Arithmetic (IEEE 754-2008 or simply 754) is the internationally accepted method for performing operations on and transmitting approximations of reals on computer systems. The key property of 754 is that the decimal point “floats”, i.e. if a number is very large or very small the decimal point can be “moved around” so that most bits are used to represent the significant digits of the number. Compare this method to fixed point arithmetic which has a bias towards numbers closer to zero; in 8.8 fixed point math (8 bits for whole part, 8 bits for fractional part) the number $2^{7}$ is represented as $1000 \; 0000.0000 \; 0000$ and $2^8$ cannot be represented at all, even though both numbers contain only one “significant digit”!

Continue reading “Real number approximations in finite space with IEEE 754”

nds4droid release 46

Hey there boys and girls, how about an nds4droid update for the holidays? As always it’s on Google Play and sourceforge. Your changes:

  • Added a soft options button that will open the options menu. This will allow new devices that don’t display the options compatibility bar to access the options.
  • (Hopefully) fixed a bug that caused excessive battery drain when minimized on devices with buggy OpenSL ES drivers (reported by LG Korea)

Automotive Ethernet: The Definitive Guide

ETHERNET-GUIDE-2I’m excited to announce my first real published work! Automotive Ethernet: The Definitive Guide is a comprehensive guide to the developing world of Automotive Ethernet. For the past twenty years most automotive networking has relied on CAN bus to move information around the car. CAN is quickly outgrowing it’s usefulness though, and the industry is now shifting to using Ethernet. I wrote this book along with several others at my company, and it will be available on October 20th, 2014 as an eBook from Amazon, and the physical version will be available soon after. Enjoy!

 

Using emscripten/WebGL to run a Nintendo 64 emulator at full speed in most games with Firefox

I recently spent some time learning emscripten, the LLVM-to-Javascript compiler and decided that porting mupen64plus, the popular Nintendo 64 emulator, would be a good test of its features. Took a bit to get right, but you can checkout the code and a working demo of it here: http://jquesnelle.github.io/mupen64plus-ui-console/ (Requires Firefox unfortunately for now)

Setting up a man-in-the-middle device with Raspberry Pi, Part 1

I recently purchased that most marvelous of devices the Raspberry Pi and naturally my thoughts turned to the nefarious given its cheap price and small package. I decided to attempt to create a man-in-the-middle device that could be discreetly attached to a remote network and could redirect and sniff traffic. I’m only a very novice Linux user so it took a bit of learning to wrangle man pages as well as some intrepid Google-fu, but I’m going to document how I was able to turn this tiny device into an evil packet-sniffing machine. Continue reading “Setting up a man-in-the-middle device with Raspberry Pi, Part 1”

nds4droid release 45

Got an e-mail recently from someone having problems running nds4droid on an NVIDIA SHIELD so I’ve made a couple of updates that should ease the pain for those of you using these newfangled console-like devices. You can as always find it on Google Play and sourceforge. Bullet points:

  • Changed the default key mapping to open the options menu to “KEYCODE_BUTTON_START.” This should be a better default for controller-based systems like the OUYA or the NVIDIA SHIELD. It will require a full reinstall of the app for this default to take effect.
  • Added the ability to access the settings screen from the ROM browser options menu.
  • Enabled compatibility for devices without a touchscreen.

nds4droid release 43/44

EDIT: I have pushed a fix (release 44) for those who couldn’t access the menu in release 43.

Reports of my death have been greatly exaggerated. As proof, I present to you nds4droid release 44! As expected it’s on Google Play and sourceforge. The changes:

  • Minor performance enhancements
  • Added a setting to disable the auto-scanning ROM browser (default to the old file browser)

Gone Home is what video games were meant to be

Most of this blog is spent posting about my pretty popular Nintendo DS emulator, nds4droid. 3.5 million can’t be wrong (this is of course not true), but between working on it and playing obsessive amounts of Counter-Strike: Global Offensive, I don’t have time for too much else. So, if you’re just here for nds4droid, bear with me a bit why I explain why a new game, Gone Home had such a profound impact on me. Continue reading “Gone Home is what video games were meant to be”

nds4droid release 41

Got another nds4droid release for all you starved souls out there! As you know, it’s up on Google Play and sourceforge. What you get:

  • Minor performance enhancements
  • Fixed a bug where rotating the display would cause the autosave timer to reset

Also, I wanted to clear the air a little bit here about the whole DraStic situation. It’s true that in the past I’ve been critical of other DS emulators such as DSoid — but this was not because I wanted people to use my emulator (in truth, why do I care, I make $0 off nds4droid). The reason was because the developer was actively stealing code (DeSmuME) and profiting off of it. DraStic is another story, it’s written by a brilliant developer (Exophase) from scratch, and he has every right to do with his code as he pleases. Do I wish he open sourced it? Sure. In fact, this is just my guess, but imagine that at some point in the future he will (he just seems like that kind of guy). I don’t, and no one else should, view it as an us vs. them thing.

When I set out to write nds4droid, it because there wasn’t a viable open source DS emulator available for the Android platform. In reality, I don’t have the time (or, to be honest, the intimate knowledge of the DS internals) to write the emulator from scratch. But I do have an expertise from my job in porting native code to Android, as well as writing regular Android UI code. When I was growing up, I used tons of free emulators and benefited from other people’s free labor. So, since I was in a position to be able to pay back this good will, I did it. This is the reason I didn’t charge for it or put ads in — I’ve certainly used tons of free apps, so I just viewed this as my turn to give back.

In conclusion, I harbor no sort of ill will or view DraStic as a bad thing (the only thing Exophase ever did to enrage me was make the gpSP dynarec a nightmare to debug!). If it makes sense for you — use it. If it doesn’t, don’t. And quit the flaming :).