Sunday, July 19, 2015

4Clojure: For the Win

(for [x (range 40)
    :when (= 1 (rem x 4))]
    x)

x is assigned the range of integer values from 0-39. x is finite so the for stops evaluating when x is fully consumed.
On each iteration the remainder of x/4 is compared to 1 and if they are equal the body is evaluated (which is just x).

(for [x (iterate #(+ 4 %) 0)
    :let [z (inc x)]
    :while (< z 40)]
    z)

x is assigned a lazy sequence of all the multiples of 4 (iterate from 0 applying +4 at each step using an anonymous function). x is infinite so the for is terminated with :while
Each iteration of the for symbol z is assigned x+1.
While z is less than 40 the body is evaluated (which is just z) and the for loop terminates when z >= 40.

(for [[x y] (partition 2 (range 20))]
    (+ x y))

The range from 0-20 is split into segments of 2 numbers. One segment deconstructed into x and y per iteration of the for. The sequence is finite so the for terminates when the full sequence is consumed.
x and y are added as the body of the for.

Each of these results in the same output (a list of each multiple of 4 incremented by 1 up to 37) just by a different mechanism. For my money the first option is probably the best combination of concise and obvious.

Clojure for macro keywords

These docs weren't incredibly helpful in figuring out the difference between :when and :while.
The examples
(for [x [1 2 3]
  y [1 2 3]
  :while (<= x y)
  z [1 2 3]]
  [x y z])
and

(for [x [1 2 3]
  y [1 2 3]
  z [1 2 3]
  :while (<= x y)]
  [x y z])

come close to exposing the difference, but what should really be stated explicitly somewhere is that :while stops attempting to evaluate at the first false result whereas (almost said while there >.> ) :when continues to try to evaluate after the false.

(for [x [1 2 3]
  y [1 2 3]
  :while (= x y)
  z [1 2 3]]
  [x y z])
;;([1 1 1] [1 1 2] [1 1 3])
(for [x [1 2 3]
  y [1 2 3]
  :when (= x y)
  z [1 2 3]]
  [x y z])
;;([1 1 1] [1 1 2] [1 1 3] [2 2 1] [2 2 2] [2 2 3] [3 3 1] [3 3 2] [3 3 3])

Perhaps I'm dense but this wasn't immediately obvious to me.

Edit: Or perhaps I should have actually read. Example 8 is pretty explicit. >.<

Saturday, June 6, 2015

Fuck Microsoft and their little dog too

I just wasted 3 hours trying to get a dev environment past the 3rd setup step. Why? Because VT-x was FUBARed by Hyper-V. 3 fucking hours googling and getting a headache trying to figure out why the Intel(R) Processor Identification Utility tool was saying my hot-shit Surface Pro 3 Core i7 processor didn't support 'Intel(effingR) Virtualization Technology' or Intel (shockingly not Red) VT-x with Extended Page Tables. All the while wondering if my CPU is weirdly broken and going to need an RMA after 6 months of settling into it. As it happens I tried deleting Hyper-V entirely after trying a good half dozen tools and workarounds, looking at the (honetly braindead) Surface BIOS UEFI, and I can't remember what all else. All I needed was to open PowerShell as admin and
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

aka KILLITWITHFIRE

The HabitRPG dev environment uses Vagrant and VirtualBox, which was complaining that VT-x wasn't available and dieing horribly (presumably because it's a 64bit guest). But apparently Hyper-V EATS that part of your CPU so nobody else can use it. Or something. Whatever, don't bore me with the technical details, I just wish someone somewhere had thought to mention the critically important bit that HYPER-V WANTS TO MONOPOLIZE THE PLAYGROUND EQUIPMENT. Anyway. Learned my lesson (I might even remember it next time) and won't be touching Hyper-V ever. Unless by some perverse chance I opt to write something for Windows Phone. Which is incredibly unlikely knowing the debugging will require Hyper-V and thus explicitly ban me from doing a hundred other things. You can pretty much forget about that.
Now the vagrant guest is coming up and, with any luck, the VM I had decided was going to need to be wiped might actually be usable again. GAH, I was just starting to think MS gave a shit about computing in general, what with Community VS and free (sorta) Windows 10 upgrades.

Wednesday, April 1, 2015

Cancer

Cancer (n) - the phenomenon resulting from a cell making its division function recursive and forgetting a proper stopping criterion. The function will recurse until it crashes the system or is halted externally.

Friday, March 20, 2015

The right to be...

In response to http://intelligencesquaredus.org/debates/past-debates/item/1252-the-u-s-should-adopt-the-right-to-be-forgotten-online

There is no right to be forgotten. That's a misapprehension of the root point. There is instead a right to be understood.
Every story discussed in support of the motion points to the every-human wanting to be understood as what they are, not what they were or what someone else believes them to be.
Every story posed against the motion points equally to a public need to understand who someone is now. The stifling of negative information about public figures being prominent.

So I propose that the motion is simply broken. We should instead be discussing a right to be understood and processes that can express and reinforce that right. Frankly, I don't believe any government is the proper party for that. Law is not, cannot reasonably be, flexible enough for that and so it must come to the individual's interaction with the world that expresses the right. Perhaps sadly there are many individuals with greater leverage in their interactions that don't seem interested in understanding anyone outside their circles.

Tuesday, January 27, 2015

Problem analysis

Response to
http://discourse.codenewbie.org/t/coding-exercise-problem-breakdown/618


  1. Check front door lock.
    1. If locked, unlock.
  2. Open front door.
  3. Until distance to car door = 0, walk toward car door (I'm deliberately ignoring pathing concerns, my car door is basically straight outside my front door)
  4. Check car door.
    1. If locked, unlock
  5. Open car door.
  6. Sit down in driver seat sideways.
  7. Juggle lunch, backpack, etc into passenger seat (this sort of crap is why robots tend to look so clumsy, just try and create an algorithm for how your arms move doing that, never mind controlling your balance through it all, your brain really is amazing)
  8. Pull feet into car.
  9. Close car door.
  10. Insert key into ignition.
  11. Turn key.

There are a few minor steps left out and there's some assumed knowledge like the car not having keyless ignition (mine does so this algorithm couldn't be applied naively to my case). It also assumes that you're able to carry whatever you're carrying without juggling anything around, and you don't have to find the right key on your key ring or look for your car in an apartment parking lot. And it still took 11 procedural steps.

Oh. And we never closed and re-locked the front door. That wasn't in the requirements. Of course in my case my wife does that in the morning so I suppose you could call me a good example of why you should follow the requirements doc once it's been reviewed and accepted by all parties.

Tuesday, January 13, 2015

Code Combet + Firefox = win

Wow. This runs so much better in Firefox. Go figure.
It's nearly unplayable in Chrome (which surprised me), it's a lot better in IE (which floored me), but it's smooth as silk in FF. Well, aside from slowing down a bit as the thang count increases.

Also, in IE my solution to one of the levels locks up every time I submit it even though it runs fine in the 'debug environment'. In FF? Works like a charm. Go figure. >.> FF just earned a spot back on my computer.