( *…continues from previous week.* )

Welcome to the Perl review pages for **Week 157** of The Weekly Challenge! Here we will take the time to discuss the submissions offered up by the team, factor out some common methodologies that came up in those solutions, and highlight some of the unique approaches and unusual code created.

### ●︎ Why do we do these challenges?

I suppose any reasonable answer to that question would be from a field as wide ranging and varied as the people who choose to join the team. One thing, though, is clear: it’s not a competition, and there are no judges, even if there is a “prize” of sorts. About that – I think of it more as an honorarium periodically awarded to acknowledge the efforts we make towards this strange goal. So there’s no determination to find the *fastest*, or the *shortest*, or even, in some abstract way, the *best* way to go about things, although I’m certain the participants have their own aspirations and personal drives. As Perl is such a wonderfully expressive language, this provides quite a bit of fodder to the core idea of TMTOWTDI, producing a gamut of varied techniques and solutions.

Even the tasks themselves are often open to a certain amount of discretionary interpretation. What we end up with is a situation where each participant is producing something in the manner they find the most interesting or satisfying. Some team members focus on carefully crafted complete applications, thoroughly vetting input data and handling every use case they can think up. Others choose to apply themselves to the logic of the underlying puzzle and making it work in the most elegant way they can. Some eschew modules they would ordinarily reach for, others embrace them, bringing to light wheels perhaps invented years ago that happen to exactly solve the problem in front of them today.

I’ve been considering this question for some time and have found one binding commonality between all of us out solving these challenges each week, in that however we normally live our lives, the task in front of us more than likely has nothing to do with any of that. And I think this has great value. We all do what we do, in the real world, and hopefully we do it well. The Weekly Challenge provides us with an opportunity to do something germane to that life yet distinctly different; if we only do the things we already know how to do then we will only do the same things over and over. This is where the “challenge” aspect comes into play.

So we can consider The Weekly Challenge as providing a problem space outside of our comfort zone, as far out from that comfort as we wish to take things. From those reaches we can gather and learn things, pick and choose and bring what we want back into our lives. Personally, I think that’s what this whole thing is about. YMMV.

And that, my friends, is why I’m here, to try and figure out ways to do just that.

So, here we are then. I’m ready — let’s get to it and see what we can find.

### For Additional Context…

before we begin, you may wish to revisit either the pages for the **original tasks** or the summary **recap** of the challenge. But don’t worry about it, the challenge text will be repeated and presented as we progress from task to task.

Oh, and one more thing before we get started:

### Getting in Touch with Us

Email › Please feel free to email me (Colin) with any feedback, notes, clarifications or whatnot about this review.

GitHub › Submit a pull request to us for any issues you may find with this page.

Twitter › Join the discussion on Twitter!

I’m always curious as to what the people think of these efforts. Everyone here at the PWC would like to hear any feedback you’d like to give.

**...So finally, without further ado...**

## • Task 1 • Task 2 • BLOGS •

# TASK 1

# Pythagorean Means

*Submitted by: Mohammad S Anwar*
You are given a set of integers.

Write a script to compute all three Pythagorean Means

- Arithmetic Mean,
- Geometric Mean and
- Harmonic Mean

of the given set of integers. Please refer to wikipedia page for more informations.

**Example 1:**

```
Input: @n = (1,3,5,6,9)
Output: AM = 4.8, GM = 3.8, HM = 2.8
```

**Example 2:**

```
Input: @n = (2,4,6,8,10)
Output: AM = 6.0, GM = 5.2, HM = 4.4
```

**Example 3:**

```
Input: @n = (1,2,3,4,5)
Output: AM = 3.0, GM = 2.6, HM = 2.2
```

## about the solutions

**Athanasius**,
**Cheok-Yin Fung**,
**Colin Crain**,
**Dave Jacoby**,
**Duncan C. White**,
**E. Choroba**,
**Flavio Poletti**,
**Jaldhar H. Vyas**,
**James Smith**,
**Jorg Sommrey**,
**Kueppo Wesley**,
**Laurent Rosenfeld**,
**Lubos Kolouch**,
**Matthew Neleigh**,
**Mohammad S Anwar**,
**Niels van Dijke**,
**Paulo Custodio**,
**Pete Houston**,
**Peter Campbell Smith**,
**PokGoPun**,
**Robert DiCicco**,
**Roger Bell_West**,
**Simon Green**,
**Ulrich Rieke**, and
**W. Luis Mochan**

When we speak of the mean, there is an intuitive understanding of “right in the middle” that comes naturally, without thinking too much about what exactly that means mathematically. And the intuitive grasp is not wrong — it’s only that sometimes the methods used to get to that middle-ground aren’t always the same, depending on what it is exactly that is being evaluated.

The arithmetic mean is the most common way to think of a mean, and it equates to the average value across a data set: if I have four piles of stuff with 1, 3, 7 and 9 items in them, the average number of items in a pile is found by looking at all the piles together and dividing them again evenly; in this case the result is 5 items.

Simplifying a bit, this mean between any two values is thus the average, made by summing and dividing the sum in half. On a number line the point would be half-way between the initial values.

The geometric mean on the other hand finds a middle point between two values such that the *ratio* of the first value to the mean is the same as the ratio of the mean to the second value. Consider the numbers 1 and 9: the half-way point between the two is 5, which is the arithmetic mean we’ve just looked at. But the ratios for these intervals between the values are 1:4 and 4:9. For the number 3, however, 1:3 is the same as 3:9, and so 3 is the *geometric* mean between the two.

For the harmonic mean, we are similarly comparing ratios, but in this case the ratio of the first term to the mean considered in turn as a ratio to the first term is the same as the ratio of the mean to the second term, considered as a ratio to the second. Put another way, we’re comparing the ratios to the mean back to their outside terms. Practically, this flips the arithmetic mean on its head, summing the reciprocals and averaging them, and then taking the reciprocal again.

Archytas of Tarentum, who coined the term *harmonic* mean, described it as:

the mean when they are such that, by whatever part of itself the first term exceeds the second, by that part of the third the middle term exceeds the third

For the harmonic mean we take the mean of the inverses of the arithmetic mean, and considers the values as a *rates*, in relation to a consistent nominal unity.

I have chosen to define the Pythagorean Means here in terms of ratios, because this mirrors the historical context in which they were first developed. Pythagoras was beyond a geometrician a musician, and spent considerable time thinking about the idea of subdividing musical strings into 3:2 and 2:1 relationships, resulting in a version of what we now consider a 12-tone scale. When looking to place a note between two other notes, you can see, or perhaps hear, how various competing ideas of “in the middle” can arise. The harmonic mean was coined specifically referring to this context, as when used in this way it produced scales with a pleasing musicality.

There were 25 submissions for the first task this past week.

## say it like YOU MEAN IT

**Flavio Poletti**,
**Simon Green**,
**Jorg Sommrey**,
**Laurent Rosenfeld**,
**Ulrich Rieke**,
**Jaldhar H. Vyas**,
**Athanasius**,
**Cheok-Yin Fung**, and
**Peter Campbell Smith**

The first challenge is a straightforward exercise in translation — from a mathematical formula to a corresponding code algorithm. There was considerable self-similarity amongst the methods we saw, but there were also a few interesting variations to look at along the way

**additional languages:**
Raku

**blog writeup:**
PWC157 - Pythagorean Means - ETOOBUSY

Flavio will begin with the first demonstration, with three subroutines for the three requested means. As we are processing lists, he imports some convenient routines from `List:Util`

to help him along: `sum`

, `product`

and later, `reduce`

.

```
sub arithmetic_mean (@n) { sum(@n) / @n }
sub geometric_mean (@n) { abs(product(@n)) ** (1 / @n) }
sub harmonic_mean (@n) { 1 / arithmetic_mean(map { 1 / $_ } @n) }
```

For the arithmetic, we sum the input list values and divide them by the number of elements, which we get by using the list itself in scalar context.

For the geometric, we take the absolute value of the product of the list and take the *n*-th root, with *n* again being the number of elements.

Then for the harmonic mean we have the reciprocal dual of the arithmetic mean. What we do there is take the arithmetic mean of the reciprocals of the list items, and then take the reciprocal of that result.

Before we continue, however, he also provides an alternate form of the geometric using `reduce`

:

```
use List::Util 'reduce';
sub gmalt (@n) { (reduce {$a * $b} @n) ** (1 / @n) }
```

The thing about `reduce()`

, though is that it’s sort of a list-wise function archetype for any process that takes all of the list items and obtains a single result by altering the applied function. What he’s done here is constructed his own `product()`

: items from the list are taken one-by-one and multiplied, with the growing result kept in the accumulator `$a`

, and the individual terms slotted into `$b`

as we perform the traversal. Alternately, by using the block `{ $a + $b }`

we can create a `sum()`

function. As both of these already exist pre-built in `List::Util`

, it does seem a bit silly to use `reduce()`

instead and explicitly construct them. But keep an eye — we’re nowhere near finished with `reduce`

.

**additional languages:**
Python

**blog writeup:**
Three means and big bases

Simon eschews bothering with separate subroutines, inlining three equations. Of note his harmonic mean is a coded little differently, being first rearranged to the number of elements divided by the sum of the reciprocals of the list items. Mathematically they are the same.

He does, however, make an effort to avoid a divide-by-zero error should a list element be 0. On the other hand he mentions the possibility that the entire list may sum to 0, allowing a second pathway for an error to arise, but that one he lets slide with a note. Seems reasonable to me.

```
# Calculate the different means
my $c = scalar(@n);
my $am = sum(@n) / $c;
my $gm = product(@n)**( 1 / $c );
my $hm = $c / reduce { $a + ( $b == 0 ? 0 : 1 / $b ) } 0, @n;
```

As stated before, `reduce()`

is list-wise proto-function, that can be instantiated with different applied blocks to mimic the more specific functions `sum`

and `product`

. So ultimately all three can be, er, “reduced”, to a `reduce`

form.

So why use three functions when you can use one? And more so, if each function processes the input list one element at a time to accumulate a result, why not compute all of the means in a single pass, with one complicated block?

That last part is a little tricky, but Jorg has risen to the task.

```
# Feed the number of elements, the sum, the product and the sum of the
# reciprocals of the given list into an anonymous sub to calculate
# the requested means.
# The examples call for results with a precision of one decimal digit,
# thus not spending any effort to produce exact results.
sub pythagorean_means {
sub {($_[1] / $_[0], $_[2] ** (1 / $_[0]), $_[0] / $_[3])}->(
scalar @_,
(reduce {[$a->[0] + $b, $a->[1] * abs($b), $a->[2] + 1 / $b]}
[0, 1, 0], @_)->@*
);
}
```

With only one accumulator, this takes the form of a three-element list for each of the three means that will be calculated simultaneously. But we’re getting ahead of ourself.

Because this is functional programming, much of the control flow is best understood backwards, reading from the right working leftwards. What we have here is, on the first line, an anonymous function reference being called with a set of parameters that follow after the final opening parenthesis. We’ll get to the function in a bit, and start with the parameters. Here we have the array length at index [0], and a `reduce`

function that produces three values in the aforementioned tripartite accumulator: the sum of the elements, the product of the elements, and the sum of the reciprocals. For those confused, the sum requires the accumulator to start with 0, but the product needs to me the multiplicative identity, unity. And yes there is an anonymous array dereferencing in there too to flatten the list properly.

Back to the first line, now we have this list of four elements as parameters, we pass it to a function that divides the second with the first to produce the average, the third raised to the fractional *n*-th power with the first to get the *n*-th root for the geometric, and the first divided by the fourth to get the harmonic.

Whew! I’m a bit out of breath. Does anyone have any water? I may need to sit for a bit.

**additional languages:**
Raku

**blog writeup:**
Perl Weekly Challenge 157: Pythagorean Means and Brazilian Number

After that workout I think it good to rest up and regain our bearings. Laurent’s solution is clean, well laid out and computes everything in a straightforward manner.

This challenge does not need to be particularly complicated.

```
my $n = scalar @in;
my $sum = 0;
$sum += $_ for @in;
my $am = $sum / $n;
my $prod = 1;
$prod *= $_ for @in;
my $gm = $prod ** (1/$n);
my $invsum = 0;
$invsum += 1/$_ for @in;
my $hm = $n / $invsum;
```

**additional languages:**
C++, Haskell, Raku

Ulrich shares a nice little app with us, taking a space-separated list of integers from a command-line prompt, and then delivering a well-formatted report of the values.

Internally, we can see the familiar core logic to produce the three variables.

```
use List::Util qw ( product sum ) ;
say "Enter a number of integers, separated by a blank!" ;
my $line = <STDIN> ;
chomp $line ;
my @numbers = split( /\s+/ , $line ) ;
my $len = scalar( @numbers ) ;
my $am = sum( @numbers ) / $len ;
my $gm = (product( @numbers )) ** (1 / $len ) ;
my $hm = $len / ( sum ( map { 1 / $_ } @numbers ) ) ;
my @formatted = map { sprintf( "%.1f" , $_) } ( $am , $gm , $hm ) ;
say "AM = $formatted[0] , GM = $formatted[1] , HM = $formatted[2]" ;
```

**additional languages:**
Raku

**blog writeup:**
Perl Weekly Challenge: Week 157

Some members go to great lengths to exactly mimic the examples, which here display one and only one decimal place. To reproduce this behavior Jaldhar introduces us to `Math::Round`

which uses a well-defined set of rules to deliver the required, and only the required, precision.

For those unfamiliar with scientific calculations excess precision in a result is actually a bad thing, as it can introduce errors by giving the experimenter the impression that accuracy is really there when it is not: one significant digit of precision going in yields one significant digit going out, and calculating internally to fifteen decimal places does not affect this fundamental truth.

```
use Math::Round qw/ nearest /;
sub product {
my ($arr) = @_;
my $total = 1;
for my $elem (@{$arr}) {
$total *= $elem;
}
return $total;
}
sub sum {
my ($arr) = @_;
my $total = 0;
for my $elem (@{$arr}) {
$total += $elem;
}
return $total;
}
my @n = @ARGV;
my $am = sum(\@n) / scalar @n;
my $gm = nearest(0.1, (abs product(\@n)) ** (-1 / scalar -@n));
my $hm = nearest(0.1, scalar @n / sum([map { 1 / $_; } @n]));
say "AM = $am, GM = $gm, HM = $hm";
```

**additional languages:**
Raku

As readers of this page will have noticed by now, I’m an… *enthusiast*… of clean code layout. Even though it makes no difference to run, maintenance and reuse is a whole ‘nother thing.

So I’m a sucker for lining things up vertically. Often when I pause, thinking of what to do next, I’ll fidget and line things up, using a couple of different parts of my brain at the same time. Consequently, I find the monk’s submission quite pleasing.

```
my $n = scalar @n; # Cardinal number
my $sum = 0;
$sum += $_ for @n;
my $am = $sum / $n; # Arithmetic mean
my $prod = 1;
$prod *= $_ for @n;
my $gm = abs( $prod ) ** (1 / $n); # Geometric mean
$sum = 0;
$sum += $_ for map { 1 / $_ } @n;
my $hm = $n / $sum; # Harmonic mean
printf "Output: AM = %.*f, GM = %.*f, HM = %.*f\n",
$DECIMALS, $am,
$DECIMALS, $gm,
$DECIMALS, $hm;
```

Being a mathematician, CY approaches the geometric mean in a unique manner. The result ends up the same, but you can see the mathematical language she uses to express it is in terms of an average multiplicand — this term to the power of the list length will yield the product of the list.

I also like the use of an associative array to hold what amount to attributes of the initial value. It’s solid structure with little to no overhead.

```
use List::Util qw/sum product/;
if (defined($ARGV[0])) {
my @in = @ARGV;
my %ans = %{mean(@in)};
say "AM = ", sprintf("%.1f", $ans{a});
say "GM = ", sprintf("%.1f", $ans{g});
say "HM = ", sprintf("%.1f", $ans{h});
}
sub mean {
my @n = @_;
my %mean = (
"a" => (sum @n) / scalar @n,
"g" => exp(log(product @n)/ scalar @n),
"h" => (scalar @n)/(sum map {1/$_} @n),
);
return \%mean;
}
```

**blog writeup:**
Mean Brazilians

Finally we’ll end with Peter, who changes this up a little bit by pre-processing a pass through the input list, calculating three new variables: a sum, a product and a sum of the reciprocals. When we add another variable for the number of list elements, we have all of the parts required to calculate any of the requested means.

```
# get started
$product = 1;
$sum = $reciprocals = 0;
$string = '';
# form sum, product and sum of reciprocals
for $n (@$example) {
$sum += $n;
$product *= $n;
$reciprocals += 1 / $n;
$string .= qq[$n, ];
}
# and tell the world
say qq[\nInput: \@n = (] . substr($string, 0, -2) . qq[)\nOutput: ] .
qq[AM = ] . sprintf('%1.1f', ($sum / scalar @$example)) .
qq[, GM = ] . sprintf('%1.1f', ($product ** (1 / scalar @$example))) .
qq[, HM = ] . sprintf('%1.1f', (scalar @$example / $reciprocals));
```

## Blogs and Additional Submissions in Guest Languages for Task 1:

**additional languages:**
Raku

**blog writeup:**
Pythagoras Was a Meanie - Programming Excursions in Perl and Raku

**blog writeup:**
I Cannot Count To A Brazillian: Weekly Challenge #157 | Committed to Memory

**blog writeup:**
The Weekly Challenge 157

**additional languages:**
Python

**additional languages:**
Raku

**additional languages:**
Go

**additional languages:**
Julia, Python, Raku, Ruby, Tcl

**additional languages:**
Javascript, Kotlin, Lua, Postscript, Python, Raku, Ruby, Rust

**blog writeup:**
RogerBW’s Blog: The Weekly Challenge 157: Pythagoras in Brazil

**blog writeup:**
Perl Weekly Challenge 157 – W. Luis Mochán

# TASK 2

# Brazilian Number

*Submitted by: Mohammad S Anwar*

You are given a number $n > 3.

Write a script to find out if the given number is a Brazilian Number.

A positive integer number N has at least one natural number B where 1 < B < N-1 where the representation of N in base B has same digits.

**Example 1:**

```
Input: $n = 7
Output: 1
Since 7 in base 2 is 111.
```

**Example 2:**

```
Input: $n = 6
Output: 0
Since 6 in base 2 is 110,
6 in base 3 is 20 and
6 in base 4 is 12.
```

## about the solutions

**Athanasius**,
**Cheok-Yin Fung**,
**Colin Crain**,
**Dave Jacoby**,
**Duncan C. White**,
**E. Choroba**,
**Flavio Poletti**,
**Jaldhar H. Vyas**,
**James Smith**,
**Jorg Sommrey**,
**Kueppo Wesley**,
**Laurent Rosenfeld**,
**Lubos Kolouch**,
**Matthew Neleigh**,
**Niels van Dijke**,
**Paulo Custodio**,
**Pete Houston**,
**Peter Campbell Smith**,
**PokGoPun**,
**Robert DiCicco**,
**Roger Bell_West**,
**Simon Green**,
**Ulrich Rieke**, and
**W. Luis Mochan**

In 1994, at the 9th Iberoamerican Mathematical Olympiad in Fortaleza, Brazil, the first problem for the competitors was prefaced by the following novel definition:

A number n > 0 is called “Brazilian” if there exists an integer b such that 1 < b < n – 1 for which the representation of n in base b is written with all equal digits

This basic form — of a number composed of a number of repetitions of a single digit — was not the novel part, having been studied at various time for a few decades at that point. These numbers are commonly called repdigits, or monodigits.

The specific coinage here, on the other hand, was not tying the representation to a single base; rather noting that it could be done in *some* base.

Well, almost any. *Terms and conditions may apply.*
As it turns out any number n is a repdigit when represented in a base one smaller than its value, *n* - 1. Although perhaps not obvious, the reasoning behind this is the same as the (possibly) more-familiar decimal expansion of ninths: 10/9 = 1.1(1), which is to say an infinite list of 1s. When we divide 10 by the value one less — 9 — then we get 1 with a reptend of 1, and if we write 10 in base-9, we get 11, a repdigit. The infinitely-repeating reptend of a decimal expansion and repdigits are, as might be expected, closely related concepts.

There were 24 submissions for the second task this past week.

## a South-American STATE OF MIND

**Duncan C. White**,
**Matthew Neleigh**,
**PokGoPun**,
**James Smith**,
**Robert DiCicco**,
**E. Choroba**,
**Paulo Custodio**,
**Dave Jacoby**,
**Kueppo Wesley**,
**Niels van Dijke**, and
**Colin Crain**

The task, of course, requires a fair bit of base-conversion in one form or another, which brings to mind the question of how to represent the larger base digits above 9. These are traditionally assigned the character values A through Z, but this schema, or any other for that matter, is one of convenience rather than settled law. As the converted values are only used internally to track repeated digits, we also saw an alternative approach to the problem that solves the various engineering trade-offs in a different way.

Duncan will start us off with a nice exploration of the subject, and how we can avoid assigning a single unique digit to each number entirely.

In his `isbrazillion()`

wrapper function, a short loop through allowed bases in turn call two helpers: `inbase()`

, which converts a number to a given base, and `repeated()`

which analyses the result for a single repeated character.

In the `inbase()`

function, the base conversion is performed by keeping track of the remainder in repeated integer division. As we mentioned above, the technical problem that came up in generalized base-conversion was the lack of designated characters in the larger bases to represent the numeric values. Here Duncan resolves the problem by simply maintaining the remainder as a decimal index for the number within a base, separating the positions with a delimiting hyphen. Thus the number 1707 in base-12 is rendered “11-10-3” instead of the more common “BA3”. Of course the number itself does not care how it is represented, and this method sidesteps the question of what to do above base-36 entirely.

```
fun inbase( $n, $b )
{
die "inbase($n,base $b): $b must be >1\n"
if $b<2;
my @x;
while( $n>0 )
{
push @x, $n % $b;
$n = int($n/$b);
}
return join('-',reverse @x);
}
```

The `repeated()`

routine splits the converted string on those hyphens into an array of values. After shifting the first value off of the array, each subsequent element is compared to the first, and if any are not equal the original then we are not repeating and the function returns 0. Otherwise if we successfully run the gauntlet then we have a proper repdigit number.

```
fun repeated( $dashstr )
{
my @x = split(/-/, $dashstr);
die "repeated: dashstr $dashstr has no '-'s\n"
if @x==0;
my $n = shift @x;
foreach my $v (@x)
{
return 0 if $v != $n;
}
return 1;
}
```

For those confused by the `fun`

keyword, he’s using `Function::Parameter`

to provide subroutine signatures, which come via introduced functions, or `fun`

.

Once he’s implemented the steps for determining whether a number is Brazilian, he then goes on to encase the whole thing in a loop to alternately find the first *n* numbers to satisfy the conditions.

Matthew follows a similar reasoning, only instead of producing his base conversion as an encoded string, he simply maintains the calculation as a list of remainder values to be examined. Again all the math is still kept as decimal values.

```
sub number_to_digit_list{
my $number = int(shift());
my $base = int(shift());
return(undef)
if($base < 2);
my @digits;
# Special case of the number being zero
if($number == 0){
return((0));
}
# Not zero- repeatedly convert remainders to
# "digits" then truncate the dividend...
while($number){
unshift(@digits, $number % $base);
$number = int($number / $base);
}
return(@digits);
}
```

Once a list of remainders is returned, the elements can be compared to each other and a flag is set if any differ.

```
foreach(@digits){
if($ARG != $digits[0]){
$match = 0;
last;
}
}
```

**additional languages:**
Go

Pokgopun provides an interesting scheme where the remainders when performing base conversion are not even kept in any sort of order. Using the remainders as hash keys, each instance found increments an associated counter. Then, when the conversion is complete, we don’t even need to count the results; instead we can count the hash keys. If there is only one key, there is only one value, signifying a repdigit.

```
{
my $r = $n % $b;
$digits{$r}++;
push @digits, $r if $debug;
last unless $n = int($n / $b);
redo;
}
if (keys %digits == 1) {
printf(", Since %d in base %d is %s", $_, $b, join("",reverse @digits)) if $debug;
$o = 1;
last;
}
```

**blog writeup:**
The Weekly Challenge 157

The next step, then, is to inline the verification check into to base conversion, recording the very first remainder and comparing all subsequent values to it. If any are not equal, then that base is not a repdigit and we immediately move to the next.

This results in a very compact routine.

```
sub is_brazilian {
O: for my $b ( 2 .. $_[0]/2 - 1 ) {
my $l = (my $n=$_[0]) % $b;
$n % $b == $l || next O while $n = int($n/$b);
return 1;
}
0;
}
```

**additional languages:**
Julia, Python, Raku, Ruby

Alternately, another common way to handle the problem was to off-load the computation of the base conversion off to a specialized imported function, picking one of a myriad of modules that are available for use.

The general trend in base conversion, though, is to use the alphanumeric character set of 10 digits plus 26 letters to accomodate representing the bases 2 through 36. Practically we can only then evaluate the numbers 4 through 38. This is a little restrictive, I must say, but the challenge did not specify a range, and all of these modules can be expanded with a larger character set to handle larger bases. The numbers, as we’ve said, don’t care which symbols are used, as long as they are unique.

Robert imports `Math::NumberBase`

to do his converting, which certainly sound appropriate. In this scheme, a number container object is instantiated in a specified base, and then filled from a base-10 value.

Once he has a converted number string, is is split into an array of characters and the first digit is compared to each of the others.

```
sub checkDigits {
my $num = shift;
my @arr = split(//, $num); # split digits into an array
my $digit = $arr[0]; # save first digit to match against
foreach (1..$#arr) { # check remaining digits
if( $arr[$_] != $digit){ # found a digit that does not match
return 0; # return failure
}
}
return 1; # return success
}
```

Choroba employs the talents of the module `Math::Base::Convert`

to produce this remarkably compact version. A regular expression matches and captures the first character and attempts to match every subsequent character until the end of the string.

```
use Math::Base::Convert qw{ cnv };
sub is_brazilian_number ($n) {
for my $base (2 .. $n - 2) {
my $converted = cnv($n, 10, [0 .. $base - 1]);
return 1 if $converted =~ /^(.)\1+$/;
}
return 0
}
```

Continuing through the variations, Paulo brings us `Math::BaseCnv`

along with a regular expression.

```
use Math::BaseCnv qw( cnv );
my $n = $ARGV[0] or die "Usage: ch-2.pl n\n";
say is_brazilian($n);
sub is_brazilian {
my($n) = @_;
for my $b (2 .. $n-2) {
my $cnv = cnv($n, 10, $b);
return 1 if $cnv =~ /^(\w)\1*$/;
}
return 0;
}
```

**blog writeup:**
I Cannot Count To A Brazillian: Weekly Challenge #157 | Committed to Memory

Dave notes that the challenge number, 157, is both prime itself and the arithmetic mean between the previous and next primes, 151 and 163. Which is both topical to the previous task and interesting in its own right.

To address the base conversion, he brings us `Math::BaseCalc`

to do the job.

After the conversion, he splits the string representation into individual digits and runs the list through `uniq`

form `List::Util`

. Then he tests the size of he resulting array to determine whether it has only one single digit.

```
use Math::BaseCalc;
use List::Util qw{ uniq } ;
sub brazillian_number ( $n ) {
for my $base ( 2 .. $n - 2 ) {
my @digits = map { $range[$_] } ( 0 .. $base - 1 );
my $digits = join '', @digits;
my $c = convert_to( $n, $digits );
my @ddigits = uniq sort split //, $c;
return 1 if scalar @ddigits == 1;
}
return 0;
}
```

Wrapping up our module overview, rather than selecting a more specific tool for the task, Kueppo simply brings in the `Math::BigInt`

library. which in addition to allowing arbitrary-position integers also provides a `to_base()`

method.

The repetitions or lack thereof are tracked using a regular expression. This is a slightly diferent form than what we’ve seen previously, capturing the first digit and then looking for a string of variable length to th eend of the string that is comprised only of one or more instances of the captured digit.

```
use Math::BigInt;
print "Input: ";
my $n = <STDIN>;
if ($n > 2) {
my($x, $count, $did) = (Math::BigInt->new($n), 0, 0);
foreach (2..$n - 2) {
my $n_in_base__ = $x->to_base($_);
if ($n_in_base__ =~ /^(.)\g1{1, }$/) {
print "Output: 0\nSince $n" if (! $did);
print "\tin base $_ is $n_in_base__\n";
$did++;
}
}
print "Output : 1\n" if ($did == 0);
}
```

Niels comes in with a wildcard, bucking the trend with an interesting logical inversion: for each permissible base, and then again for each digit value within that base, he attempts to form a repdigit number that converts back into the decimal value of the input. The actual calculations required are simple, if repetitive. It’s nice to see a different approach out there, reminding us there are alternate ways to solve the problem.

```
foreach my $base (2 .. $n - 2) {
foreach my $digit (1 .. $base - 1) {
my ($sum,$pos) = (0,0);
while ($sum < $n) {
$sum += $digit * $base**$pos++;
}
if ($sum == $n) {
say "n=$n is a Brazilian Number :: base$base(",join('|',($digit) x $pos),')';
exit;
}
}
}
```

**additional languages:**
Raku

**blog writeup:**
Waxing Numeric - Programming Excursions in Perl and Raku

Circling back, we’ll close the survey with my own solution. In it, a neat wrapper looping over bases supplies an up/down test on the Americo-African-Portuguese origin of a given input. This loop in turn uses a helper function that similarly validates a given base representation against continuous repetition.

We use a defined-OR operator to assign the first remainder to a variable, which is then used for comparison with any subsequent values. The remainders are kept in their decimal form, compared and then discarded as we don’t care about the actual base conversion, only the self-similarity, or lack thereof, among its digits.

```
sub brazilian ( $num ) {
## up/down check if number is a Brazilian number
for ( 2..$num-2 ) {
return $_ if digit_test( $num, $_ );
}
return 0;
}
sub digit_test ( $num, $base ) {
## up/down check for all digits are the same in a given base
## converts from base-10 to any given base
## does not internally store converted number other than
## single digit as base-10 sequence index: conditional
## 1 short-circuits returning 0 if non-repeated digit found,
## otherwise returns 1
my $rem;
my $digit;
while ( $num > 0 ) {
($num, $rem) = (int( $num/$base ), $num % $base);
$digit //= $rem;
return 0 if $digit != $rem;
}
return 1;
}
```

## Blogs and Additional Submissions in Guest Languages for Task 2:

**additional languages:**
Raku

**additional languages:**
Raku

**blog writeup:**
PWC157 - Brazilian Number - ETOOBUSY

**additional languages:**
Raku

**blog writeup:**
Perl Weekly Challenge: Week 157

**additional languages:**
Raku

**blog writeup:**
Perl Weekly Challenge 157: Pythagorean Means and Brazilian Number

**additional languages:**
Python

**blog writeup:**
Mean Brazilians

**additional languages:**
Javascript, Kotlin, Lua, Postscript, Python, Raku, Ruby, Rust

**blog writeup:**
RogerBW’s Blog: The Weekly Challenge 157: Pythagoras in Brazil

**additional languages:**
Python

**blog writeup:**
Three means and big bases

**additional languages:**
C++, Haskell, Raku

**blog writeup:**
Perl Weekly Challenge 157 – W. Luis Mochán

# _________ THE BLOG PAGES _________

**That’s it for me this week, people! Warped by the rain, driven by the snow, resolute and unbroken by the torrential influx, by some miracle I somehow continue to maintain my bearings.**

**Looking forward to next wave, the perfect wave, I am: your humble servant.**

# But if Your Unquenchable *THIRST* for *KNOWLEDGE* is not *SLAKED*,

# then *RUN* *(dont walk!)* to the *WATERING HOLE*

# and *FOLLOW* these *BLOG* *LINKS*:

**( … don’t think, trust your training, you’re in the zone, just do it … )**

**Arne Sommer**

- Brazilian Means with Raku (
*Raku*)

**Colin Crain**

- Pythagoras Was a Meanie - Programming Excursions in Perl and Raku (
*Perl & Raku*) - Waxing Numeric - Programming Excursions in Perl and Raku (
*Perl & Raku*)

**Dave Jacoby**

**Flavio Poletti**

- PWC157 - Pythagorean Means - ETOOBUSY (
*Perl & Raku*) - PWC157 - Brazilian Number - ETOOBUSY (
*Perl & Raku*)

**Jaldhar H. Vyas**

- Perl Weekly Challenge: Week 157 (
*Perl & Raku*)

**James Smith**

- The Weekly Challenge 157 (
*Perl*)

**Laurent Rosenfeld**

**Luca Ferrari**

- Perl Weekly Challenge 157: numbers – Luca Ferrari – Open Source advocate, human being (
*Raku & PostgreSQL*)

**Peter Campbell Smith**

- Mean Brazilians (
*Perl*)

**Roger Bell_West**

- RogerBW’s Blog: The Weekly Challenge 157: Pythagoras in Brazil (
*Perl & Raku*)

**Simon Green**

- Three means and big bases (
*Perl*)

**W. Luis Mochan**