Reng v.3.2, 88 bytes
(Noncompeting, postdates question.)
2#y2#z"a"1Ø Ø3r1\
:1+>y1-?!v$z1+:#y#zRzeq!^
^ :y#<
i sve(*?v)
?~n>$ 2.>076**
This is one heckuvan answer.
Initial
2#y2#z"a"1Ø
Stores 2 to y
(the temporary counter) and z
(the overall counter), and initiates the stack with "a"
then goes to the next line.
Loop
:1+>y1-?!v$z1+:#y#zRzeq!^
^ :y#<
First, :1+
duplicates the previously made run of characters and increments it to work with the next one. Then...
Generating N copies of a number
>y1-?!v
^ :y#<
This loops until y == 0
. Once y
is zero, we exit the loop. Otherwise, we put y - 1
back into y
and duplicate the character being worked with it.
Breaking out of this loop
$z1+:#y#zRzeq!^
This drops y
from the conditional and increments and duplicates z
, which is then put into y and z. Then, if R
(26 + 1) is z
, we go to the next part. Otherwise, the loop continues again.
Transition
Ø3r1\
^
This goes out of the loop, pushes 1
(our equality counter), reverses the stack, and goes to the third line.
Final
i sve(*?v)
?~n>$ 2.>076**
i sve(*?v)
loops until (a) there is no input or (b) the equality counter is 0. In the first case, the first v
is met, and we drop the -1 bit, skip over the >0
bit (2.
), and output 42 (6*7*equality
), skipping ~
with a conditional. Otherwise, the second v
is encountered, and a zero is pushed before the 76**
, so this makes it zero. The conditional activates the ~
(exit program) command because the TOS is falsey, and thus no output is given.
Many of the solutions provided here are wrong because they print 42 when the string is longer than the desired string and the prefix matches with the desired string. – fR0DDY – 2011-03-10T10:30:13.170
@froddy: What if the only characters? following the string (is|are) a line break? My usual input mechanism doesn't care whether the input is terminated by a line break or not but yield the same in both cases, for example. – Joey – 2011-03-10T13:22:54.790
@fR0DDY : There was no clear definition on how the rest of the input should be handled, so there's no 'wrong' here. – PatrickvL – 2011-03-10T15:46:48.440
3@PatrickvL It does mention 'only' if the input is the given string. So
abbcccddddeeeee...zzabc
does not satisfy that i suppose and i can see some programs giving yes on that input. – fR0DDY – 2011-03-10T15:56:53.9172@fR0DDY : Let me put it another way : There's no specification on how input is delimited, so that's open to interpretation. There's also no mention of character encoding (I guess most of us assume the default of their environment - ANSI, UTF8 and UTF16LE will be the most popular ones). Also no mention how the input is presented - is it entered via the standard input, via a command-line parameter? So you see - having all this freedom gives way to some interpretation that you would mark as 'incorrect', while others would judge it 'compliant'. NOFI, but this is daily practise for some of us. – PatrickvL – 2011-03-10T16:10:31.447
Is the sample input supposed to contain invisible nonprintable characters? Because it does. – None – 2017-02-12T21:18:09.020
muntoo: How should a trailing line break in the input be handled (i.e. valid input vs. valid input with a line break appendded)? Would that be invalid already since the input is not exactly the specified one? Also, may 42 be part of the output for invalid input or may 42 only be printed if the input matched? – Joey – 2011-03-12T15:05:09.767
Can we use uppercase instead? – Adám – 2017-05-04T12:37:37.323
This question’s score should be left as is... – JayCe – 2018-08-01T21:59:42.723
@Joey Trailing line breaks don't have to count as input. – Mateen Ulhaq – 2011-07-01T02:38:11.607