If you aren't Happy
Which Dwarf Are You?

I've been creating classes relating to playing cards using the new Moxie module for the Perl programming language. The objective is to implement the card game Go Fish! as specified at Rosetta Code . The Outside-In View An actual program file should be simple; all the real code should be in testable modules. In this case, play_go_fish.pl takes this to an extreme. #!/usr/bin/env perl use warnings; use strict; use 5.026; use lib '.'; use Game; Game->new()->play(); As of Perl 5.26, the current directory is not automatically part of @INC, the search path for modules, so it is necessary to include it manually. That makes it possible to load the Game module, to instantiate an instance, and play a game. package Game; use Moxie; use lib '.'; use Deck; use Computer; use Human; use Const::Fast; extends 'Moxie::Object'; const my @PLAYERS => qw( human computer ); const my $INITIAL_DEAL_COUNT => 9; A Game.pm object begins like most ot...

Mathematician Rob Bradley posted that the expected length of a best-of-seven series should be about 5 3/4 games, on which basis he expected the New York Yankees to win. Or maybe living close to New York has warped his sense of reality. As a programmer, I felt a compulsion to verify his claim. I could figure out a formula, or list the possibilities (70 possible ways to win or lose 4 games out of 7), but I decided to write a simulation, using the Perl programming language. This explanation may be overly-detailed for programmers, but I want facebook friends with limited programming experience to understand. sub count_games_in_series { my ( $max ) = @_; $max //= 7; my ( $won, $lost) = (0, 0); for my $games ( 1..7) { if ( int rand 2 ) { $won++; } else { $lost++; } say "won $won; lost $lost; total $games" if $VERBOSE>1; return $games if $won == 4 || $lost == 4; ...

Having in the previous article prepared data types for car suits and card ranks, I can now combine them to provide a playing card class, using Stevan Little's Moxie module (version 0.04, so definitely early days.) The goal is to provide an object-oriented paradigm to the Perl 5 programming language which is more sophisticated, more powerful and less verbose than manually bless() -ing hashes. To achieve that goal it needs to be faster and light-weight compared to Moose. Currently, Moxie.pm and and MOP.pm are add-on modules, but eventually, when they are more complete, when the wrinkles have been ironed out, and when they have gained acceptance and a community of users, they might be merged into the Perl core. One significant feature of Moxie is that it reduces boilerplate code. You don't have to specify warnigns or strict . As well, the features or the perl you are using are enabled, among them say , state , signatures , and post_deref . A Simple Moxie Class packag...

Moxie - a new object system for Perl5 Stevan Little created the Moose multiverse to upgrade the Perl 5 programming language's object-oriented system more in line with the wonderfull world of Perl 6. Unfortunately, it's grown into a bloated giant, which has inspired light-weight alternatives Moos, Moo, Mo, and others. Now he's trying to create a modern, efficient OO system that can become built into the language. I've seen a few of his presentations at YAPC (Yet Another Perl Conference, now known as TPC, The Perl Conference), among them ‎p5 mop final final v5 this is the last one i promise tar gz While the package provides some POD documentation about the main module, Moxie, it doesn't actually explain the enum package, Moxie::Enum. But delving into the tests directory reveals its secrets. Creating an Enum package Ranks { use Moxie::Enum; enum by_ARRAY => qw( unused 2 3 4 5 6 7 8 9 10 J Q K A ); enum by_HASH => { 2 => 2, 3 =...

Having recently started a new job, I was exposed to old code with multi-step tests against autovivification in multi-level hashes. You get used to the code you have seen, but in a new environment it‘s irritating and jarring. Moose does not generally have the problem, first because class structure is pre-declared, because values are accessed using accessor functions rather than directly, and because responsibility is delegated down to attributes, avoiding long chains. On the other hand, Moose has it's own overhead, so hand-rolled objects, and bare structures still have their use. If you don‘t protect against autovivification, then mis-spelling a key, or referencing keys which haven‘t been instantiated in this instance, causes those keys to instantly come into existence. #!/usr/bin/perl use warnings; use strict; use Data::Dump 'dump'; use 5.024; my $var = {key1 => {key2 => {key3 => 'a'}}}; say dump $var; if ( $var->{key1}{key2}{key3b}[13]{foo...

Bash can only handle integer arithmetic. To process floats, you need to shell out to 'bc' or some other external utility. The core multiplication changes to: result=`echo "$result + $m * $n" | bc`; Boy, does that slow things down! For each multiplication, you're launching a shell, invoking a program, returning results. The result is 800 multiplications a second. Note this is running on integer matrices, there remain unresolved problems processing floats. One obvious problem is shelling out for every multiplication. More efficient is to accumulate the expression to calculate, and just invoke the external calculator once. Now we only shell out N^2 times, instead of N^3, so increasing matrix size leads to better performance, up to a limit. the 32x32 matrix gives 18x performance compared to the simpler version. This implies the 32x reduction in shelling out is offset by the cost of building the expression. By the time we reach 100x100, overhead costs are...

tl;dr Bash is not the language for math-intensive operations. REPS=$1; FILE_1=$2; FILE_2=$3 OUTFILENAME=$4; readonly COLS=`head -1 $FILE_1 | wc -w`; readonly ROWS=`cat $FILE_1 | wc -l`; # echo "rows is $ROWS; cols is $COLS" if [[ $ROWS != $COLS ]]; then echo "Expecting square matrices, " \ "but rows = $ROWS, cols = $COLS\n"; exit 1; fi # -------------------------------------------------- # SUBROUTINES # function outputMatrix() { local matrixname=$1; local matrix; local elem; echo "matrix is '$matrixname'."; eval matrix=\( \${${matrixname}[@]} \); local i=0; for elem in "${matrix[@]}"; do echo -n "$elem "; if (( ++i == $COLS )); then echo ''; i=0; fi done } function multiply() { declare -a product; local M=$1 N=$2; local i j k idx1 idx2 idx3; for ((i=0; i < $ROWS; i++ )); do for ((j=0; j<$COLS; j++)); do ...

Both Perl and Javascript implement only one-dimensional arrays. To represent a matrix you need to nest arrays within arrays, typically one array for each row, within the overall matrix array. Each element of the result matrix is the product of one row from the first matrix, and one column from the second. Going from one element to the next in the same row is much quicker than going to another row. The first matrix only changes rows once for each row, N changes, but the second matrix has N^3 changes of row, one for each multiplication. If we were to transpose the second array, turn the rows into columns and columns into rows, the multiplication could be carried out by by scanning along a row instead of going from row to row.That reduces the cost to N^2. How much will that save us? I transposed the second array while reading it in: for my $size ( keys %vars ) { my $filestub = q{M_} . $size . q{x} . $size . q{.}; my ( $f1, $f2 ) = ( $filestub . '1', $filestub . '...

The numbers I've been reporting for Javascript and Perl performance need a context. Are they running on a Commodore 64, or a super-computer? Nope, it's my laptop, and here's what Linpack has to report about it: 4 core, 8 thread (Intel core i7) at 3.389 GHz. Peak performance is 46 GFLOPS. Javascript and Perl are both single-threaded, so you only get 1/8 peak performance, 5 3/4 GFLOPS. That's still 1000 times the performance we actually achieve on more convenient languages. You have to sacrifice some things to gain benefits. On the optimistic side, a moderately fast modern computer sunning Perl or Javascript is almost as fast as  Sparc-10 running LINPACK. Intel(R) LINPACK data Current date/time: Fri Jun 12 01:19:06 2015 CPU frequency: 3.389 GHz Number of CPUs: 1 Number of cores: 4 Number of threads: 8 Parameters are set to: Number of tests : 15 Number of equations to solve (problem size) : 1000 2000 5000 10000 15000 18000 20000 2...

I was worried whether I was making basic errors in testing the Perl version, so I decided to use the Benchmark module to get the numbers. I copied the matmult.pl file and added use Benchmark ':all'  to the header of the file. The main() routine got changed to : my $time = $ARGV[0] || 5; my %vars = ( 2 => [], 5 => [], 10 => [], 32 => [], 100 => [], ); for my $size ( keys %vars ) { my $filestub = q{F_} . $size . q{x} . $size . q{.}; $vars{$size}[0] = readMatrix( $filestub . '1' ); $vars{$size}[1] = readMatrix( $filestub . '2' ); } say "Processing for $time seconds each size ", "will take @{[5 * $time]} seconds."; say scalar localtime; cmpthese( -$time, { 'F_2x2' => sub { matmult( $vars{2}[0], $vars{2}[1]); }, 'F_5x5...

Floating point performance compared to integer multiplication on Perl This is much the same as Perl Integer performance, and disappointly inferior to Javascript. Not a whole lot worse, comparable, really, but MY language should be better than the OTHER language! :-)

Here's the Perl script for matrix multiplication. It's derived from the RosettaCode site with slight modifications ... I didn't like some things about their way of doing things, but it's much the same in the end. #! /usr/bin/perl5.20.2 use 5.020; use warnings; use strict; use English; use Time::HiRes qw(gettimeofday tv_interval); use autodie; use Data::Dumper; # ------------------------------------------------------- # SUBROUTINES # # ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ ⋯ # matmult - multiple matrices. Copied from # RosettaCode.orgwiki/Matrix_multiplication#Perl. # sub matmult { my ( $M, $N ) = @_; my ( $rows, $cols ) = (scalar @$M, scalar @{$N->[0]} ); my $prod = []; my $k = @$N - 1; for my $i ( 0..$rows - 1 ) { for my $j ( 0 .. $cols - 1 ) { $prod->[$i][$j] += $M->[$i][$_] * $N->[$_][$j] for 0..$k; } } return $prod; } # ⋯ ⋯ ⋯ ...

I don't know why I wrote such stupid code for readMatrix.js . I guess when someone uses a new language their brain cells seize up, effective function becomes impossible. After tests I ran on Friday, I wanted to see how Javascript does with floating point numbers? JS only supports 64 bit floating-point numbers, but there must be special code in their to make integers look like integers ... unless their isn't. When I went to update my code to support numbers with fractions, my first thought was to flag whether a decimal point had been seen and then keep track of the value by which to divide, multiplying by ten for each fractional digit. I quickly realized I was sinking into the mire of coding stupidity; JS must have a function to convert strings into integers or floats, and indeed it has parseInt() and parseFloat() . But in my research I discovered ( or re-discovered ) that there's no need for the conversion. Like Perl, JS allows arithmetic on the string representation...

For the past 20 years, I've focused on programming in real languages for real applications, as opposed to web stuff, :-). When I have dealt with the web, it's been using server-side scripts. Definitely not that Javascript crud. Mind you, back when I worked for a porn website, they also came up with a JS based website, Simple.com, long before other people were doing all-JS interfaces. But the time has come to re-evaluate ... well, everything. Javascript can be checked for validity and style using JSHint & JSLint; it can be debugged. There are frameworks and layers that make it possible to do useful things easily, treating old JS as a sort of widely-supported low-level language on which to implement more elegant systems. One of these new paradigms is the implementation of node.js to run JS programs on the server, rather than in a web page. Node uses the Google's V8 Javascript engine from the Chrome browser, which means a large corporation ensures high performance on...

I was somewhat uncomfortable that my solution to the combinatorics task, which involved a single, not very long routine, became so long with the addition of command line processing and POD  documentation. For one thing, while it had some information about how to invoke the routine, it did not have tests. I still feel that a book on programming, say, should have a fully-implemented solution once a chapter, perhaps, to show the way things should be done. But that is too long for every single bit of code. Full documentation and sample implementations stretch on too long, compared to the few lines a snippet actually deserves. Providing tests may still be appropriate. They take up less space than full documentation, yet explain how the various components work, by the very act of stress-testing those lines of code. Tests provide examples of how the code should be invoked. Revising the combinatorics task into a module, this generates: use perl5i::2; # ---------------------------...

I've long admired the way functional languages specify multiple implementations of a routine for different sets of argument values, to detect terminal conditions. Converting a Perl6 solution  of a combinatorics task to Perl5i, I realized the plain Perl solution isn't necessarily all that bad, either. The problem is to list the different ways you can select M elements from a set of N. Select 2 elements from a set of 4 would lead to the values ( 1, 2 ); ( 1, 3 ); ( 1, 4 ); ( 2, 3 ); ( 2, 4 ); ( 3, 4 ). Oh yeah, they want the characters in each combination in sorted order, and  the list of combinations sorted, too. So it all consists of a single routine which gets invoked as combine(3, ['a'..'e']) . Ignore the first couple of lines, for a moment. If the first character of the set exists in a combination, it must be in the first position, since the characters are in sorted order. That means the remainder of the combination must be one character shorter, made...