On Fri, Aug 26, 2016 at 8:20 PM, mlz wrote:
> I believe there are languages that preserve exact accuracy in this way for
> rational fractions. I don't know if Python is one of them.
It is, but only if you explicitly request it (due to the performance
impact). Just import it:
#!/usr/bin/python2
mlz writes:
> It's true that a*(b/c) yields fractions which would probably accrue
> accuracy errors depending on how those values are implemented. For
> example, it is possible to represent 1/3 internally as two numbers,
> numerator and denominator, thus avoiding the repeating decimal (or
> binima
It's true that a*(b/c) yields fractions which would probably accrue accuracy
errors depending on how those values are implemented. For example, it is
possible to represent 1/3 internally as two numbers, numerator and denominator,
thus avoiding the repeating decimal (or binimal, or whatever it's
Partly it's the layout, but mathematically speaking the two should be equal.
(a*b)/c should equal a*(b/c)
The fact that they're not is surprising, because python 2 so seamlessly
supports big integers in a mathematically correct way.
I consider such surprising behavior to be abstraction leak, wh
Aha. That's interesting.
On Friday, August 26, 2016 at 2:11:32 AM UTC-7, Peter Otten wrote:
> mlz wrote:
>
> > Yes, I just worked that out. It's the integer math that's the problem.
> >
> > I guess this has been fixed in python 3, but unfortunately it seems that
> > most people are still using
On 26/08/2016 08:14, mlzarathus...@gmail.com wrote:
However, precedence wasn't the problem in this case, it was the type conversion.
I think it was. I was puzzled as well.
But apparently if you have:
x * = expr
That's like:
x = x * (expr)# note the parentheses
which may not al
mlzarathus...@gmail.com wrote:
> Yes, I just worked that out. It's the integer math that's the problem.
>
> I guess this has been fixed in python 3, but unfortunately it seems that
> most people are still using python 2.
Note that you can get Python 3's default behaviour in Python 2 with
from _
Am 26.08.16 um 09:53 schrieb Erik:
On 26/08/16 08:44, mlzarathus...@gmail.com wrote:
Here's the key:
$ python2
Python 2.7.10 ...
1/2
0
$ python
Python 3.5.1 ...
1/2
0.5
1//2
0
I read about this awhile ago, but it's not until it bites you that you
remember fully.
How is this rela
On 26/08/16 08:14, mlzarathus...@gmail.com wrote:
I was being facetious, but behind it is a serious point. Neither the APL nor
the J languages use precedence even though their inventor, Ken Iverson, was a
mathematician.
That was to support functional programming dating back to the 1970's.
P
On 26/08/16 08:44, mlzarathus...@gmail.com wrote:
Here's the key:
$ python2
Python 2.7.10 ...
1/2
0
$ python
Python 3.5.1 ...
1/2
0.5
1//2
0
I read about this awhile ago, but it's not until it bites you that you remember
fully.
How is this related to your question? The example e
Here's the key:
$ python2
Python 2.7.10 ...
>>> 1/2
0
>>>
$ python
Python 3.5.1 ...
>>> 1/2
0.5
>>> 1//2
0
>>>
I read about this awhile ago, but it's not until it bites you that you remember
fully.
--
https://mail.python.org/mailman/listinfo/python-list
mlzarathus...@gmail.com writes:
> Yes, I just worked that out. It's the integer math that's the problem.
>
> I guess this has been fixed in python 3 [- -]
Note that division in Python 3 produces approximate results (floating
point numbers). This may or may not be what you want in this exercise.
I
I was being facetious, but behind it is a serious point. Neither the APL nor
the J languages use precedence even though their inventor, Ken Iverson, was a
mathematician.
That was to support functional programming dating back to the 1970's.
However, precedence wasn't the problem in this case, i
Yes, I just worked that out. It's the integer math that's the problem.
I guess this has been fixed in python 3, but unfortunately it seems that most
people are still using python 2.
Thanks for all the help!
--
https://mail.python.org/mailman/listinfo/python-list
mlz wrote:
> I've been playing with the binomial function, and found that in the below
> code, rs *= x does not behave the same way as rs = rs * x. When I set FAIL
> to True, I get a different result. Both results are below.
>
> I had read that the two were equivalent. What am I missing?
>
> th
On Fri, Aug 26, 2016 at 4:40 PM, wrote:
> Precedence, d'oh!
>
> rs *= (n-(i-1))/i
> is equivalent to:
> rs = rs * ((n-(i-1))/i)
>
> not
> rs = rs * (n-(i-1))/i
>
> which is the same as
> rs = ( rs * (n-(i-1)) ) /i
>
>
> Ken Iverson was right. Precedence is a bad i
Precedence, d'oh!
rs *= (n-(i-1))/i
is equivalent to:
rs = rs * ((n-(i-1))/i)
not
rs = rs * (n-(i-1))/i
which is the same as
rs = ( rs * (n-(i-1)) ) /i
Ken Iverson was right. Precedence is a bad idea.
--
https://mail.python.org/mailman/listinfo/python
if FAIL: rs *= (n-(i-1))/i # these should be the same,
This is equal to rs = rs * ((n-(i-1))/i)
else: rs = rs * (n-(i-1))/i # but apparently are not
This is equal to rs = (rs * (n-(i-1)))/i
On Fri, Aug 26, 2016 at 3:20 PM, mlz wrote:
> I've been playing with the binomial f
mlz writes:
> I've been playing with the binomial function, and found that in the
> below code, rs *= x does not behave the same way as rs = rs * x. When
> I set FAIL to True, I get a different result. Both results are below.
>
> I had read that the two were equivalent. What am I missing?
You do
I've been playing with the binomial function, and found that in the below code,
rs *= x does not behave the same way as rs = rs * x. When I set FAIL to True, I
get a different result. Both results are below.
I had read that the two were equivalent. What am I missing?
thanks,
-= miles =-
#!
20 matches
Mail list logo
