Comments for Joe Rawlings http://joerawlings.com/blog Software Engineer Sun, 06 Mar 2011 22:26:15 +0000 hourly 1 http://wordpress.org/?v=3.1.3 Comment on Scala Day 1 Tic-Tac-Toe by Scala Day 2 – Higher-Order Functions | Joe Rawlings http://joerawlings.com/blog/2011/03/scala-day-1-tic-tac-toe/#comment-32 Scala Day 2 – Higher-Order Functions | Joe Rawlings Sun, 06 Mar 2011 22:26:15 +0000 http://joerawlings.com/blog/?p=71#comment-32 [...] up on Day 1, here's day 2 from 7 languages in 7 weeks. These problems are quite a bit more abstract but I [...] [...] up on Day 1, here's day 2 from 7 languages in 7 weeks. These problems are quite a bit more abstract but I [...]

]]> Comment on Java Puzzle 6 by jrawlings http://joerawlings.com/blog/2010/11/java-puzzle-6/#comment-7 jrawlings Fri, 26 Nov 2010 16:23:01 +0000 http://joerawlings.com/blog/?p=43#comment-7 The answer is (b), 17777 and 43878. This program doesn't say what you think it does and leading zeros can cause trouble. On line 3, the syntax highlighting gives it away that you are adding 12345 with the long 5432. On line 4, the leading 0 on '01234' makes it an octal literal equal to 1,234 (base 8 ) or 668 in decimal. The moral is to always use an uppercase el (L) for long literals and never use lowercase el as a variable name. Also, never precede an int literal with 0 unless you want to express it in octal (base 8 ) The answer is (b), 17777 and 43878. This program doesn’t say what you think it does and leading zeros can cause trouble. On line 3, the syntax highlighting gives it away that you are adding 12345 with the long 5432. On line 4, the leading 0 on ’01234′ makes it an octal literal equal to 1,234 (base 8 ) or 668 in decimal.

The moral is to always use an uppercase el (L) for long literals and never use lowercase el as a variable name. Also, never precede an int literal with 0 unless you want to express it in octal (base 8 )

]]> Comment on Java Puzzle 5 by jrawlings http://joerawlings.com/blog/2010/11/java-puzzle-5/#comment-6 jrawlings Fri, 26 Nov 2010 16:03:02 +0000 http://joerawlings.com/blog/?p=40#comment-6 The answer is (a), 5. Computation does overflow (multiplying with ints). 24 * 60 * 60 * 1000 * 1000 > Integer.MAX_VALUE. The simple fix is to multiply with longs. The moral is to watch out for overflow -- it's a silent killer. When in doubt, use a larger type. The answer is (a), 5. Computation does overflow (multiplying with ints). 24 * 60 * 60 * 1000 * 1000 > Integer.MAX_VALUE. The simple fix is to multiply with longs.

The moral is to watch out for overflow — it’s a silent killer. When in doubt, use a larger type.

]]> Comment on Java Puzzle 4 by jrawlings http://joerawlings.com/blog/2010/11/java-puzzle-4/#comment-5 jrawlings Fri, 26 Nov 2010 15:51:35 +0000 http://joerawlings.com/blog/?p=36#comment-5 The answer is (b). Enumerating over entry sets works better for some Map implementations than others. The key line is 15 where the Constructor iterates over entrySet and inserts entries into the set. 2 for the HashMap is pretty obvious but for EnumMap it's a little trickier. EnumMap is very frugal with its memory usage and actually reuses the same entry object every time. So, when HashSet iterates over the entries it adds the same mutable entry twice and you should never add mutable objects in HashSets. The fix is pretty painful where by you would need to manually iterate over the entrySet and add your own immutable copies of the entries. The moral here is to take care when iterating over entry sets. The answer is (b). Enumerating over entry sets works better for some Map implementations than others. The key line is 15 where the Constructor iterates over entrySet and inserts entries into the set. 2 for the HashMap is pretty obvious but for EnumMap it’s a little trickier. EnumMap is very frugal with its memory usage and actually reuses the same entry object every time. So, when HashSet iterates over the entries it adds the same mutable entry twice and you should never add mutable objects in HashSets.

The fix is pretty painful where by you would need to manually iterate over the entrySet and add your own immutable copies of the entries. The moral here is to take care when iterating over entry sets.

]]> Comment on Java Puzzle 3 by jrawlings http://joerawlings.com/blog/2010/11/java-puzzle-3/#comment-4 jrawlings Fri, 26 Nov 2010 15:23:02 +0000 http://joerawlings.com/blog/?p=33#comment-4 The answer is (d). This program will run for > 10^15 years before printing anything. This is because the regex exhibits catastrophic backtracking. Here's how matcher tests "aaaaa" for "(aa|aab?)+" <pre>(aa) (aa) (aa) fail (aa) (aa) (aab?) fail (aa) (aab?) (aa) fail (aa) (aab?) (aab?) fail (aab?) (aa) (aa) fail (aab?) (aa) (aab?) fail (aab?) (aab?) (aa) fail (aab?) (aab?) (aab?) fail</pre> This is exponential in length of string! O(2^(n/2)). Fix this by replacing (aa|aab?)+ with (aa|aab)+. This cuts the spread factor from 1^n to 1^100 and runs the program instantaneously. Moral here is to avoid catastrophic backtracking and sure there's only one way to match each string. This goes beyond Java and affects most regular expression systems. The answer is (d). This program will run for > 10^15 years before printing anything. This is because the regex exhibits catastrophic backtracking.

Here’s how matcher tests “aaaaa” for “(aa|aab?)+”

(aa)     (aa)     (aa)    fail
(aa)     (aa)     (aab?)  fail
(aa)     (aab?)   (aa)    fail
(aa)     (aab?)   (aab?)  fail
(aab?)   (aa)     (aa)    fail
(aab?)   (aa)     (aab?)  fail
(aab?)   (aab?)   (aa)    fail
(aab?)   (aab?)   (aab?)  fail

This is exponential in length of string! O(2^(n/2)).

Fix this by replacing (aa|aab?)+ with (aa|aab)+. This cuts the spread factor from 1^n to 1^100 and runs the program instantaneously. Moral here is to avoid catastrophic backtracking and sure there’s only one way to match each string. This goes beyond Java and affects most regular expression systems.

]]> Comment on Java Puzzle 2 by jrawlings http://joerawlings.com/blog/2010/11/java-puzzle-2/#comment-3 jrawlings Fri, 26 Nov 2010 04:41:38 +0000 http://joerawlings.com/blog/?p=19#comment-3 The answer is (d). It will actually print out .89999999999999111821580299 and so on. In this puzzle, the wrong BigDecimal constructor was used. When passing a double in, it is translated to the exact decimal representation of the double's binary floating-point value. More details in the video. But, to fix the problem, use the String constructor. new BigDecimal("2.00") and new BigDecimal("1.10"). Moral is to not use float or double when exact answers are required (like money). Use BigDecimal, int, or long instead. It's not the size, it's how you use it. The answer is (d). It will actually print out .89999999999999111821580299 and so on.

In this puzzle, the wrong BigDecimal constructor was used. When passing a double in, it is translated to the exact decimal representation of the double’s binary floating-point value. More details in the video.

But, to fix the problem, use the String constructor. new BigDecimal(“2.00″) and new BigDecimal(“1.10″).

Moral is to not use float or double when exact answers are required (like money). Use BigDecimal, int, or long instead.

It’s not the size, it’s how you use it.

]]> Comment on Java Puzzle 1 by jrawlings http://joerawlings.com/blog/2010/11/java-puzzle-1/#comment-2 jrawlings Fri, 26 Nov 2010 01:50:26 +0000 http://joerawlings.com/blog/?p=15#comment-2 The correct answer is (c) where the actual exception is a ClassCastException. This is because of raw types and they are dangerous. You may have noticed the class was typed -- from line 1 Glommer < T > class. Since < T > type is not used anywhere, this makes it a raw type and all generic types referenced are thrown out when compiled. This includes throwing out the wildcard type on Collection < ? >, the Integer type on List < Integer >, and the String type on List < String >. Therefore, the call to glom(strings) using a List will go the the glom method on line 9. This being the most specific, applicable match. Subsequently, the app blows up with a ClassCastException being thrown. The compiler does help you in this case. When compiled, you will get "Glommer.java uses unchecked or unsafe operations". So, you can't say you weren't warned :) The correct answer is (c) where the actual exception is a ClassCastException. This is because of raw types and they are dangerous.

You may have noticed the class was typed — from line 1 Glommer < T > class. Since < T > type is not used anywhere, this makes it a raw type and all generic types referenced are thrown out when compiled.

This includes throwing out the wildcard type on Collection < ? >, the Integer type on List < Integer >, and the String type on List < String >.

Therefore, the call to glom(strings) using a List will go the the glom method on line 9. This being the most specific, applicable match. Subsequently, the app blows up with a ClassCastException being thrown.

The compiler does help you in this case. When compiled, you will get “Glommer.java uses unchecked or unsafe operations”. So, you can’t say you weren’t warned :)

]]>