Ørjan Johansen

@El'endiaStarman The probability that you still won't get one in the next 2000 is 1/e ~ 36%, which, when multiplied by the original ~ 30% probability of not getting one in the first 2400, gives ~ 11%, or the probability of not getting one in the total 4400. That's exactly the rule for combining independent probabilities.

CPS = continuation passing style

@EdgyNerd Every Underload command (ignoring exact S output format) translates directly to Smurf except for ^, which gets restricted to only be used at the end when there's exactly one element on the stack. So to make it work you need to (1) CPS transform the Underload program (2) reencode the Underload stack into a single string so it can be embedded in the continuation string called by x.

@EdgyNerd I think so too. I think you can also remove \ , since q and + can be used to construct the kind of strings you'd want it for.

(which btw shows that reduction can be faked in various ways, so t is probably unnecessary).

@EdgyNerd They're not TC. You have no way to do duplication. In fact the only way to grow the program state is q, but that uses up a q that you have no way of getting back. So the remaining program + stack have to shrink, eventually halting. t won't help you either. I think p and g are necessary but some of the rest might not be. You might want to look at my Underload :()^ minimization.

@DJMcMayhem Are you saying you want a pillow fight?

@PhiNotPi OK calculating speed is beyond my little knowledge of thermodynamics.

@PhiNotPi Right, swapping should be possible.

In which case your sqrt(XY) note seems like the thing.

Well you can only do that by heating the other.

@PhiNotPi You cannot use the heat differential between two objects to power heat transfer from the coldest to the hottest - that's pretty much one formulation of the second law. But you could use it as an energy source to cool a third object.

Or loops and mutable variables.

In Python it would be easier though, since functions can have optional arguments.

@Khuldraesethna'Barya Oh I see, I read "helper function" as "predefined function".

(Without optimizations.)

Actually, technically laziness ruins it. Should have used the strict foldl'.

@Khuldraesethna'Barya No, it's easy to build a reversed copy on the fly while traversing an immutable original. In fact that's exactly what the standard definition of Haskell's reverse does. (reverse = foldl (flip (:)) [])

@EsolangingFruit R (B x R) is a fixpoint for x but I don't see how to get the x as the final argument.

di and id could be any single letter instead.

@Laikoni Thanks, I decided to post it.

(41 bytes)

Reversed niam=main;main=putStr$!"-1";1!$tnirp=niam

@Laikoni main=print$!1;"1-"!$rtStup=niam;niam=main

| ... <- is basically syntactic sugar for case ... -> ..., which doesn't.

let also allows types to be polymorphic.

@SriotchilismO'Zaic The y is not in scope on the right side of the <-, but is in scope on the right side of the =. (BTW f x|let(y,z)=(x,y)=z works.)

Thanks

Since I can no longer unprotect questions, I tried to flag a couple days ago that codegolf.stackexchange.com/q/55422 needs to be, but no one has reacted :(

The logical solution is to get SE to rename to something abbreviating to PP.

Both. The 2 cannot be changed to 4 or 8, because 5 isn't divisible by 2 or 3. The 5 cannot be changed because 25 > 10.

And I suspect there won't be any large ones which do.

There are few enough candidates that you can use the logarithm method from the earlier challenge to estimate which ones might fit, though.

You also have to check if (c^d^e-1)/2 and (c^d^e-1)/3 are powers, for 9^4^ and 9^8^.

Catalan's conjecture

Oh, 1 is a theorem now...

I think it's likely that subtracting 1 or 2 from a large power never gives a power, though.

Something like 3^2^c^d^e might be harder to handle, though, since you end up having to check if c^d^e-1 is a power, and it might be large. (In which case it fits with 9^2^.)

@Anush I've thought a bit about that recently. Two towers cannot be equal unless their base numbers are powers of a common one. For that particular example that implies that the 2^5^ part is fixed, and that 2^5^3^2^4, 2^5^9^2^3 and 2^5^9^8^1 are the possible options.

Well it might be tricky to check if implementations actually solve the problem...

And then you know the former ends up larger, no matter what the rest of the bases are.

That does work with my observation, though. 4^5 = 1024 > 7*(3^2) + 3.

Yeah although not too bad with two steps

It's (3^4^5)*log 2 and (4^3^2)*log 5.

No.

Perhaps it's possible to check all a^b^c cases and verify none of them are closer than 7 times each other unless they're equal. If so that should give an algorithm.

And I don't know whether that can happen or not, and there's no obvious reason why it cannot.

It's not about being large. You can make it small. The problem is that it won't help if you end up having to compare two numbers that are so close you need more precision than you have memory.

I've warned those who had TIO links if they failed for the new test case.

Suggested test case: 2^3^12 == 8^3^11. Evil grin. This is smaller than I'd like, but I couldn't find a bigger one where floating point error matters.