Posts

Showing posts with the label google

Nexus 4 Red Light of Death

I've written a few times in the past about various poor or laughable customer experiences I've had when dealing with technology and the companies making or retailing them.  Things usually work out well in the end of course as we're well protected as consumers here in the UK.  However, when my Nexus 4 went wrong late on Saturday night I thought I was in for another world of pain, I couldn't have been more wrong.

The short version of this post is that my phone died late on Saturday night.  On Sunday morning I raised a support call.  By Tuesday morning I had a brand new phone in my hand, delivered to my door, all under warranty.  I need not have worried it seems, Google appear to have customer support really very well sorted out.  I only wish the vast array of companies out there who are terrible to deal with would learn the lessons of having satisfied customers even when things go wrong.

The slightly longer version of the story is that my phone completely ran out of charge on Saturday and when I went to plug it in for an over night full charge before going to bed, I noticed the LED was solid red.  I've never seen this before but left it for a few hours and tried turning it on, nothing.  I left it on over night and it still wouldn't turn on the next morning.  I tried a few other things, like a separate wall outlet and another charger and cable but still all I got was a solid red light and no ability to boot the phone.

I phoned Google at 10am on a Sunday in the hope that they ran a call center on Sundays or that I would be connected to an international person who would be able to help.  I think that's probably what happened as it was an all-American experience from start to finish.  Benjamin answered the phone, asked me some questions and got me to do a couple of things with the phone, it was still dead.  He was first class, easy to understand and took ownership of the issue straight away, I can still email him directly about the problem now.

After Google support (Ben) realised the phone was dead, there was no quibble, no problem, no hoops to jump through.  He told me that he'd send the issue through to the warranty department, they would send me an email with how to order a new phone and when I receive it I should send back the old one in the same packaging (standard practice for the tech industry).  We parted company, and I'm thinking this is all a bit too easy and something will go wrong later.

A couple of hours later, I get an email from Google warranty.  It has a link to click which allows you to order a new phone at no cost (the link is only live for 24 hours).  I set about ordering the phone, it was Sunday night by this time.

8:30am Tuesday morning and Parcel Force knock at the door and deliver my new phone.  Inside the package is a return envelope, exactly as described by Ben at Google and exactly what the warranty email said would happen.  I printed the RMA note attached to the email, packaged everything up and it's ready to go back to Google - we're still less than 5 days from the start of the issue at this point.

Quite simply, brilliant.  I thought I should say so (or more so).

So would I buy a new Google hardware product again?  You bet I would.  Software updates come regularly, I'm always at the latest Android level (unlike the Transformer Prime tablet we have in the house which is stuck on 4.1 because Asus dropped support after little more than a year), I don't suffer from the Apple single vendor lock-in issue, and now to top it all off it seems the warranty support is first class.

Nexus 4

This post could as easily have been titled "buying my first mobile phone".  Yes, it's 2013 and I've just shelled out for my first ever new mobile phone, buying the Google/LG Nexus 4 so I thought I'd put something down about switching phones.  Prior to this as regular readers will know, I had an HTC Desire (which was actually a work phone), before that a Nokia N73 (which I bought second hand from eBay).  So I don't have a particularly prolific phone history, I tend to wait for what I want after researching long and hard and buying something that will last me several years (I'd say I change every 3 years or so).  With the price and feature set of the Nexus 4 as they are, it was a no-brainer next move for me so after the early rush on stock saw them getting sold out everywhere I waited and ordered when they came back in stock (on Feb 4th) and took delivery the very next day in spite of the 2 week wait Google were advertising for delivery.  Having had the phone a couple of months now, I'd say I've got used to it so now seems like the right time to talk about it.

So why the move to a new phone this time?
Basically, it wasn't at all driven by the Nexus 4, it was all about the HTC Desire.  I had been running non-standard firmware versions on it for quite a while and got fed up of the various instabilities in them, or out of date Android versions (for the more stable versions) but the real sticking point of the HTC Desire is that 150MB user space for apps.  That was OK back in the day, when apps were small and relatively few and far between in Android.  However, it quickly became far too little and I was either constantly battling to have the minimal set of apps I needed installed or copying them out to SD card in a custom firmware and suffering the slow-down consequences of doing that.

OK, so I decided I needed a new phone but why the Nexus 4?
Price.  Simple.  End of.  Having been lucky enough to have had the HTC Desire since it first came out, I've been used to a high end smart phone for quite a while.  A lot of the cheaper phones on the market today aren't really much better than the HTC Desire even now, so I needed to look high end.  Obvious choices were other top notch phones from HTC or perhaps a move to Samsung for the Galaxy S3.  However, looking at the high end market as it is right now, you just can't beat the Nexus 4 for "bang for your buck".  It's a high end phone offering all the features of the S3 and other similar phones but at a whisker over half of the price, so no contest.

What do I like about the Nexus 4?
I'm going to split this into two parts.  Software and then Hardware.

Well it's Android, and being a Google phone it's a bang up to date version too.    I can still use all the same apps I know and love from the HTC Desire (with the odd change of widget here and there as I've moved away from HTC Sense, obviously) but now I can have them all installed at the same time and running and comparative speed.  There are three things that come to mind when talking about the software differences.  First, the gesture typing keyboard seems really quite adequate to me; I was a Swype user before now but I've not even been remotely tempted to install Swype on the Nexus 4 as the gesture typing from Google more or less exactly replicates the experience with a few subtle differences.  Second, Google Now really does seem very clever indeed; within a couple of days it had worked out where I live and where I work so I get traffic updates before I make the journey; I get similar information if I've travelled somewhere I don't usually go; recently on holiday in Spain, Now welcomed me with local weather information, an estimate of the time back to the airport, a list of local restaurants and attractions, etc.  Third, the camera software completely blows me away; yes there's the photosphere camera which is a nice toy but the in-built ability to do time lapse videos, HDR pictures, panoramic pictures (which get stitched automatically) as well as all the various scene modes, editing facilities, location and social functions they've put in the app make it absolutely first class - my two cameras (a compact that is a few years old and an SLR) get absolutely nowhere near this level of functionality.

Hardware wise, the tech specs speak for themselves being dual core, 2GB RAM, nice screen, camera, etc.  Speaking of camera, I've been particularly impressed by the quality of the pictures and video from it against what I had before with the HTC Desire in addition to the camera software I've already talked about.  I could go on and on about what I like, the list is really long since it's more or less bigger, better and more powerful than the HTC Desire as you'd expect being released 3 years later.

So what's not to like?
If I was an Apple fan-boy I'd say "it's not an iPhone" but more seriously there are probably two downsides that I can think of.  You know it's coming... battery life.  Until humankind invents a more compact version of storing more electricity then battery life is always going to suck.  I can get 2 days from the phone with light usage but under heavier load I can get 1 day out of it.  The other thing is the size.  Preferably, I'd like to be able to break the laws of physics somehow and have a phone with a gorgeous massive screen that is absolutely tiny, unrealistic at the moment.  It is bigger than the HTC Desire and I would say, while thin, is still quite a large phone.

Google Treasure Hunt Question 4

Question 4 has been out for a while now and it's taken me a while to blog the solution for a couple of reasons, I've not had much time to work out the solution recently, and this question seems a lot more difficult than the other three (for me at least).

Here's my question this time around:
Find the smallest number that can be expressed as
the sum of 25 consecutive prime numbers,
the sum of 99 consecutive prime numbers,
the sum of 189 consecutive prime numbers,
the sum of 467 consecutive prime numbers,
the sum of 535 consecutive prime numbers,
and is itself a prime number.

For example, 41 is the smallest prime number that can be expressed as
the sum of 3 consecutive primes (11 + 13 + 17 = 41) and
the sum of 6 consecutive primes (2 + 3 + 5 + 7 + 11 + 13 = 41).


First of all I thought I'd write a routine (once again in Perl) to generate prime numbers. I know I'm not entering a competition to find the worlds largest primes so chose to write an optimised solution rather than a super efficient one. The difference here is computational complexity v coding complexity. I chose the simpler code but less efficient solution rather than the more complicated code but efficient solutions offered by algorithms such as the Sieve of Eratosthenes.

sub primes {
my $max = shift || 10;
my @primes = ( 2, 3, 5, 7 );
return @primes if ($max <= 9);
my $loop = 9;
while (scalar(@primes) < $max) {
my $is_prime = 1;
for (my $div = 3; $div < ($loop-1)/2; $div++) {
$is_prime = 0 if ($loop % $div == 0);
}
push (@primes,$loop) if ($is_prime);
$loop += 2;
}
return @primes;
}


Now I had a way of populating an array with prime numbers I thought about the solution a bit more carefully and decided it wasn't likely to be simple to calculate, however long the code I managed to write was. So, I decided to search around for lists of prime numbers and decided to use a list of the first million primes. I could, on reflection, just used my routine to generate 1 million primes and written them to a file instead of generating each time.

The solution I came up with is shown below. It starts by populating an array with the first million primes from the downloaded file. Then the sums of the required continuous number of primes are generated and stored in another array. At this early stage, the solution is now contained in this array (with the assumption the solution exists within the first one million primes of course) so it's just a case of searching the array to find it. In order to find the number, I numerically sort the list. Now it's a simple case of finding the first (and therefore lowest) prime in the new list that is repeated 5 times.

use strict;
use FileHandle;

sub sum_primes {
my $amount = shift;
my $start = 0;
my @sums;

while ($amount < scalar(@_)) {
my $sum = 0;
for (my $i = $start; $i < $amount; $i++) {
$sum += $_[$i];
}
push(@sums,$sum);
$start++;
$amount++;
}
return @sums;
}

sub read_primes {
my $filename = shift;
my $fh = new FileHandle;
$fh->open($filename) || die "$filename: $!\n";
my @primes;
push(@primes,split) while (<$fh>);
$fh->close();
return @primes;
}

sub is_prime {
my $num = shift;
foreach my $prime (@_) {
return 1 if ($num == $prime);
}
return 0;
}

my @primes = read_primes("1000000.txt");
my @sum_list;
push(@sum_list, sum_primes(25,@primes));
push(@sum_list, sum_primes(99,@primes));
push(@sum_list, sum_primes(189,@primes));
push(@sum_list, sum_primes(467,@primes));
push(@sum_list, sum_primes(535,@primes));
@sum_list = sort(@sum_list);
my $prev = 0;
my $same = 0;
foreach my $num (@sum_list) {
if ($num == $prev) {
$same++;
if ($same == 4) {
print "Found $num, checking... ";
if (is_prime($num,@primes)) {
print "PRIME! :-)\n";;
last;
} else {
print "not prime :-(\n";
$same = 0;
}
}
} else {
$same = 0;
}
$prev = $num;
}


This code takes a few minutes to run. I'm sure it's not the smartest solution to the problem, there must be some maths I can use to calculate a solution. Instead, this approach turns the problem into a search solution but it works pretty well and identified the correct answer of 6990493 for my question.

Google Treasure Hunt Question 3

I've been keeping up with the Google treasure hunt as a bit of fun rather than seriously going after any prizes. At least one other guy at work has been joining me, Nick O'Leary has taken up the challenge too. Question 3 was recently released, and while I thought it might possibly present the greatest challenge yet on first inspection, it turned out to be really rather trivial.

So question 3 is all about IP routing, and tracing a packet route around the network. I was expecting some hardness built in around working out subnet masks, but there was none of that at all, just a simple route to follow resulting in an 11 node path. The question then:

Below is a diagram of a computer network. The nodes are hosts on the network, and the lines between them are links. A packet is sent out from host G with a destination of 201.89.136.112. Which nodes does the packet pass through on its way to the destination? (include start and final node in your answer)



You are then shown a routing table and must trace your way through it from the start node to the end node recording the path taken along the way. This is a solution that is quickly manually traceable since no node should be visited twice (unless Google have given you some really badly designed network).

Having said about the simplicity of this one, I managed to get it wrong the first time around by starting at the wrong node. Reminds me of maths teachers constantly saying "Always Read the Question!". Once I screwed my head on the right way around I correctly answered GFIHDLOPABC for my network.

Google Treasure Hunt Question 2

After solving question 1 successfully I decided to plod on and answer question 2 as well. It was, for me at least, far less challenging than the first question.

This time, you are generated a set of files with random directories and file names that you are asked to download and process. Once I got passed the immediate suspicion of downloading a zip file (for fear of viruses) it took no time at all to whip up a solution. My question was:

Here is a random zip archive for you to download:
GoogleTreasureHunt08_15866755520722619948.zip

Unzip the archive, then process the resulting files to obtain a numeric result. You'll be taking the sum of lines from files matching a certain description, and multiplying those sums together to obtain a final result. Note that files have many different extensions, like '.pdf' and '.js', but all are plain text files containing a small number of lines of text.

Sum of line 4 for all files with path or name containing BCD and ending in .pdf
Sum of line 5 for all files with path or name containing mno and ending in .rtf
Hint: If the requested line does not exist, do not increment the sum.

Multiply all the above sums together and enter the product below.
(Note: Answer must be an exact, decimal representation of the number.)


Again, my solution was Perl based and generated a correct answer of 364264342 for my particular zip file:
#!/usr/bin/perl -w
use strict;
use File::Find;
use FileHandle;
my $total1 = 0;
my $total2 = 0;
find(\&wanted, ("/home/gwhite/GoogleTreasureHunt08_15866755520722619948"));
print $total1*$total2."\n";
sub wanted {
return if (-d $File::Find::name);
if (($File::Find::name=~m!BCD!i) && ($File::Find::name=~m!\.pdf$!i)) {
my $fh = new FileHandle;
$fh->open($File::Find::name) || die ($File::Find::name." Oops: $!\n");
while (<$fh>) {
last if ($fh->input_line_number>4);
chomp($_);
$total1+=$_ if ($fh->input_line_number==4);
}
$fh->close();
}
elsif (($File::Find::name=~m!mno!i) && ($File::Find::name=~m!\.rtf$!i)) {
my $fh = new FileHandle;
$fh->open($File::Find::name) || die ($File::Find::name." Oops: $!\n");
while (<$fh>) {
last if ($fh->input_line_number>5);
chomp($_);
$total2+=$_ if ($fh->input_line_number==5);
}
$fh->close();
}
}

Google Treasure Hunt

I've just discovered today (rather late I know) that Google have released a treasure hunt which is quite interesting. It's not what you might think. Given the name, I would have guessed it involved using the google search engine to find things on the Internet. However, it's actually a problem solving challenge where they pose questions and you submit your answer. I think question 2 is due out today (they obfuscate when the next question will be released), nobody seems to know how many questions there are, exactly how long this will go on for, etc. But there is a prize for "the first person to answer all the questions correctly" whatever that means.

A word of warning, don't read the rest of this if you want to work out the answer yourself!!!

My question number 1:
Google Treasure Hunt Q1
A robot is located at the top-left corner of a 65 x 61 grid (marked 'Start' in the diagram above)*.

The robot can only move either down or right at any point in time. The robot is trying to reach the bottom-right corner of the grid (marked 'Finish' in the not to scale diagram below).

How many possible unique paths are there?
(Note: Answer must be an exact, decimal representation of the number.)


The problem here is the vast number of different routes that can be taken, which would overflow 32 bit computers for numbers this size. My (correct) answer was 1426507627253102510231886503468838531 which I calculated using the formula (x+y-2)! / ((x-1)! (y-1)!)

A few simple lines of Perl later and I had the answer:
#!/usr/bin/perl -w
use strict;
use Math::BigInt;
# change these to match your X & Y grid size
my $xgrid = 61;
my $ygrid = 65;
my $x = Math::BigInt->new($xgrid-1)->bfac();
my $y = Math::BigInt->new($ygrid-1)->bfac();
my $z = Math::BigInt->new($xgrid+$ygrid-2)->bfac();
print $z->bdiv($x->bmul($y))."\n";