Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Chris Smith
I am aware of how the numbers are stored but was overly optimistic that the 
shift could resolve this in all cases. It can't (and thanks for the 
correction). 
But my suggested alternative makes a significant difference in how often 
the problem arises:

>>> bad=[]
>>> for i in range(1,1000):
...  n = str(i)+'5'
...  if int(str(round(int(n)/10**len(n),len(n)-1))[-1])%2!=0:bad.append(i)  # 
e.g. round(0.1235, 3)
...
>>> len(bad)
546


>>> bad=[]
>>> for i in range(1,1000):
...  n = str(i)+'5'
...  if round(int(n)/10**len(n)*10**(len(n)-1))%2!=0:bad.append(i)  # e.g. 
round(0.1235*1000)
...
>>> len(bad)
8
>>> bad  # e.g. 0.545*100 != 54.5
[54, 57, 501, 503, 505, 507, 509, 511]

So the question is whether we want to do better and keep the SymPy 
> algorithm.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/b50c0504-ec96-4583-84b1-d5a3902277c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Chris Smith
I am aware of how the numbers are stored and was overly optimistic that the 
shift could resolve this in all cases. It can't. But my suggested 
alternative makes a significant difference it how often the problem arises:

>>> bad=[]
>>> for i in range(1,1000):
...  n = str(i)+'5'
...  if int(str(round(int(n)/10**len(n),len(n)-1))[-1])%2!=0:bad.append(i)  # 
e.g. round(0.1235, 3)
...
>>> len(bad)
546


>>> bad=[]
>>> for i in range(1,1000):
...  n = str(i)+'5'
...  if round(int(n)/10**len(n)*10**(len(n)-1))%2!=0:bad.append(i)  # e.g. 
round(0.1235*1000)
...
>>> len(bad)
8
>>> bad  # e.g. 0.545*.1000 != 54.5
[54, 57, 501, 503, 505, 507, 509, 511]


So the question is whether we want to do better and keep the SymPy 
algorithm.

On Wednesday, April 10, 2019 at 8:29:46 PM UTC-5, Oscar wrote:
>
> The fact that the numbers are stored in binary is significant: 
>
> In [16]: nums = [eval('1.%d5' % n) for n in range(10)] 
>
> In [17]: nums 
> Out[17]: [1.05, 1.15, 1.25, 1.35, 1.45, 1.55, 1.65, 1.75, 1.85, 1.95] 
>
> In [18]: [round(n, 1) for n in nums] 
> Out[18]: [1.1, 1.1, 1.2, 1.4, 1.4, 1.6, 1.6, 1.8, 1.9, 1.9] 
>
> Proper decimal rounding might look like: 
>
> In [20]: from decimal import Decimal 
>
> In [21]: nums = [Decimal('1.%d5' % n) for n in range(10)] 
>
> In [22]: nums 
> Out[22]: 
> [Decimal('1.05'), 
>  Decimal('1.15'), 
>  Decimal('1.25'), 
>  Decimal('1.35'), 
>  Decimal('1.45'), 
>  Decimal('1.55'), 
>  Decimal('1.65'), 
>  Decimal('1.75'), 
>  Decimal('1.85'), 
>  Decimal('1.95') 
>
> In [23]: [round(n, 1) for n in nums] 
> Out[23]: 
> [Decimal('1.1'), 
>  Decimal('1.2'), 
>  Decimal('1.3'), 
>  Decimal('1.4'), 
>  Decimal('1.5'), 
>  Decimal('1.6'), 
>  Decimal('1.7'), 
>  Decimal('1.8'), 
>  Decimal('1.9'), 
>  Decimal('2.0')] 
>
> Or with half-even rounding: 
>
> In [24]: from decimal import getcontext 
>
> In [25]: getcontext().rounding = 'ROUND_HALF_EVEN' 
>
> In [26]: [round(n, 1) for n in nums] 
> Out[26]: 
> [Decimal('1.0'), 
>  Decimal('1.2'), 
>  Decimal('1.2'), 
>  Decimal('1.4'), 
>  Decimal('1.4'), 
>  Decimal('1.6'), 
>  Decimal('1.6'), 
>  Decimal('1.8'), 
>  Decimal('1.8'), 
>  Decimal('2.0')] 
>
> The binary floats don't work out correct because some are above and 
> some are below the number suggested by the original float literal. 
>
> On Thu, 11 Apr 2019 at 02:03, Chris Smith > 
> wrote: 
> > 
> > That floats are stored in binary is an implementation detail which need 
> not prevent base-10 rounding to still work. The 2nd argument to round is 
> intended to tell at which base-10 digit the rounding is to take place. By 
> shifting that digit to the ones position and then doing the rounding one 
> can easily detect whether what follows is above or below a half. 
> > 
> > >>> .345.as_integer_ratio() 
> > (1553741871442821, 4503599627370496) 
> > >>> (_*100).as_integer_ratio() 
> > (69, 2) 
> > 
> > "round to even" means "if what follows the digit to which you are 
> rounding is 5 then round so your digit is even". As is shown in the integer 
> ratios above, what follows the 4 is exactly 1/2 so we can round to the even 
> 4 (as in .34) instead of the odd 5 (as in .35) just like round(0.75,1) 
> rounds to 0.8 while round(0.25) rounds to 0.2. 
> > 
> > On Wednesday, April 10, 2019 at 7:29:18 PM UTC-5, Aaron Meurer wrote: 
> >> 
> >> Doesn't Python do rounding based on the binary representation of the 
> float? 
> >> 
> >> I'm a little confused what "round to even" means in that case. 
> >> 
> >> Aaron Meurer 
> >> 
> >> On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  wrote: 
> >> > 
> >> > Python 3 implements "round to even on tie" logic so `round(12.5)` -> 
> 12,  not 13. I have updated, in #16608, the round function but there is a 
> difference in how ties are detected. I shift the desired position to the 
> ones position and then check for a tie so 12.345 is shifted to 1234.5 and 
> rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
> this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
> rounds up to 12.35 
> >> > 
> >> > 
> >> > >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 
> 345/1000 
> >> > -3/112589990684262400 
> >> > >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 
> 395/1000 
> >> > 1/56294995342131200 
> >> > 
> >> > 
> >> > >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected 
> >> > 12.35 
> >> > 
> >> > 
> >> > 
> >> > Does anyone have objections to the proposed rounding? 
> >> > 
> >> > /c 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> Groups "sympy" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to sy...@googlegroups.com. 
> >> > To post to this group, send email to sy...@googlegroups.com. 
> >> > Visit this group at https://groups.google.com/group/sympy. 
> >> > To view this discussion on the web visit 
> 

Re: [sympy] Implement solvers for symengine

2019-04-10 Thread brijesh vora
PR-
#16617-https://github.com/sympy/sympy/pull/16617

#16580-https://github.com/sympy/sympy/pull/16580

Can someone please review it.

In the coming days I will send more PR as I couldn't send before the proposal 
time. 

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/2ef8dd44-8d48-4c32-b97f-e3dc78292414%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Oscar Benjamin
The fact that the numbers are stored in binary is significant:

In [16]: nums = [eval('1.%d5' % n) for n in range(10)]

In [17]: nums
Out[17]: [1.05, 1.15, 1.25, 1.35, 1.45, 1.55, 1.65, 1.75, 1.85, 1.95]

In [18]: [round(n, 1) for n in nums]
Out[18]: [1.1, 1.1, 1.2, 1.4, 1.4, 1.6, 1.6, 1.8, 1.9, 1.9]

Proper decimal rounding might look like:

In [20]: from decimal import Decimal

In [21]: nums = [Decimal('1.%d5' % n) for n in range(10)]

In [22]: nums
Out[22]:
[Decimal('1.05'),
 Decimal('1.15'),
 Decimal('1.25'),
 Decimal('1.35'),
 Decimal('1.45'),
 Decimal('1.55'),
 Decimal('1.65'),
 Decimal('1.75'),
 Decimal('1.85'),
 Decimal('1.95')

In [23]: [round(n, 1) for n in nums]
Out[23]:
[Decimal('1.1'),
 Decimal('1.2'),
 Decimal('1.3'),
 Decimal('1.4'),
 Decimal('1.5'),
 Decimal('1.6'),
 Decimal('1.7'),
 Decimal('1.8'),
 Decimal('1.9'),
 Decimal('2.0')]

Or with half-even rounding:

In [24]: from decimal import getcontext

In [25]: getcontext().rounding = 'ROUND_HALF_EVEN'

In [26]: [round(n, 1) for n in nums]
Out[26]:
[Decimal('1.0'),
 Decimal('1.2'),
 Decimal('1.2'),
 Decimal('1.4'),
 Decimal('1.4'),
 Decimal('1.6'),
 Decimal('1.6'),
 Decimal('1.8'),
 Decimal('1.8'),
 Decimal('2.0')]

The binary floats don't work out correct because some are above and
some are below the number suggested by the original float literal.

On Thu, 11 Apr 2019 at 02:03, Chris Smith  wrote:
>
> That floats are stored in binary is an implementation detail which need not 
> prevent base-10 rounding to still work. The 2nd argument to round is intended 
> to tell at which base-10 digit the rounding is to take place. By shifting 
> that digit to the ones position and then doing the rounding one can easily 
> detect whether what follows is above or below a half.
>
> >>> .345.as_integer_ratio()
> (1553741871442821, 4503599627370496)
> >>> (_*100).as_integer_ratio()
> (69, 2)
>
> "round to even" means "if what follows the digit to which you are rounding is 
> 5 then round so your digit is even". As is shown in the integer ratios above, 
> what follows the 4 is exactly 1/2 so we can round to the even 4 (as in .34) 
> instead of the odd 5 (as in .35) just like round(0.75,1) rounds to 0.8 while 
> round(0.25) rounds to 0.2.
>
> On Wednesday, April 10, 2019 at 7:29:18 PM UTC-5, Aaron Meurer wrote:
>>
>> Doesn't Python do rounding based on the binary representation of the float?
>>
>> I'm a little confused what "round to even" means in that case.
>>
>> Aaron Meurer
>>
>> On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  wrote:
>> >
>> > Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12,  
>> > not 13. I have updated, in #16608, the round function but there is a 
>> > difference in how ties are detected. I shift the desired position to the 
>> > ones position and then check for a tie so 12.345 is shifted to 1234.5 and 
>> > rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
>> > this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
>> > rounds up to 12.35
>> >
>> >
>> > >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 
>> > >>> 345/1000
>> > -3/112589990684262400
>> > >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 
>> > >>> 395/1000
>> > 1/56294995342131200
>> >
>> >
>> > >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected
>> > 12.35
>> >
>> >
>> >
>> > Does anyone have objections to the proposed rounding?
>> >
>> > /c
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "sympy" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to sy...@googlegroups.com.
>> > To post to this group, send email to sy...@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/sympy.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/sympy/a84085c6-aa90-437c-b063-a87f909beac4%40googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/7873bfe6-6f91-4d39-af6f-9f4039714fa8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 

Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Chris Smith
That floats are stored in binary is an implementation detail which need not 
prevent base-10 rounding to still work. The 2nd argument to round is 
intended to tell at which base-10 digit the rounding is to take place. By 
shifting that digit to the ones position and then doing the rounding one 
can easily detect whether what follows is above or below a half.

>>> .345.as_integer_ratio()
(1553741871442821, 4503599627370496)
>>> (_*100).as_integer_ratio()
(69, 2)

"round to even" means "if what follows the digit to which you are rounding 
is 5 then round so your digit is even". As is shown in the integer ratios 
above, what follows the 4 is exactly 1/2 so we can round to the even 4 (as 
in .34) instead of the odd 5 (as in .35) just like round(0.75,1) rounds to 
0.8 while round(0.25) rounds to 0.2.

On Wednesday, April 10, 2019 at 7:29:18 PM UTC-5, Aaron Meurer wrote:
>
> Doesn't Python do rounding based on the binary representation of the 
> float? 
>
> I'm a little confused what "round to even" means in that case. 
>
> Aaron Meurer 
>
> On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  > wrote: 
> > 
> > Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12, 
>  not 13. I have updated, in #16608, the round function but there is a 
> difference in how ties are detected. I shift the desired position to the 
> ones position and then check for a tie so 12.345 is shifted to 1234.5 and 
> rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
> this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
> rounds up to 12.35 
> > 
> > 
> > >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 
> 345/1000 
> > -3/112589990684262400 
> > >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 
> 395/1000 
> > 1/56294995342131200 
> > 
> > 
> > >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected 
> > 12.35 
> > 
> > 
> > 
> > Does anyone have objections to the proposed rounding? 
> > 
> > /c 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "sympy" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sy...@googlegroups.com . 
> > To post to this group, send email to sy...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/sympy. 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/a84085c6-aa90-437c-b063-a87f909beac4%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/7873bfe6-6f91-4d39-af6f-9f4039714fa8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Aaron Meurer
The round() function used in that function comes from the C math
standard library. Here is an implementation that is used if it isn't
available. 
https://github.com/python/cpython/blob/a10d426bab66a4e1f20d5e1b9aee3dbb435cf309/Python/pymath.c#L72

Aaron Meurer

On Wed, Apr 10, 2019 at 6:39 PM Aaron Meurer  wrote:
>
> Here is the Python implementation
> https://github.com/python/cpython/blob/a10d426bab66a4e1f20d5e1b9aee3dbb435cf309/Objects/floatobject.c#L917
>
> It's possible you have found a bug in Python's round. I'm unclear how
> it is supposed to work.
>
> Aaron Meurer
>
> On Wed, Apr 10, 2019 at 6:28 PM Aaron Meurer  wrote:
> >
> > Doesn't Python do rounding based on the binary representation of the float?
> >
> > I'm a little confused what "round to even" means in that case.
> >
> > Aaron Meurer
> >
> > On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  wrote:
> > >
> > > Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12,  
> > > not 13. I have updated, in #16608, the round function but there is a 
> > > difference in how ties are detected. I shift the desired position to the 
> > > ones position and then check for a tie so 12.345 is shifted to 1234.5 and 
> > > rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
> > > this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
> > > rounds up to 12.35
> > >
> > >
> > > >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 
> > > >>> 345/1000
> > > -3/112589990684262400
> > > >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 
> > > >>> 395/1000
> > > 1/56294995342131200
> > >
> > >
> > > >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected
> > > 12.35
> > >
> > >
> > >
> > > Does anyone have objections to the proposed rounding?
> > >
> > > /c
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "sympy" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to sympy+unsubscr...@googlegroups.com.
> > > To post to this group, send email to sympy@googlegroups.com.
> > > Visit this group at https://groups.google.com/group/sympy.
> > > To view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/sympy/a84085c6-aa90-437c-b063-a87f909beac4%40googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2Bxag-303rzjyy4AF7yszngvyVM5W%3DFKtM4BZUzZBUf-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Aaron Meurer
Here is the Python implementation
https://github.com/python/cpython/blob/a10d426bab66a4e1f20d5e1b9aee3dbb435cf309/Objects/floatobject.c#L917

It's possible you have found a bug in Python's round. I'm unclear how
it is supposed to work.

Aaron Meurer

On Wed, Apr 10, 2019 at 6:28 PM Aaron Meurer  wrote:
>
> Doesn't Python do rounding based on the binary representation of the float?
>
> I'm a little confused what "round to even" means in that case.
>
> Aaron Meurer
>
> On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  wrote:
> >
> > Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12,  
> > not 13. I have updated, in #16608, the round function but there is a 
> > difference in how ties are detected. I shift the desired position to the 
> > ones position and then check for a tie so 12.345 is shifted to 1234.5 and 
> > rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
> > this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
> > rounds up to 12.35
> >
> >
> > >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 345/1000
> > -3/112589990684262400
> > >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 395/1000
> > 1/56294995342131200
> >
> >
> > >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected
> > 12.35
> >
> >
> >
> > Does anyone have objections to the proposed rounding?
> >
> > /c
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "sympy" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to sympy+unsubscr...@googlegroups.com.
> > To post to this group, send email to sympy@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sympy.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/sympy/a84085c6-aa90-437c-b063-a87f909beac4%40googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6K0%2BoG8zR3b8ZAT5S4eLrr6%3DjeJBoz0o_koLmub0t2Hqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Aaron Meurer
Doesn't Python do rounding based on the binary representation of the float?

I'm a little confused what "round to even" means in that case.

Aaron Meurer

On Wed, Apr 10, 2019 at 6:16 PM Chris Smith  wrote:
>
> Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12,  not 
> 13. I have updated, in #16608, the round function but there is a difference 
> in how ties are detected. I shift the desired position to the ones position 
> and then check for a tie so 12.345 is shifted to 1234.5 and rounded to 1234 
> then is divided by 100 to give 12.34. Python doesn't do this. I suspect it 
> adds 0.05 and then detects that12.395 > 12395/1000 and rounds up to 12.35
>
>
> >>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 345/1000
> -3/112589990684262400
> >>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 395/1000
> 1/56294995342131200
>
>
> >>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected
> 12.35
>
>
>
> Does anyone have objections to the proposed rounding?
>
> /c
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/a84085c6-aa90-437c-b063-a87f909beac4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6K2Y%3D6ZonewE2_EeX5rjpBP3L4TVBMw8cr_iF27T6PArA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[sympy] rounding difference between Python 3 and SymPy

2019-04-10 Thread Chris Smith
Python 3 implements "round to even on tie" logic so `round(12.5)` -> 12,  
not 13. I have updated, in #16608 
, the round function but there 
is a difference in how ties are detected. I shift the desired position to 
the ones position and then check for a tie so 12.345 is shifted to 1234.5 
and rounded to 1234 then is divided by 100 to give 12.34. Python doesn't do 
this. I suspect it adds 0.05 and then detects that12.395 > 12395/1000 and 
rounds up to 12.35


>>> Rational(*.345.as_integer_ratio())-Rational(345,1000)  # .345 < 345/1000
-3/112589990684262400
>>> Rational(*.395.as_integer_ratio())-Rational(395,1000)  # .395 > 395/1000
1/56294995342131200


>>> round(12.345,2)  # 12.345 rounds up b/c a tie is not detected
12.35



Does anyone have objections to the proposed rounding?

/c

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/a84085c6-aa90-437c-b063-a87f909beac4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.