This is about scientific notation, and how Gnome Calculator still doesn’t do it correctly.
So I was checking a simple calculation today, and couldn’t find a proper calculator, so I reached for gnome-calculator on the desktop. That was a mistake.
It seems to think that
which is not correct. It would, if I’d typed it as:
You can only get the right answer (1333.333…) if you type
so it’s clear that gnome-calculator isn’t apply the right exponentiation operator precedence when you hit ‘×10y’. It would have been so much better if gnome-calculator supported ‘E’ scientific notation (1.333E21 for 1.333×10²¹).
A bug is filed, but I don’t think I trust it any more.
I’m looking at having a proper calculator again, or maybe invest in one of the delightful tiny HP clones from SwissMicros.com.
Almost forgot that I had a barely-used HP 49G in the cupboard. It was barely used because the thing eats AAA batteries. Who knew that Dollarama would have a pair of NiMH AAAs for only $2?
Update, 2021: Use galculator instead. It does the right thing, and supports RPN like a calculator should. You don’t need to remember any precedence rules when you have The Truth.
I use Gnome Weather Report, an applet that shows the local temperature and weather conditions on my desktop. For the last few days, it’s been showing something really weird: . It’s nothing like -17°C here; it’s nearer 0°C, according to Environment Canada.
Things become clearer when you change the view to Fahrenheit view: . It’s clear that the sensor or protocol is broken, but is being mis-interpreted as a zero signal.
As an avid RISKS reader, I know that confusing zero and null values is pretty much unforgivable. I’ve wired up enough 4-20mA current loop instruments to know that having a zero-value signal being the same as a no signal value is bad.
But there’s no real risk here. I mean, I could always go outside and find that it’s not 17°C. You don’t need a weatherman, as Bob said.