fixed

Rejected.

Too easily cheatable, and use of Random instead of QuickCheck.

Cheatable with

factorial n = show $ product [1..n'] where
  (a,b) = decodeFloat $ fromIntegral n
  n' = a `div` 2 ^ negate b

I don't know exactly how you'd prevent that; that's your job.

Use spoiler flag next time please. Your post was visible in the homepage.

New to Haskell, how does this work?

>> 1.0 / 0.0
inf
>> 0.0 / 0.0
NaN

according to evcxr, which is a rust REPL

What happens here if total is 0?

If you could fix assertion messages, this would be approvable.
I'm also seeing changes to the description in the diff, though I'm seeing the same or varying changes throughout this chain of forks, so I'm not sure which of those you actually applied or not. Maybe give those another once over to ensure only necessary changes are made.

The translation it's forked from didn't pass its tests

Also, this would have been a good opportunity to improve the (missing) assertion messages.

EDIT: Disregard my comment about the current solution being correct; cargo test uses debug mode, in which case the overflow becomes a runtime error.

EDIT 2: Disregard my third point. I hadn't realised this is a new translation, I thought it was an update to an existing translation. There is no current solution...

I don't quite see the point of your fork. From what I can tell, all you did is update the reference solution with one that you would consider "more correct". However

• MIN is never tested
• The current solution is correct (due to overflow, the result of negating abs of MIN is MIN)
• This will have no effect other than adding your new solution to the solutions page under your name. You achieve the indentical outcome by simply solving yourself the regular way

If you can give me a good reason for this fork to exist, I will consider it, otherwise I will simply reject this.

Haskell Translation

Approved.

An annoying but possible solution might be to make a custom int subclass that checks for oversized ints, pass in a RestrictedInt(10) along with n, and disallow integer literals

You'd also have to ban the use of int, __class__, type, and Decimal.

But that would make it harder than other languages...

Edit: oops; it would still be possible to break the integer restriction using any default method that returns an int

Too much work to replace all the builtins and ban all the importables that would return int...