« first day (2508 days earlier)      last day (139 days later) » 

12:43 AM
@RikedyP Ooh. Very nice resource... which I see is listed under the "Resources" tab of the homepage. Thanks for the pointer. Will ping you if I stumble across something that'd be a good addition.
 
 
2 hours later…
3:09 AM
@LdBeth Will you publish your answers when this is done? Feels like a neat idea to encode hands as numbers, but in practice I ended up with a very un-neat solution, and that was just part 1.
 
 
2 hours later…
5:33 AM
@Lapwing482 That part is +/{10*≢⍵}⌸'AAJKK' or replace 10 by 6 for more compact number
     (5⍴6)⊤+/{6*¯1+≢⍵}⌸'CCDDA'
0 0 0 2 1
How to handle same type? Just multiply the above result by 1000000 and add 14⊥'23456789TJQKA'⍳⍵
Day8 is straightforward, use LCM for part2
 
 
6 hours later…
11:29 AM
@LdBeth does the problem text actually say that it works with lcm? seems like it's unspecified information that all A-Z distances for a path are the same
though it wouldn't be the first time this year that there is unspecified information required
 
 
2 hours later…
1:00 PM
Welcome to APL Quest 2022-7! Today's quest is Just Golfing Around:
> In golf, lower scores place higher – the lowest score places first and the highest score places last.
Write a function that:
• takes a right argument that is a non-decreasing vector or scalar of strictly positive integers, representing a set of scores.
• returns a numeric vector of the place for each score; for duplicate scores, it returns the average of the places they hold.
 
I think I have a nice one
∊(≢⍴(+/÷≢))¨⊆∘⍋⍨
 
∊(⊂≢⍴+⌿÷≢)⍤⊢⌸⍤,
 
but fails on the test
havent fifgured out yet why
 
The problem statement says this problem has several viable approaches, including using , , and . So, assuming we fix the problem, we've all three, 'cause I have a -based solution.
@Richard My guess would be that it is becuase you have three monadic functions in a row, intending atops, but getting a fork.
Yup, indeed, {∊(≢⍴(+/÷≢))¨⊆∘⍋⍨⍵} works, except for scalars, which is of course trivial to fix.
 
@Adám ⍸⍨ also is a good start indeed
 
1:03 PM
Yes, that's like a third of my solution.
 
@Adám I still don't understand. What should I have done different. What you wrote is the same or not?
 
I wrapped it in a dfn, wherein the snipped just applies each function after the previous.
 
@Adám Your solution is 6 characters‽
 
No, 8, but fails on a scalar.
 
@Adám yes, but is that because of tryApl or should I have done something different
 
1:09 PM
No no, because when you test using a normal interpreter (including TryAPL), you probably juxtapose your solution with an input, but that makes the whole thing a large expression. But the quest was to create a stand-alone function.
 
ok!
 
Compare ∊(≢⍴(+/÷≢))¨⊆∘⍋⍨68 71 71 73 with (∊(≢⍴(+/÷≢))¨⊆∘⍋⍨)68 71 71 73
The latter parses as (∊68 71 71 73) (≢⍴(+/÷≢))¨ (⊆∘⍋⍨68 71 71 73)
 
yes got it, thanks!
 
Btw, you don't need to parenthesise +/÷≢
 
so something like ∊(≢⍴+/÷≢)¨⍤(⊆∘⍋⍨)⍤, should work
 
1:12 PM
Yes, or even ∊(≢⍴+/÷≢)¨⍤⊆∘⍋⍨⍤,
 
2÷⍨⍸⍨+⍳⍨
 
Ah yes, was already removed in my final solution, copied the wrong one.
@rabbitgrowth :)
 
@rabbitgrowth Indeed. Equivalent to mine.
 
2÷⍨(⍸+⍳)⍨?
 
Not even. 2÷⍨⍳⍨+⍸⍨
 
1:15 PM
Any reason you put ⍳⍨ on the left and ⍸⍨ on the right?
 
No, not at all.
 
@Adám is not working I thnik
 
Why not?
 
just tested it, looking at it now.
 
That was fun to figure out :)
 
1:17 PM
@rabbitgrowth ah, so ⍳⍨ returns the index of the first occurence of each number and ⍸⍨ the one of the last, right?
 
Right.
 
why does behave like that?
 
It tells you which interval the right side element belongs in, among the elements of the left argument.
Now, if the left argument has duplicates, then we give "precedence" to already existing elements, with the newcomer going last.
 
@Adám The argument for ⍳ should be the original input and not the result of ⍸
sorry if I am worng
2÷⍨(⍸+⍳)⍨ is working
 
It is. Did you forget parenthesis/naming? The fork returns…
 
1:20 PM
it's a train, wrap it in parens
 
:) oops
realy nice solutions. Also the one from @RubenVerg
 
It's cool and are (accidentally?) symmetrical like that.
 
ovs
2÷⍨⍋+⌽⍤⍒ is also 8 without handling scalars :). Though a bit longer to fix
 
@rabbitgrowth Not entirely accidental.
@ovs Ooh, I like that. Nice illustration of not just being ⌽⍋.
 
Just for fun, this was my solution during the competition. After just stepping in to APL
 prob1_7←{
     ⍬≡⍴⍵:1
     a←(⍵⍸⍵)
     b←(+⌿⍵∘.=⍵)
     a+2÷⍨1-b
 }
 
1:25 PM
You've come a long way. Congrats!
OK, I think we've exhausted this one. See you next week for 2022-8: Let’s Split!
 
Could you do a speed test? I am curious of the difference between ⌸ ⍸ and⊆
 
Oh, sure.
      Key←∊(⊂≢⍴+⌿÷≢)⍤⊢⌸⍤,
      Partition←∊(≢⍴+/÷≢)¨⍤⊆∘⍋⍨⍤,
      Interval←2÷⍨⍸⍨+⍳⍨
      Grade←2÷⍨⍋+⌽⍤⍒
      'cmpx'⎕CY'dfns'
      +/≠s←{⍵[⍋⍵]}?5e3⍴1e4
3952
      cmpx(⎕A ⎕NL ¯3),¨⊂' s'
  Grade s     → 4.1E¯5 |      0%
  Interval s  → 2.9E¯5 |    -29%
  Key s       → 6.0E¯3 | +14623% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  Partition s → 2.0E¯3 |  +4780% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
The problem with and is that intermediate values are nested.
 
ah, partition is worse than I expected
 
Ooh, I have an idea for something even more efficient.
 
I think the problems in this year (2022) are very good and make APL shine.
 
1:35 PM
@Adám how about, in the Key solution, removing the enclose in the operand and then doing ~0?
 
That's a good idea, since the input is strictly positive, but I doubt it will help much, as Key can't take any shortcuts.
      Key2←0~⍨∘,(≢⍴+⌿÷≢)⍤⊢⌸⍤,
      cmpx'Key s' 'Key2 s'
  Key s  → 6.0E¯3 |   0% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
  Key2 s → 5.3E¯3 | -12% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
I have this idea to work of ≠s which can be computed fast with 1,2≠/s
Still working on it…
 
:)
 
Got it!
Nah, it is slower. Never mind.
Have a good weekend!
 
1:52 PM
Would you mind to share it anyway?
 
2:19 PM
{l/i+0.5ׯ1+l←¯2-/(1+≢⍵),⍨i←⍸1,2≠/⍵}
Made this thing that was more than twice as slow as 2÷⍨⍸⍨+⍳⍨. Oh well.
And replacing the in 2÷⍨⍋+⌽⍤⍒ with ⍳⍤≢ still doesn't beat 2÷⍨⍸⍨+⍳⍨.
 
2:50 PM
Oh, looks like the dfn is actually a lot faster if the input is longer.
 
 
3 hours later…
6:14 PM
@RubenVerg I used a much stronger assumption: when it reaches the Z it is always the last direction instruction of the list been executed
so I only record how many times the entire list of instructions has been executed and multiply result by the length of instruction list
 

« first day (2508 days earlier)      last day (139 days later) »