@Adnan ÅΓ isn't in the "Extended Math & List Commands" on the github wiki yet (mentioned just yet here: codegolf.stackexchange.com/questions/170872/…). @Mr.Xcoder You've only updated the Commands page, or also the Extended Math & List Commands page on the wiki last week?

I've updated both pages, yes. I probably missed that command.

Ugh, turns out I've skipped a lot of Å commands

Ah ok. I indeed just saw you updated it 3 days ago.

@KevinCruijssen Thankfully, this isn't really my fault. Some commands have been added in the meantime :P

I thought I missed them first, but no, they've been added later

We finally have apply to every bth element, cumulative reduce, integer partitions, next prime, previous prime and nearest prime!! \o/

@KevinCruijssen Done and Done.

@Mr.Xcoder Ah ok, sneaky @Adnan added some more this weekend. :D

@Mr.Xcoder Nice and nice.

@Mr.Xcoder And very nice! ;D

lol

Hmm, those all seem pretty useful. Looking forward having some challenges which can utilize 05AB1E's new builtins :)

Or I'm gonna look for existing challenges where I can use them when I have some more time ;)

I already have some in mind which I can answer. I'll post them shortly, to feature how useful the new additions are :P

:)

Roman Army shields, for example, can be solved in 17 without dealing with [

With ÅœΣDŲP*Z}θDt4*+O, for example.

@Adnan I've found a bug with the prime checker p. For some values it returns a truthy result instead of falsey even if they aren't primes (49 or 55 to give some examples): ₄Lʒp}g (amount of primes <= 1000) returns 332 in the new 05AB1E and 168 in the legacy version.

Ugh that's bad

def is_prime?(value) when value in [2, 3, 5, 7], do: true
def is_prime?(value) when value < 2 or rem(value, 2) == 0 or rem(value, 3) == 0 or rem(value, 5) == 0 or rem(value, 7) == 0, do: false
def is_prime?(value), do: is_prime?(value, :math.sqrt(value) |> Float.floor |> round, 5)
def is_prime?(_, current_prime, upper_bound) when current_prime > upper_bound, do: true
def is_prime?(value, current_prime, upper_bound) do
    cond do
        rem(value, current_prime) == 0 -> false
        rem(value, current_prime + 2) == 0 -> false

Relevant portion of code.

@KevinCruijssen Hmm..., here the primality test seems perfectly valid... The issue may lie somewhere else

@Mr.Xcoder Hmm, that's indeed weird.. :S

@Mr.Xcoder The to_number part seems to work fine as well in Elixir.

Not sure what else could cause 55p and 49p (among others) to return 1 when the only relevant code (as far as I can see) is "p" -> Stack.push(stack, call_unary(fn x -> to_number(IntCommands.is_prime?(to_number(x))) end, a))

to_number portion of boolean works fine as well.

@Mr.Xcoder @KevinCruijssen I remember fixing the code for the is_prime function but don't remember when

I'm assuming this hasn't been synced to TIO yet since it works locally

@Adnan Ah ok, that is the first thing that mades sense thus far. Ok, in that case it should be fixed when the latest commits are on TIO. Thanks for clearing up the mystery. :)

Now I can concentrate on work again, lol ;p

hahahaha

@KevinCruijssen that's not a good thing, is it? :P

XD

It is when you have deadlines ;p

(Not right now though, otherwise I wouldn't be here to begin with of course. :) )

Indeed, the prime test was last fixed ~2 days ago, it's not in TIO yet

Anyway, the rewrite of 05AB1E made me decide to learn Elixir.

Hmm, do we have a 1 or 2-byte builtin for middle character of a string? If not, what would be the shortest way to get the middle character of an (odd-length guaranteed) string?

@KevinCruijssen I'm a bit out-of-date on the latest month of changes, but a 4-byte solution would be 2äнθ

In legacy, g;è

@Mr.Xcoder Thanks, and the ï can be dropped as well.

Just did it

Noticed. ;)

Thanks

Don't know why it doesn't work in v2

ï doesn't seem to convert to int anymore

Umm...

Umm'...

Ignore my now deleted comments, g, g;, and 3è all work in the new version. g;è and g;ïè not however.

Apparently a bug then

Emigna is right

Or maybe not on TIO yet

Could be

That's my initial thought as well

Considering the is_prime didn't work either and was also using to_number

Does it work locally, @Adnan (g;ïè and/or g;è)?

Does either of you have 05AB1E locally? Or you also only use TIO like me?

Relevant line:

"ï" -> Stack.push(stack, call_unary(fn x -> to_number(x) end, a))

I only have the old version in python

^

I don't have Elixir installed, I learn Elixir and test it online

I'll install it, though

Damn, brew update takes so long

ಠ_ಠ

@Mr.Xcoder ah okay, that needs to be to_integer instead of to_number

will fix this as soon as possible

@Adnan Do you have any idea why ^^^^ happens?

I have absolutely no idea

that does not make sense in any way

:( Then I cannot run it locally

oh nevermind I found the problem

All ears

~> 1.6.0 is 1.6.0 through 1.6.9

I should have used >= 1.6.0

I see. May I edit that in the GH repo so that I can run 05AB1E?

Oh you did it

yep, including the fix for the to int bug

Nice

Thanks @Emigna for spotting the bug

Yay I can now compile 05AB1E locally. If you guys want to check if things work locally but not on TIO, I can help from now on

Nice :)

Anyway the changes will soon be live on TIO too because Adnan just requested a sync FYI

@Adnan If you don't mind me asking, have you implemented flags other than j for λ by now?

@Mr.Xcoder No not yet, although I do have some ideas in mind

like £ and è which should not be too hard to implement

Another Question:

When running things like λ+}10£ on the command line, λ only defaults to 1 if I haven't given any input, right?

Yes, that is correct

Good thanks

Actually, the same thing happens on TIO, it's just that TIO doesn't take input dinamically

Sorry for the silly question

no worries :)

And the new deck-shuffle command basically pairs the elements of the first half with the corresponding elements in the second half, leaving the median for odd-length lists untouched at the end?

Oh, btw, feature-request: median

Dennis already pulled so maybe in the next sync

@Adnan Should .M and .m error on []?

In the legacy version, they just returned []

Asking because I want to make a PR and I'll add that too if this behaviour is not intended.

@Mr.Xcoder Alright, I'll look into that

You can do

  def median([]), do: []
  def median(list) do
    len = length(list)
    sorted = Enum.sort(list)
    mid = div(len, 2)
    if rem(len, 2) == 0, do: (Enum.at(sorted, mid - 1) + Enum.at(sorted, mid)) / 2,
    else: Enum.at(sorted, mid)
  end

For lists numbers

But should definitely overload for lists of strings for example, so it acts like g;è

Oh nice!

Yeah, but how do you distinguish a list of numbers and a list of strings representing numbers

Good question

About the .M/.m thing, returning [] is a good idea IMO

but that can be fixed (as well as for any other function) by using the call_unary/call_binary method

because it returns the first argument on error

@Adnan How about this: if not all of the strings represent integers, return the middle one for odd-length lists and the middle two for even length ones

That would be of course quite inconsistent though

Normally the best option would be creating two different commands in that case

Sure, but I don't know if it's worth it

something like Å; for example

well we have more than enough room for 2-byte commands

That's true too

And how'd you name those?

Maybe Åm for normal median

And Ås for string-list median?

sure, that sounds good

or something like middle

Wait a second

Should they be list commands (Å...)? Because I'd be nice if one of them could work for strings too (e.g. "abcde"Å??? --> "c", "abcd"Å??? --> ["b", "c"] or "bc")

Or should they be .??? functions?

Å... are no longer just list commands

they used to be though, but now they are just extended commands

I see. So I'll rename the wiki page too

Alright

One thought: Should we merge Extended Commands with Commands in the wiki and instead make it a separate section, like we did for constants, for better accessibility?

Sure, seems visually more pleasing

Will do asap

Merged the two. Should I delete the other page?

@Mr.Xcoder Sure, go ahead