The task is taken from an MIT lecture by Prof. Devadas called You can read minds. A detailed explanation of the trick can be found in the linked video, or in this document. I'll try to explain it in simpler terms.
It turns out this was invented in the 1930's, and is known as the "Five-Card Trick...
The challenge is there. I can either replicate the JS solution, but that means lexographic ordering, plus to generate similar 'idx,card' string I'd need to 1) find the index 2) format to string 3) pad with '0' 4) concat with original card
Otherwise I could also find the index, ×9 (or some factor), add the index of the card's color (0 to 3), and compare those...
@Ven i wrote down all permutations of 0 1 2 and the expected results. i tried a few silly things and i noticed that 2⊥ gives almost consecutive numbers: 4 5 6 8 9 10, so i tried to squeeze that range
i tried floor-multiplying by 0.9, 0.8, and at 0.7 i noticed that it's all consecutive integers
@Ven the challenge says: "There are 13 ranks, 2,3,4,5,6,7,8,9,10,J,Q,K,A", so you must put it at the end
Dyalog invite you to join our live webinar, Introducing the 2019 APL Problem Solving Competition, on Thursday 25 April at 15:00 UTC (San Francisco 8am/New York 11am/London 4pm/Copenhagen 5pm/Bangalore 8:30pm).
https://dyalog.tv/Webinar
#DyalogAPL
@dzaima My idea for a keyboard is to have a sparse looking display of just 5 rows of 6 buttons each, except the last button in the last three rows is double width:
The four leftmost buttons in the next two rows work the same, but the rightmost double-width button needs to be pulled in one of the cardinal directions, as on your keyboard. The third row's multi-key is ↑back ↓fwd ←bksp →del:
J X Y Z ↶
j x y z ⌫ ⌦
¯ 7 8 9 ↷
The fourth row's multi-key is cursor movement:
E P Q R ↑
e p q r ← →
. 4 5 6 ↓
The fifth row also has four pull-up keys, but the big key is Enter:
@Ven It isn't ordered by frequency, but rather by subject: Top row is numerics, logic, shape, function, structs. Second row is arithmetic, comparison, selection, monadic-operators, dyadic-operators, data. ¯ and j are paired as they extend the natural numbers. . and e are paired as they scale numbers. 0⍬⍝ are all a form of nulling.
I like the musing by the author saying it's easier to type with a QWERTY layout compared to an ABCDEF layout. I loathe each and everything that comes with an ABCDEF layout by default for typing.
@Adám ah, that's a good idea taking the extended pullable set to the max. Where'd the 1st two row extensions get drawn though - drawing them all for every key above would make them extend way over the keyboard space, obstructing text view. current system doesn't allow for generic pull mappings other than the orthogonal directions but adding that has been on my mind - there'd be a lot of space for user-added shortcuts for project-specific things (e.g. (+/÷≢), G.rect, etc.)
@Adám that's also definitely a thing I have wanted to add
my goal with my APL layout was to minimize the amount of swiping required, yours would have some pretty long swipes
the swipe detection in mine isn't exactly invoked by the cursor being over a neighboring character, but rather a specific distance away from the center as to allow off-centered taps to only care about swipe size to tell whether something special has to happen as IMO that's way easier to control than a specific position
@dzaima True, but it would have a look-and-feel much closer to a normal calculator.
@dzaima I'm sure your layout would allow much faster typing than mine, once one has learned it. Yes, precision on mine would be a problem, and it requires visual feedback of the currently held character. Your's allows "blind" typing.
@dzaima One thing I do think you should adapt from my layout is a single button which is swiped to move the cursor in the four directions, instead of two adjacent key presses for left and right but two swipes on the same key for up and down. Tapping the direction key should insert a space.
@Adám reason for me not combining the direction keys is that the left/right moves would definitely be used by being held for faster travel and using a swipe to do that feels weird (it's what currently happens to the vertical movement however), though that's personal opinion, so subject to change
@Adám I don't have a pointing stick nor a laptop, but that's a good point
@Adám since you're the one here with lots of APL code, do you have statistics on character usage? I'd be interested in where the numbers actually are in the usage frequency to decide whether they're worthy top-level spots
beyond 0/1 (any maybe 2) I don't think writing code would need random access to digits, mostly used for hardcoded data, for which switching a layout would be allowable
@Adám that again doesn't relate to the frequency of APL chars, but i realize now that they probably wouldn't relate much
7 being 100× less used than 1 does seem to say something though
1 6.11748%
3 4.27327%
2 3.52627%
⍵ 3.51505%
9 3.20970%
7 3.16225%
← 3.12775%
0 3.10273%
s 2.98974%
4 2.59294%
e 2.49720%
t 2.40662%
⍺ 2.29363%
5 2.11421%
) 2.08402%
( 2.08229%
6 2.02536%
r 1.97015%
a 1.96843%
8 1.95377%
n 1.74847%
p 1.66997%
{ 1.58285%
o 1.57681%
} 1.57681%
' 1.53110%
c 1.40430%
d 1.40171%
, 1.38446%
i 1.36979%
l 1.36548%
m 1.28612%
: 1.13862%
f 0.83326%
/ 0.77461%
u 0.76167%
b 0.75390%
⎕ 0.73406%
¨ 0.73234%
⍴ 0.69783%
k 0.64090%
h 0.62279%
x 0.60985%
↑ 0.57190%
= 0.56586%
v 0.56155%
@dzaima Yeah, and all 10 digits within the 20 most common characters. I'd say "the numpad" merits easy access.
Ah, hold on, pco probably skews the result quite a bit. Let me take that one out.
@dzaima Yes, as suspected, same thing but without pco:
⍵ 4.86555%
← 4.34333%
s 4.15586%
e 3.46444%
t 3.34636%
⍺ 3.21976%
) 2.90204%
( 2.89961%
a 2.74379%
r 2.72432%
n 2.39686%
p 2.28487%
{ 2.20575%
o 2.20453%
} 2.19723%
1 2.14975%
' 2.14367%
d 1.96837%
c 1.96472%
, 1.93916%
l 1.92333%
i 1.91360%
m 1.79187%
0 1.63849%
: 1.55814%
f 1.15887%
u 1.07366%
/ 1.07244%
b 1.04079%
⎕ 1.02984%
¨ 1.02375%
⍴ 0.96167%
k 0.89228%
h 0.87889%
x 0.85454%
↑ 0.80585%
2 0.78394%
v 0.78272%
⊃ 0.77055%
= 0.76568%
↓ 0.74134%
+ 0.70969%
≡ 0.69021%
⊂ 0.68047%
g 0.66708%
. 0.53805%
Here's the formula I used (I should have let the bot do this…): {(⊂⍒n)⌷'%',⍨(⊣/⍵),5⍕⍪100×n÷+/n←⊢/⍵},∘≢⌸' '~⍨∊('''[^'']''' '⍝.*$'⎕R''⎕NR)¨(⎕NL-3 4)~⊂'pco'⊣⎕CY'dfns'
the top 14…24 chars take 6.7%, a bit more than numbers. seems my best bet is to make 3 layouts - one without top-level numbers, one with, and one specifically for data hardcoding..
at least now I have actual statistics to design by
@Adám
⍵ 5.26282%
← 4.69697%
s 4.25485%
e 3.51628%
t 3.50726%
⍺ 3.36676%
( 3.12057%
) 3.12057%
r 2.77384%
a 2.74677%
n 2.41809%
{ 2.40391%
} 2.40391%
p 2.30208%
1 2.27372%
, 2.18865%
o 2.18607%
c 1.97726%
d 1.96308%
l 1.95664%
i 1.91024%
m 1.87544%
0 1.68338%
: 1.60604%
f 1.20904%
/ 1.12397%
¨ 1.11624%
b 1.06210%
u 1.05695%
⍴ 1.02214%
⎕ 0.96801%
k 0.95641%
h 0.93450%
x 0.93321%
↑ 0.86876%
⊃ 0.82236%
2 0.80173%
↓ 0.80044%
⊂ 0.77853%
v 0.77466%
+ 0.73728%
≡ 0.72697%
= 0.70635%
g 0.69088%
∇ 0.53492%