Comments on: This is your brain; this is your brain on OCaml http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: Robert Fischer http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/#comment-37817 Robert Fischer Sun, 22 Aug 2010 23:21:16 +0000 http://enfranchisedmind.com/blog/?p=39#comment-37817 Yeah, shifting to use Strings as the basis instead of ints as the basis is a lot smarter. Yeah, shifting to use Strings as the basis instead of ints as the basis is a lot smarter.

]]> By: Przemek http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/#comment-37816 Przemek Sun, 22 Aug 2010 17:23:48 +0000 http://enfranchisedmind.com/blog/?p=39#comment-37816 1) startValue > endValue is not error, it is convenient way to express empty set, in that case it doesnt break anything - you just get empty array of Strings 2) do you really want complexity o((endValue-startValue)*usedValues.length) in production code? 3) Good, fast and "in java way" code (my first try): <code> public static String[] findAvialable(int startValue, int endValue, String[] usedValues) { describe empty sets! TreeSet allUsed = new TreeSet(Arrays.asList(usedValues)); ArrayList results = new ArrayList(); for (int i = startValue; i <= endValue; i++ ){ String s = ""+i; if ( !allUsed.contains(s)){ results.add(s); } } return results.toArray(new String[results.size()]); } </code> 1) startValue > endValue is not error, it is convenient way to express empty set, in that case it doesnt break anything – you just get empty array of Strings
2) do you really want complexity o((endValue-startValue)*usedValues.length) in production code?
3) Good, fast and “in java way” code (my first try):

public static String[] findAvialable(int startValue, int endValue, String[] usedValues) {
describe empty sets!
TreeSet allUsed = new TreeSet(Arrays.asList(usedValues));
ArrayList results = new ArrayList();
for (int i = startValue; i <= endValue; i++ ){
String s = ""+i;
if ( !allUsed.contains(s)){
results.add(s);
}
}
return results.toArray(new String[results.size()]);
}

]]> By: The Cheap Sitcom Clip Scene Blog Post | Enfranchised Mind http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/#comment-33556 The Cheap Sitcom Clip Scene Blog Post | Enfranchised Mind Tue, 15 Jul 2008 04:58:39 +0000 http://enfranchisedmind.com/blog/?p=39#comment-33556 [...] “…since I was writing JUnit tests anyways, I figured I would do a bit of clean-up. What I didn’t realize is that Ocaml has warped me, and my concept of “cleanup” is very different than everyone else’s.” (This Is Your Brain; This Is Your Brain on OCaml) [...] [...] “…since I was writing JUnit tests anyways, I figured I would do a bit of clean-up. What I didn’t realize is that Ocaml has warped me, and my concept of “cleanup” is very different than everyone else’s.” (This Is Your Brain; This Is Your Brain on OCaml) [...]

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/#comment-25 Robert Fischer Fri, 16 Dec 2005 19:37:07 +0000 http://enfranchisedmind.com/blog/?p=39#comment-25 Good call -- I actually did that when I went back to my code after lunch. Particularly considering that the number of "used" elements is known to be small in this implementation, that's a much better way to go. There is a type mismatch between the used set and the available list, but the resolution is left as an exercise for the reader. I also changed the List to a TreeSet, which retains the sorting I need but substantially improves performance in the removeAll call. I had to create a singleton Comparator that compared on length first, and then on content, but it's still pretty nifty. The other change I made was to change <code>new Integer(Integer.parseInt(object.toString()))</code> to just <code>new Integer(object.toString())</code>. Good call — I actually did that when I went back to my code after lunch. Particularly considering that the number of “used” elements is known to be small in this implementation, that’s a much better way to go. There is a type mismatch between the used set and the available list, but the resolution is left as an exercise for the reader.

I also changed the List to a TreeSet, which retains the sorting I need but substantially improves performance in the removeAll call. I had to create a singleton Comparator that compared on length first, and then on content, but it’s still pretty nifty.

The other change I made was to change new Integer(Integer.parseInt(object.toString())) to just new Integer(object.toString()).

]]> By: TheHawk http://enfranchisedmind.com/blog/posts/this-is-your-brain-this-is-your-brain-on-ocaml/#comment-24 TheHawk Fri, 16 Dec 2005 17:56:32 +0000 http://enfranchisedmind.com/blog/?p=39#comment-24 You are a sick man... but instead of the for loop you could have created a List of Ints between Start Value and End Value (which is more natural with the program) and then RemoveALL the elements in the used set. You are a sick man… but instead of the for loop you could have created a List of Ints between Start Value and End Value (which is more natural with the program) and then RemoveALL the elements in the used set.

]]>