Problem 6 Rounding in Python3

What exactly is your problem with this task? Data input-output or rounding? For rounding you can use built-in round() function.

Please note, that python math.round function do the "bank" rounding, not the rounding asked for in the task. You have to invent and realize your own way to do rounding in the right way in python.

Having sccessfully submitted a solution for problem, one can see how other people solved the same problem. I can see other solutions for problem 6 (rounding), and it seem that 80% of people solved it with round(). So it seems using round() is ok. No need to invent your own wheel, really.

I think checker is weak for this problem and didn't always catch troubles, e.g. with python standard rounding:

>>> round(3.5)
4
>>> round(4.5)
4

Well, perhaps I should try to improve the checker, though the main goal is to make sure people can use rounding in further tasks... And probably .5 cases arose rarely...

UPD: I think I improved the checker to increase probability of such "bad cases"... Thanks for your hint...

i think i improved the checker
The checker is definitely better now. I tried to submit solution based on round() function five times and suceeded only once.

To author of topic (Freddie) - in my very first solution of this problem I came up with following solution:.

1. Let r be result of division of a by b.
2. Let sgn be -1 if r < 0, 1 otherwise.
3. Let r be equal to absolute value of r.
4. Let n be integer part of r.
5. Let f be (r - n) converted to string representation (we can call it "fraction part").
6. Let k be third character of f, converted to int.
7. Answer is n multiplied by sgn if k less than 5, otherwise answer is (n + 1) multiplied by sgn.

I clearly understand this is not the best solution (because I know other people solutions now), but this is how people like me approach this problem first time.

Oh, and by the way (problem statement):

...when result contains exactly 0.5 as a fraction part, value should be rounded up, by adding another 0.5...

I looked more carefully at my first solution, and found out it rounds towards infinity unstead of rounding up. Does this mean that checker rounds towards infinity too (because solution was accepted), or it was just luck that checker did not found my mistake?

Reloaded the problem page many times and all the "bad cases" have a positive sign. There is still room for improvement (making checker generate bad cases with negative signs too).

More than three years are passed after my request to add halves-rounding cases with negative sign and still no such cases.

Will we see them in the future?

This is not hard to implement, I believe. Examples:

3
-3 2
1 -2
-35 14

Rodion, I wrote a short code to help with test data generation for this task:

<?php
// the code has been moved to the checker, let it not be here to spoil solutions :)

Hi Friend! And thanks for notifying about the thread!

More than three years are passed after my request

what a shame :( please sorry, it seems I completely missed the discussion perhaps after some point, I'll review it today and come back.

This task definitely could be improved so it is great that you decided to help - moreover it is generally solved by many people.

It seems using round() is ok.

By the way, this is wrong. I made this statement because I did not knew much about Python at this time, but now I know that round() function behaves differently in Python 2 and Python 3.

The behaviour of round() function in Python 2 is exactly what is required for this task, but for Python 3 one must code its own solution.

Rodion, I understand that you reviewed the discussion yesterday as promised, but when you come back with review?

Sorry for delay, I adapted the code and plugged it in, but recently found there are some discrepancies which I'm going to investigate a bit later so right now problem is reverted to the old silly version of checker but it is just temporarily.

Definitely your approach is much better so we'll have it in place soon. Very sorry I haven't yet figured out the issue during weekend. Here are two examples calculated wrong:

1617401835 -2015454
768903492 -49224

expectation is given as -803 -15621 instead of -802 and -15620, though other negative half-division cases are correct, probably there is precision issue with values above some absolute value.

As about Python - it's true, despite being considered most popular language for beginners, it has "too scientific" approach to rounding enabled by default.

Hey! For test cases:

2
1617401835 -2015454
768903492 -49224

Correct answers are:

-803 -15621

I don't see a problem here.

Without rounding, the answers are:

-802.5 -15620.5

Then we round answers towards infinity (or away from zero):

-802.5 -> -803
-15620.5 -> -15621

And finally, the answers are:

-803 -15621

<?php
    echo round(1617401835 / -2015454).PHP_EOL;
    echo round(768903492 / -49224).PHP_EOL;

.

-803
-15621

Hm-m-m... I feel confused :) it seems problem statement meant rounding "half-up". Let me investigate this closer.

From the old checker code it seems it was rounding the way you propose. Then probably statement should be corrected.

Yeah, I noticed that old problem statement describes some other algorithm.

I see you already fixed the statement, but please change this...

. for more thorough explanations.

...to following:

. For more thorough explanations, please refer Wikipedia's article on Rounding (Rounding to integer -> Rounding to the nearest integer -> Rounding half away from zero).

Thanks in advance!

There is also more direct link: Rounding half away from zero

Hi Friend, thanks for correcting this yet another silly mistake :)

The statement is updated! Please sorry for delay - got bit distracted by dull work these days :(

It seems wiki articles are not always preserve pages and anchors for good. If they change this rounding article once more, perhaps we'll recreate it in our space!

Another sad thing is that for article having some translations we can't get them all updated at once. But I'll look into it bit later...