[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
Change by AVicennA : -- components: Library (Lib) files: cProfiling.txt nosy: AvicennA priority: normal severity: normal status: open title: cProfile behaviour issue with decorator and math.factorial() lib. type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48764/cProfiling.txt ___ Python tracker <https://bugs.python.org/issue38993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
AVicennA added the comment:
Hello, I use decorators in my Python project. I tested project with
cProfile(profiling). Then,
I decide did test with some decorator code fragments. Some results were
surprising:
import functools
import cProfile
def decor(func):
@functools.wraps(func)
def wraps(*args, **kwargs):
return func(*args, **kwargs)
return wraps
@decor
def count(g_val):
if g_val < 1:
print("End")
else:
count(g_val - 1)
cProfile.run('count(102)')
OS names: Windows, Linux - x64
Python versions: 3.6.8, 3.4.3 - x64
# cProfile using into the .py file
python dec_profile.py
End
210 function calls (6 primitive calls) in 0.000 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.0000.0000.0000.000 :1()
103/10.0000.0000.0000.000 timeer.py:10(count)
103/10.0000.0000.0000.000 timeer.py:5(wraps)
10.0000.0000.0000.000 {built-in method builtins.exec}
10.0000.0000.0000.000 {built-in method builtins.print}
10.0000.0000.0000.000 {method 'disable' of
'_lsprof.Profiler' objects}
# Instead of 102 used ---> 82, 22, 33, 72 and etc. also gave me strange results
like in 102.
This behaviour can be changing sometimes, but usually give an incorrect results.
import functools
import cProfile
def decor(func):
@functools.wraps(func)
def wraps(*args, **kwargs):
return func(*args, **kwargs)
return wraps
@decor
def count(g_val):
if g_val < 1:
print("End")
else:
count(g_val - 1)
count(102)
# cProfile using via command line
python -m cProfile dec_profile.py
End
539 function calls (334 primitive calls) in 0.002 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.0000.0000.0000.000 :103(release)
10.0000.0000.0000.000 :143(__init__)
10.0000.0000.0000.000 :147(__enter__)
10.0000.0000.0000.000 :151(__exit__)
10.0000.0000.0000.000 :157(_get_module_lock)
10.0000.0000.0000.000 :176(cb)
10.0000.0000.0000.000 :211(_call_with_frames_removed)
260.0000.0000.0000.000 :222(_verbose_message)
10.0000.0000.0000.000 :307(__init__)
10.0000.0000.0000.000 :311(__enter__)
10.0000.0000.0000.000 :318(__exit__)
40.0000.0000.0000.000 :321()
10.0000.0000.0000.000 :35(_new_module)
10.0000.0000.0000.000 :369(__init__)
20.0000.0000.0000.000 :403(cached)
10.0000.0000.0000.000 :416(parent)
10.0000.0000.0000.000 :424(has_location)
10.0000.0000.0000.000 :504(_init_module_attrs)
10.0000.0000.0000.000 :564(module_from_spec)
10.0000.0000.0000.000 :58(__init__)
10.0000.0000.0000.000 :651(_load_unlocked)
10.0000.0000.0000.000 :707(find_spec)
10.0000.0000.0000.000 :78(acquire)
10.0000.0000.0000.000 :780(find_spec)
30.0000.0000.0000.000 :843(__enter__)
30.0000.0000.0000.000 :847(__exit__)
10.0000.0000.0010.001 :870(_find_spec)
10.0000.0000.0010.001 :936(_find_and_load_unlocked)
10.0000.0000.0010.001 :966(_find_and_load)
60.0000.0000.0000.000 :1080(_path_importer_cache)
10.0000.0000.0010.001 :1117(_get_spec)
10.0000.0000.0010.001 :1149(find_spec)
10.0000.0000.0000.000 :1228(_get_spec)
50.0000.0000.0010.000 :1233(find_spec)
20.0000.0000.0000.000 :263(cache_from_source)
10.0000.0000.0000.000 :361(_get_cached)
50.0000.0000.0000.000 :37(_relax_case)
10.0000.0000.0000.000 :393(_check_name_wrapper)
10.0000.0000.0000.000 :430(_validate_bytecode_header)
10.0000.0000.0000.000 :485(_compile_bytecode)
20.0000.0000.0000.000 :52(_r_long)
10.0000.0000.0000.000 :524(spec_from_file_location)
250.0000.0000.0000.000 :57(_path_join)
250.0000.0000.0000.000 :59()
20.0000.0000.0000.000 :63(_path_split)
10.0000.0000.0000.000 :669(create_module)
10.0000.0000
[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
AVicennA added the comment:
In short, here are different behaviours in increasing steps of values, which
are (based on my researching) giving incorrect results in relation to each
other.
Given example:
import functools
import cProfile
def decor(func):
@functools.wraps(func)
def wraps(*args, **kwargs):
return func(*args, **kwargs)
return wraps
@decor
def count(g_val):
if g_val < 1:
print("End")
else:
count(g_val - 1)
cProfile.run('count(VALUE)')
Below I wrote results by given values...
1) VALUE = 50
End
106 function calls (6 primitive calls) in 0.000 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.0000.0000.0000.000 :1()
51/10.0000.0000.0000.000 main.py:10(count)
51/10.0000.0000.0000.000 main.py:5(wraps)
10.0000.0000.0000.000 {built-in method exec}
10.0000.0000.0000.000 {built-in method print}
10.0000.0000.0000.000 {method 'disable' of
'_lsprof.Profiler' objects}
2) VALUE = 45
End
96 function calls (6 primitive calls) in 0.062 seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
10.0000.0000.0620.062 :1()
46/10.0000.0000.0610.061 main.py:10(count)
46/10.0000.0000.0620.062 main.py:5(wraps)
10.0000.0000.0620.062 {built-in method exec}
10.0610.0610.0610.061 {built-in method print}
10.0000.0000.0000.000 {method 'disable' of
'_lsprof.Profile
[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
AVicennA added the comment: In official documentation: https://docs.python.org/3/library/profile.html was not noted about the difference behaviour of cProfile in command line and into the file. -- ___ Python tracker <https://bugs.python.org/issue38993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
AVicennA added the comment: @rhettinger, I did not write nowhere in my post that it's a pure bug. I use "behaviour" instead of it. And it getting me incorrect results everytime, that is why I should wrote it in here for resolving this problem. This is not about getting error message, that write to Stackoverflow. I think you were not checking this never. -- ___ Python tracker <https://bugs.python.org/issue38993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39059] Getting incorrect results in rounding procedures
New submission from AVicennA :
This is about rounding process and getting incorrect results. In documentation
written
that, "This is not a bug: it’s a result of the fact that most decimal fractions
can’t be
represented exactly as a float". -
https://docs.python.org/3/library/functions.html?highlight=round#round
It is also related with hardware. I wrote some code parts that shows it and
used decimal value
as in documentation sample:
''' 2.675(4) - (4) or (3) or (2) etc. I have given range 2, and the result is
influenced not
just by one number after those 2 ranges, but also the another number
consistently. '''
>>> round(2.675, 2)
2.67
>>>
>>> round(5.765, 2)
5.76
>>>
>>> round(2.6754, 2)
2.68
>>>
>>> round(5.7652, 2)
5.77
''' "format" is also not working properly. Gives incorrect results. '''
>>> format(2.675, ".2f")
'2.67'
>>>
>>> format(2.678, ".2f")
'2.68'
>>>
>>> '{:0.2f}'.format(2.675)
'2.67'
>>>
>>> '{:0.2f}'.format(2.678)
'2.68'
''' Because, when the decimal string is converted to a binary floating-point
number, it's
again replaced with a binary approximation:
Whose exact value is 5.765 -->
5.76468025576890795491635799407958984375
&&
2.675 -->
2.67482236431605997495353221893310546875
It means that, the 76(5) --> 5 replaced in a memory as 4.()
&&
67(5) --> 5 replaced in a memory as 4.() '''
>>> from decimal import Decimal
>>> Decimal(2.675)
Decimal('2.67482236431605997495353221893310546875')
>>>
>>> Decimal(5.765)
Decimal('5.76468025576890795491635799407958984375')
''' Used float point precision(FPU) with math lib to apply a certain correct
form.
I propose to use some tricks. But again incorrect result in third sample:
'''
>>> import math
>>> math.ceil(2.675 * 100) / 100
2.68
>>>
>>> print("%.2f" % (math.ceil(2.675 * 100) / 100))
2.68
>>> math.ceil(2.673 * 100) / 100
2.68
''' The most correct form is using by round: '''
>>> round(2.675 * 100) / 100
2.68
>>>
>>> round(2.673 * 100) / 100
2.67
>>> round(2.674 * 100) / 100
2.67
>>> round(2.676 * 100) / 100
2.68
''' In this case, whatever the range the full right result is a return.
Mostly can be using in fraction side correctness. '''
>>> def my_round(val, n):
... return round(val * 10 ** n) / 10 ** n
...
>>> my_round(2.675, 2)
2.68
>>>
>>> my_round(2.676, 2)
2.68
>>>
>>> my_round(2.674, 2)
2.67
>>>
>>> my_round(2.673, 2)
2.67
>>>
>>> my_round(2.674, 3)
2.674
>>>
>>> my_round(55.37678, 3)
55.377
>>>
>>> my_round(55.37678, 2)
55.38
>>>
>>> my_round(55.37478, 2)
55.37
>>>
>>> my_round(224.562563, 2)
224.56
>>>
>>> my_round(224.562563, 3)
224.563
>>>
>>> my_round(224.562563, 4)
224.5626
>>>
>>> my_round(224.562563, 5)
224.56256
>>>
>>> my_round(224.562563, 7)
224.562563
>>>
>>> my_round(224.562563, 11)
224.562563
''' my_round - function tested on Windows and Linux platforms(x64). This can be
added in Python
next releases to solve this problem which related with the IEEE 754 and PEP
754 problems. '''
--
assignee: docs@python
components: Documentation, FreeBSD, IDLE, Interpreter Core, Library (Lib),
Tests, Windows, macOS
messages: 358467
nosy: AVicennA, docs@python, koobs, ned.deily, paul.moore, ronaldoussoren,
steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Getting incorrect results in rounding procedures
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39059>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39059] Getting incorrect results in rounding procedures
AVicennA added the comment: @steven.daprano, yes, my_round(2.675, 2) --> gave 2.68 and it's not buggy and not wrong. This is correct in this case. I advise you look at 5th class math book. -- ___ Python tracker <https://bugs.python.org/issue39059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
Change by AVicennA : Removed file: https://bugs.python.org/file48764/cProfiling.txt ___ Python tracker <https://bugs.python.org/issue38993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39059] Getting incorrect results in rounding procedures
AVicennA added the comment: @mark.dickinson, 1) Where is your "`round` is giving the correct result in all cases"?? >>> round(4.395, 2) 4.39 2) I wrote it in my post using decimal punct: ''' Because, when the decimal string is converted to a binary floating-point number, it's again replaced with a binary approximation: Whose exact value is 5.765 --> 5.76468025576890795491635799407958984375 && 2.675 --> 2.67482236431605997495353221893310546875 It means that, the 76(5) --> 5 replaced in a memory as 4.() && 67(5) --> 5 replaced in a memory as 4.() ''' 3) round(2.6748, 2) --> this is the same with round(2.675, 2). 4) I also have a question for you.. Do you have any suggestion to solve this problem? -- ___ Python tracker <https://bugs.python.org/issue39059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38993] cProfile behaviour issue with decorator and math.factorial() lib.
Change by AVicennA : -- resolution: not a bug -> later ___ Python tracker <https://bugs.python.org/issue38993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39059] Getting incorrect results in rounding procedures
AVicennA added the comment: @mark.dickinson: You asked some questions, then, I also asked you about solving this problem. It seems to me you just love to talk.. I just answered to your questions. If "this isn't the right forum for that discussion" as you mean, it concerns you too. When you ask it's right, but when I answer it's wrong place to discuss ?! I can change this line of my post - "In this case, whatever the range the full right result is a return" to " In this case, sometimes right result can be return like a round". round function also not work properly, my_round too. Each of them must be used in its place. In the end I wanna say that, if you want to discuss this further, please, we can continue conversation in mailing list or where you want. Thanks. -- ___ Python tracker <https://bugs.python.org/issue39059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
