57 chars of APL vs. uncounted lines of C#, SQL, LINQ, F#, LISP, Powershell etc. :-)
MBaas
can anyone perhaps find a way to make it even shorter?
http://www.craigmurphy.com/blog/?p=1417#comment-66863
Cheers
Michael
Simon Marsden
Thanks for alerting me to this. I posted a follow-up message on the
blog, and created a new Wiki page on the APL Wiki:
http://aplwiki.com/Studio/LetterDiamonds
My solution would take 42 characters if you use single-letter variable
names, but I'm not trying to steal your Tee-shirt! I'm just hoping
that a few new people will be inspired to learn APL.
If anyone else comes across other programming challenges like this,
it'd be great if we could get the word out about APL.
Cheers
Simon
MBaas
well - to be honest, I thought I wouldn't have time to take part at
all. Then I used a little break while waiting for a setup to complete
and came up with that solution.
My appreciation of Dfns made it so "long", I appreciate the way you
elegantly assigned the intermediate results .
So you not only have the shorter solution, you also went the extra-
mile and even did that great documentation on the wiki - so that shirt
is well deserved :)
Cheers
Michael
On Apr 16, 4:04 pm, Simon Marsden
Graham
"MBaas" <m...@mbaas.de> wrote in message news:cc2ba9c5-bb03-4df1...@e18g2000yqo.googlegroups.com...
> Hi,
>
> can anyone perhaps find a way to make it even shorter?
> http://www.craigmurphy.com/blog/?p=1417#comment-66863
Try this in Dyalog with index origin 1. I make it 38
z,0 1↓⌽z←z⌽⊃n↑¨⎕A[z←(⍳n),1↓⌽⍳n←⎕A⍳'F']
or just for fun its cousin
(⌽z),0 1↓z←z⌽⊃n↑¨⎕a[z←(⍳n),1↓⌽⍳n←⎕a⍳'F']
Graham.
Morten Kromberg
wrote:
> "MBaas" <m...@mbaas.de> wrote in messagenews:cc2ba9c5-bb03-4df1...@e18g2000yqo.googlegroups.com...
> Try this in Dyalog with index origin 1. I make it 38
z,0 1↓⌽z←z⌽⊃n↑¨⎕A[z←(⍳n),1↓⌽⍳n←⎕A⍳'F']
One less ... but you need the power operator... :-)
{⌽⍉⍵,0 1↓⌽⍵}⍣2⊃(-⍳⍴l)↑¨⌽l←(⎕A⍳'F')↑⎕A
I have a feeling it should be possible to simplify the above further,
but I can't find it right now...
Morten
kaitho...@googlemail.com
Guys, hang on - you gonna repeat a mistake we all made in the past
several times already.
We gonna win the competition. Others count lines or even pages, we
count symbols.
Simon's solution was certainly not the shortest possible solution, but
it combined conciseness with readability almost perfectly.
Furthermore, it's a general solution.
Trying to make it even shorter by one symbol might look ridiculous to
non-APLers, and maybe even to some APLers.
Kai
Graham
<kaitho...@googlemail.com> wrote in message news:52f4276f-0555-4eae...@x3g2000yqa.googlegroups.com...
Sorry Sir!!!! I can see your point but I am afraid for some of us with an acutely competitive nature we can never resist a challenge and the original poster did ask if anyone could beat 57.
Also within the APL community I find these sort of challenges can be very instructive and lead one to write more efficient code and I do not mean killer one liners. In normal coding I avoid them in favour of readability as you will have seen from my contributions to the wiki.
Graham.
gladeyed
> Simon's solution was certainly not the shortest possible solution, but
> it combined conciseness with readability almost perfectly.
> Furthermore, it's a general solution.
It's not quite a general solution since it implies origin 1 and there
may be a []ML issue dependent on version.
David
Graham
"Morten Kromberg" <mk...@dyalog.com> wrote in message news:ffbc26ec-011a-4486...@b7g2000pre.googlegroups.com...
Morten
Sorry Kai!
Morten
If you use my index method above on your quadrant you can lose two more:
{⌽⍉⍵,0 1↓⌽⍵}⍣2⊃(-n)↑¨⌽⎕A[n←⍳⎕A⍳'F']
Graham.
kaitho...@googlemail.com
It depends on the definition of "general". You can run the code in
APLX, APL2 and in Dyalog with []ML=3 without any change. In this
respect it is certainly a general solution.
Kai
Morten Kromberg
> Guys, hang on - you gonna repeat a mistake we all made in the past
> several times already.
Kai, I don't quite agree: The solution using "power" is "significantly
more general". If we make use of Graham's simplification, and leave
out the generation of the argument we get a general function:
diamond←{{⌽⍉⍵,0 1↓⌽⍵}⍣⍺⊃(-⍳⍴⍵)↑¨⌽⍵}
(27 symbols):
1 diamond 'ABC'
C
B
A
B
C
2 diamond ⍳5
0 0 0 0 1 0 0 0 0
0 0 0 2 0 2 0 0 0
0 0 3 0 0 0 3 0 0
0 4 0 0 0 0 0 4 0
5 0 0 0 0 0 0 0 5
0 4 0 0 0 0 0 4 0
0 0 3 0 0 0 3 0 0
0 0 0 2 0 2 0 0 0
0 0 0 0 1 0 0 0 0
4 diamond 'APL'
A A
P P P P
L L L
P P P P
A A
P P P P
L L L
P P P P
A A
... We have now moved the original problem along into a significantly
more general space, we have a broader understanding of "the problem
space", which is one of the things that reasoning about a problem in
APL can do for you :-)
kaitho...@googlemail.com
Okay. No comment. Keep going ;)
> Also within the APL community I find these sort of challenges can be very instructive and lead one to write more efficient code and I do not mean killer one liners. In normal coding I avoid them in favour of readability as you will have seen from my contributions to the wiki.
I slightly disagree. APL is short by definition. Others are not.
That's why others need to take part in competitions like that. It's
their weakness, they need to improve.
Writing more efficient code sounds okay, but what exactly are we
talking about? Less symbols == more efficient?? Hardly. To find the
most efficient code we need to measure execution time. Counting
symbols won't help.
We should concentrate on readability (FIRST priority) and execution
time (SECOND priority), because that's were we are not exactly in a
strong position, to put it mildly. Replacing meaningful names by one-
letter names only to cut the number of symbols down is in my view a
mistake.
We are known as the "Write-once-read-never" guys. I would like to get
rid of this fame.
Kai
Morten Kromberg
arrays) - and uses a completely different approach :-)
∇ r←isodiam w;n;i;j;m;⎕IO
[1] ⎕IO←0
[2] n←¯1+⍴w
[3] i←|(⍳n+n+1)-n
[4] m←i∘.=j←n-i
[5] r←(⍴m)⍴(,m)\w[1⌽2/¯1↓j]
∇
Argument is the list to be diamondized:
isodiam¨'APL' (1 2 3)
A 0 0 1 0 0
P P 0 2 0 2 0
L L 3 0 0 0 3
P P 0 2 0 2 0
A 0 0 1 0 0
Runs 2x faster than the original and I think it needs half the space
as well:
cmpx 'isodiam ⎕A' '2 diamond ⎕A'
isodiam ⎕A 1.8E¯4 0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
2 diamond ⎕A 4.0E¯4 +127% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
And now I promise to shut up and retreat to Powerpoint ...
Graham
<kaitho...@googlemail.com> wrote in message news:3b6589d2-270e-445b...@y7g2000yqa.googlegroups.com...
> Writing more efficient code sounds okay, but what exactly are we
> talking about? Less symbols == more efficient?? Hardly.
It can be when the symbols are operators. Clearly not when one is just shortening variable names.
> To find the most efficient code we need to measure execution time.
Agreed!
For me writing more efficient code comes from seeing new ways in which to structure problems in APL and how to apply new APL functionality. Coming from an APL+WIN background the effective use of dynamic functions is new to me for example.
Graham.
Martin Neitzel
> For me writing more efficient code comes from seeing new ways in which
> to structure problems in APL and how to apply new APL functionality.
> Coming from an APL+WIN background the effective use of dynamic functions
> is new to me for example.
Coincidentally, I'm right now venturing along the reverse path a bit:
I'll giving a presentation on APL and its history on the European
edition of the yearly Vintage Computer Festival in two weeks.
Because I won't have my own laptop with me, I needed to prepare
something simple which will boot reliably from a diskette or USB
stick on someone else's laptop and drop me into an APL system.
Candidates would have been either IBM's TryAPL2 or SHARP/ISI's
"APLI-PC", and I chose the latter because it one of the ancestors
of J which is my only APL dialect since 1991.
I learned and loved "flat APL" back in mid-eighties but going
back in time and evolution to the SHARP system, I immediately
miss all of the "new APL functionality" Graham is mentioning:
- no "direct definitions" / "dynamic functions"
- no user-definable operators, no user-defined.
functions as arguments to the built-in operators.
- MUCH smaller set of primitives.
I know that everybody who gives J a first look is a bit overwhelmed
when confronted with nearly 240 primitives. It certainly takes
some time to commit, say, the catenation variants , ,. ,: and their
meanings to memory but trust me: having to make do without them
is more painful.
Summary: don't be shy but go ahead and embrace any new APL
functionality vendors provide you with.
Martin
Curtis A. Jones
wrote:
...
>
> I'll giving a presentation on APL and its history on the European
> edition of the yearly Vintage Computer Festival in two weeks.
Martin,
Vintage Computer Festival in Europe? The Vintage Computer Festivals
here in San Jose and Mountain View, California have been wonderful.
But I don't see one in Europe at http://www.vintage.org/events.php
Can you tell us more? Curtis
Martin Neitzel
>Vintage Computer Festival in Europe? The Vintage Computer Festivals
>here in San Jose and Mountain View, California have been wonderful.
>But I don't see one in Europe at http://www.vintage.org/events.php
>Can you tell us more? Curtis
It's http://vcfe.org/ but the web pages are very minimalist. It's
a yearly event in Munich, Germany, essentially organized by a single
person - Hans Franke.
Martin
Seth
<kaitho...@googlemail.com> wrote:
>I slightly disagree. APL is short by definition.
Except when it isn't. Some people can write FORTRAN in any language.
Seth