Posts tagged "problem"

ActionScript Puzzler – Block Party!

Hi, everyone! It’s been a while, but it’s time now for another Puzzler! This time, we’ll do another ActionScript Puzzler! For those of you that don’t know what a Puzzler is, let me quickly explain. A Puzzler is essentially a short and simple programming problem that is used to demonstrate special cases or “features” of a programming language. See some of my old ones here, here, and here.

This time, I’ve decided to try something new. Rather than writing a blog post about it, I’ve made a video Puzzler instead! Watch below! And as always, feedback is always welcome!

If you like these video Puzzlers, let me know and I can do more! Or, if you prefer the blog-post style, let me know too. Until next time, happy coding!

Charles

ActionScript Puzzler – The Joy of Millisecs

Note: This is the same puzzler that was featured in the March issue of the Adobe Edge newsletter!

It’s about that time again…time for another Puzzler! I’ve written a few before, in a couple of languages too, but this will be my first in ActionScript! I know I have a lot of Flash readers, so hopefully this will be extra ‘puzzling’ for you (see what I did there?). For those that don’t know what a Puzzler is, it is essentially a short problem used to demonstrate special cases or “features” of a particular language. Here is the format:

  1. Code – I introduce the code
  2. Question – I pose a multiple-choice question and you guess what the outcome is…think hard!
  3. Walkthrough – I walk through a reasonable explanation
  4. Answer – I tell you the real outcome (it might surprise you), and explain why
  5. Moral – How can we avoid making mistakes like this in our own code

Now that we all know what a Puzzler is, here is a simple ActionScript Puzzler:

Code:

// declare key dates
var now:Date = new Date();
var birthday:Date = new Date(1940, 06, 27); // Bugs Bunny’s birthday!
 
// save them as milliseconds since epoch
var nowInMs:int = now.getTime();
var birthdayInMs:int = birthday.getTime();
 
// get the difference to calculate Bugs’ age in milliseconds
var millisecondsElapsed:int = nowInMs - birthdayInMs;
 
// sanity check
if (millisecondsElapsed == now.getTime() - birthday.getTime())
{
	trace("What’s up, Doc?");
}

What does this print?

  1. Nothing
  2. “What’s up, Doc?”
  3. Throws an exception
  4. None of the above

Walkthrough:

Alright, it looks like we are just trying to compute Bugs Bunny’s age in milliseconds, from the time he was “born” until now. First, we create the key dates. We have now initialized to the current date (as in the date this program is executed), and birthday initialized to Bug Bunny’s birthday. We then go and save those times as milliseconds since epoch so that we can easily do some date math with these two dates. Next, we calculate the difference of Bugs’ birthday (in ms) from now (also in ms) which should give us the total milliseconds elapsed since he was born. Finally, we do a sanity check. In the sanity check, we essentially duplicate the math we’ve done previously: calculate the difference from Bugs’ birthday until now, in milliseconds. This should obviously be true, and so we trace “What’s up, Doc?” to the debug console.

 

*SPOILER ALERT – ANSWER BELOW*


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Answer:

The answer is a – nothing! How does this happen? Well, we must be skipping over the trace statement. That would only occur if the sanity check fails. But the sanity check does exactly what is done earlier on in the code…almost! The key error in this code is that there is an implicit narrowing type-cast! Where is it? Let’s take a look at the description of the Date class in the ActionScript 3 LiveDocs. In the documentation for the Date.getTime() method, we get the following function prototype:

  Method Defined By
   
Returns the number of milliseconds since midnight January 1, 1970, universal time, for a Date object.
Date

Date.getTime() returns a Number! And we are storing that number in an int. In ActionScript, a Number uses the IEEE-754 double-precision floating-point specification, and therefore can use 53 bits to represent integer values. Comparing this to only 32 bits used by int and uint, we can see that Numbers can be used to represent values well beyond the range of the int and uint data types. Because of this implicit type-cast, our millisecond time gets narrowed and loses precision! Now, knowing this, it is easy to see why our sanity check fails. Our int variable millisecondsElapsed does not, in fact, store the total milliseconds elapsed since Bug Bunny was born, but rather, it stores the total milliseconds elapsed since he was born, truncated to 32 bits. Therefore, the sanity check fails, the if-statement falls through, and the trace statement never gets executed.

Moral:

Although in some other languages, implicit narrowing type-casts cause warnings or even compilation errors, in ActionScript, they do not. So, whenever you are storing or working with numbers, be aware of the size of the numbers as well as the data-types floating around. Implicit casts do occur (and often, in any language), but implicit narrowing casts will go unnoticed by the compiler, and likely by you as well…until now :)

That’s it for this Puzzler! Hope you enjoyed! Happy coding!

 

 
Charles

actionscript-puzzler-the-joy-of-millisecs.zip (source code)

C Puzzler – Give Me A Float

Time for another Puzzler! This time, let’s do a C Puzzler :) For those that don’t know what a Puzzler is, it is essentially a short problem used to demonstrate special cases or “features” of a particular language. Here is the format:

  1. Code – I introduce the code
  2. Question – I pose a multiple-choice question and you guess what the outcome is…think hard!
  3. Walkthrough – I walk through a reasonable explanation
  4. Answer – I tell you the real outcome (it might surprise you), and explain why
  5. Moral – How can we avoid making mistakes like this in our own code

Now that we all know what a Puzzler is, here is a simple C Puzzler:

Code:

// c-puzzler-give-me-a-float.c
#include <stdio.h>
 
int main()
{
	int x = 0.5 + giveMeAFloat();
 
	return x;
}
// c-puzzler-give-me-a-float-please.c
float giveMeAFloat()
{
	return 0.5;
}

Question:

What does this print?

  1. 0
  2. 1
  3. 1056964608
  4. it varies

Walkthrough:

There is a local variable, x, and it is declared as an int. It is being initialized to the sum of 0.5 and the value returned by the function giveMeAFloat, which is implemented in another source file. The function giveMeAFloat returns the float value 0.5, and so the sum of these two values is the float value 1.0. The variable x is an int, and so it will cast the value from 1.0 to 1. So, my answer is b, main returns the int value 1.

 

*SPOILER ALERT – ANSWER BELOW*


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Answer:

The answer is actually d – it varies! But, in practice, you will likely get c – 1056964608. How does this happen? Well, the astute observer will notice that in the source file containing our main function, there is no function prototype declaring the function giveMeAFloat. Because of this, and the fact that giveMeAFloat is implemented in another source file, then giveMeAFloat is *assumed* to return an int and not a float! If the method were declared and defined within the same source file, the compiler would detect this error and not complete the compilation. However, due to separate compilation, this cast goes unnoticed. And so, because of this ambiguity, depending on the compiler and the platform, how this value is treated and stored will vary from machine to machine! To better understand this, let’s look at the practical case where the answer is 1056964608.

  • This assumes that the program is being executed on a typical machine setup, with an x86 architecture running a current version of gcc (v4.x+)
    When the program is executed, within main, an int variable, x, is declared and initialized with a simple assignment expression that invokes giveMeAFloat. When giveMeAFloat returns, it stores the value 0.5 into the return register, eax. Since we are on a little-endian machine, this value is 0x3F000000. However, since the compiler is expecting to read an integer value, it interprets 0x3F000000 as an int and not a float, effectively loading the value 1056964608 (this is the decimal interpretation of the floating point hex representation of 0x3F000000…yikes!). Back in main, the value 0.5 gets added to this, resulting in the float value 1056964608.5. This subsequently gets assigned to the variable x. Since x is an int, this value gets cast and therefore truncated to 1056964608. And so main returns 1056964608.
     

As you can see, there are many factors that can affect the return value. In particular, what value the compiler stores into the return register (if anything), how that value is stored internally (endian-ness of the host machine), and how that value is subsequently read from the register (interpreted as int, or float, or other) all play a part. Due to all of these factors, the return value from main is effectively unpredictable, and should be treated as such (regardless of what the practical case would yield)!

Moral:

Given an arbitrary name that has not yet been previously declared, if the name is followed by a left parenthesis, it is defined to be a function and it is assumed to return an int. To prevent this, explicitly declare the function, either as a function prototype at the top of the source file, like so…

#include <stdio.h>
 
float giveMeAFloat();
 
int main()
{
	int x = 0.5 + giveMeAFloat();
 
	return x;
}

…or within the calling routine, like so…

#include <stdio.h>
 
int main()
{
	float giveMeAFloat();
	int x = 0.5 + giveMeAFloat();
 
	return x;
}

Now, there is no confusion, to yourself or the compiler, about the return-type of the function giveMeAFloat().

That’s been another C Puzzler! Hope you enjoyed! Happy coding!

 

 
Charles

c-puzzler-give-me-a-float.zip (source code)

Update: This post was corrected based on some feedback in the comments by Mihai. Thanks for the feedback, Mihai!

JavaScript Puzzler – Let’s Print Some ZIP-Codes!

Let’s take a look at a JavaScript Puzzler. If you don’t know what a Puzzler is, it is essentially a short problem used to demonstrate a quirk or edge-case with the language that you might encounter. Here is the format:

  1. Code – I introduce the code
  2. Question – I pose a multiple-choice question and you guess what the outcome is…think hard!
  3. Walkthrough – I walk through a reasonable explanation
  4. Answer – I tell you the real outcome (it might surprise you), and explain why
  5. Moral – How can we avoid making mistakes like this in our own code

Now that we all know what a Puzzler is, here is a simple JavaScript Puzzler:

Code:

<script type="text/javascript">
 
	// array of 6 valid zip-codes
	var zipCodes = new Array("93021", "16284", "02392", "20341", "08163", "32959");
 
	// let's do something with each zip-code - for now, print them out
	for (i = 0; i < zipCodes.length; i++) {
 
		// sanity check
		if (!isNaN(parseInt(zipCodes[i])) && parseInt(zipCodes[i]) > 0) {
			document.write(parseInt(zipCodes[i]) + " ");
		}
 
	}
 
</script>

Question:

What does this print?

  1. 93021 16284 2392 20341 32959
  2. 93021 16284 2392 20341 8163 32959
  3. 93021 16284 20341 32959
  4. none of the above

Walkthrough:

So, we have an array of 6 ZIP-codes in string format. We iterate through each one and print it, but first we do a sanity check. Let’s walk through each number and see if it passes.

  • 93021 – This will return a number and it will be greater than 0, so “93021″ will be written.
  • 16284 – This will return a number and it will be greater than 0, so “16284″ will be written.
  • 02392- This number has a leading 0, but parseInt() will just trim it. So, this will also return a number greater than 0, and “2392″ will also be printed (Note: no leading 0).
  • 20341 – This will return a number and it will be greater than 0, so “20341″ will be written.
  • 08163 – The same as the other number with a leading 0, parseInt() will trim this and return valid number, so “8163″ will be printed (Note again: no leading 0).
  • 32959 – This will return a number and it will be greater than 0, so “32959″ will be written.

Therefore, we should see all six numbers printed, with the numbers that have trailing 0′s being trimmed. So, my answer is b, this code will print the string “93021 16284 2392 20341 8163 32959″.

 

*SPOILER ALERT – ANSWER BELOW*


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Answer:

If you chose a, you were close. The answer is actually d – none of the above. This is because the ECMAScript standard does not define the interpretation of certain number literals, in particular number literals with a leading 0. Some JavaScript implementations will interpret these as integers with the leading 0 trimmed. Others will treat them as octal literals. It should be noted, though, that MOST JavaScript interpreters will perform the latter and interpret number literals with leading 0′s as octal literals. This is different from other languages, like Java’s Integer.parseInt(), which will conversely trim the leading 0.

So what actually gets printed? In most browsers, including IE 8, Firefox 3 and Chrome, the string “93021 16284 19 20341 32959″ gets printed (Notice the 19!). Let’s examine this step-by-step one more time…

  • 93021 – There is no leading 0, and so this number will get interpreted just as we expect, as the integer 93021, and so “93021″ will be written.
  • 16284 – Again, no leading 0, so no surprises here. “16284″ will be written.
  • 02392- This number has a leading 0, and so it will be interpreted as an octal literal. Notice, though, that the second least-significant-digit is a 9, which is not allowed in an octal number! And so, by the specification of parseInt(), it will read all digits until an illegal character is read. Therefore, parseInt() will parse the octal value 23, which equals ((2 x 8) + (3 * 1)) = (16 + 3) = 19 in decimal.
  • 20341 – This will return a number and it will be greater than 0, so “20341″ will be written.
  • 08163 – Again, this number has a leading 0. But, this time, the most-significant-digit is an 8, which is also not allowed in an octal number. So, parseInt() will interpret the octal value 0, and return 0. This fails the second part of our sanity check (that our ZIP-code must be non-zero), and so this doesn’t get printed!
  • 32959 – This will get printed as is. No surprise here either.

Moral:

Whenever possible, do not write an integer with a leading zero. Doing so can cause unexpected behaviour across browsers with different JavaScript implementations. If you can’t control the input values (as in our example above), then make use of parseInt()’s second optional parameter, radix – e.g. use parseInt(“08163″, 10) to parse “08163″ to a base-10 integer. Passing in the radix explicitly eliminates the variability between browser implementations.

That’s it for this JavaScript Puzzler! Until next time, happy coding!

Charles

javascript-puzzler-lets-print-some-zip-codes.zip (source code)

C Puzzler – Like Java Puzzlers, but for C!

I’m a big fan of Java Puzzlers. If you’re not familiar with what those are, I highly encourage you to watch this Google Tech Talk by Joshua Bloch. In short, Java Puzzlers are quirky pitfalls and corner-cases one might encounter when programming with the Java language. I liked the concept so much, I thought I’d add a section on my blog for my own puzzlers! The format is simple:

  1. Code – I introduce the code
  2. Question - I pose a multiple-choice question and you guess what the outcome is…think hard!
  3. Walkthrough - I walk through a reasonable explanation
  4. Answer - I tell you the real outcome (it might surprise you), and explain why
  5. Moral - How can we avoid making mistakes like this in our own code

Now that we know what a Puzzler is, here is a simple C Puzzler:

Code:

/** c-puzzler-lets-get-funcy.c **/
#include <stdio.h>
 
int funcOne();
int funcTwo();
 
int x = 1;
 
int main()
{
	int y = funcOne() + funcTwo();
 
	return y;
}
 
int funcOne()
{
	return x;
}
 
int funcTwo()
{
	return ++x;
}

Question:

What value does main return?

  1. 2
  2. 3
  3. 4
  4. it varies

Walkthrough:

There is a global variable, x, and it is initialized to 1. In main(), there is a local variable, y, and it is initialized to the value returned by funcOne() plus the value returned by funcTwo(). The function funcOne() simply returns the value stored in variable x, which is 1. The function funcTwo() also references x, but increments it in the process. Since the increment operator is a prefix, it performs the increment before returning the value, and so funcTwo() will return the incremented value of x, which is 2. Therefore, y will equal 1 + 2, which is 3, and main() will return the int value 3. So, my answer is b, main will return 3.

 

*SPOILER ALERT – ANSWER BELOW*


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Answer:

The answer is d – it varies. This is because in ANSI C, there is no guarantee as to the order in which the operands of an operator are evaluated. So, depending on the compiler implementation, funcOne() can be evaluated before funcTwo(), and vice versa, giving us a result of 3 or 4 depending on the compiler. It should be noted, though, that MOST C compilers will evaluate expressions of operands left to right, including the GNU compiler, but there is no guarantee that this is the case. As a result, the safest way to achieve compiler-agnostic results would be to use intermediary variables.

Moral:

The order in which operands of an operator is unspecified in C. So, to give safe and predictable results, external variables should be modified carefully, and specifically noted in the function’s documentation. If the documentation for a function is lacking, or you are working with a 3rd party API which, for all intents and purposes, is a black-box, use of intermediary variables to ensure order of operations is safest.

I hope you’ve enjoyed my first C Puzzler! Until next time, happy coding!

Charles

c-puzzler-lets-get-funcy.zip (source code)