Hi list,
when dividing two integers, the result is a float, which means we immediately
lose precision. This is not good if you want to use code which supports higher
precision. Decimals come to mind, but also sympy. This loss of precision could
be avoided if the result of a division is a fracti
Hi Joao,
I actually had the same fear as you. But as stated before, I managed to run
most of the tests, and even compile and test numpy, with only some 30 tests
failing. This means the entire tool chain, setuptools, pytest, cython and much
more just worked. No, I did not need to touch one of th
Hi Jonathan,
I would agree with you if what I was asking was arbitrary precision math. But
this is not what I am asking for, what I am asking for is that integer true
division should result in a Fraction. The difference is huge: arbitrary
precision math is costly, and while arbitrarily precise,
Hi Paul,
I would be fine with a new division operator or fraction literal as well, and
in the beginning this is what I actually wanted to propose.
But then I started prototyping, and given that it is not so easy to change the
parser, I just changed the normal division operator. And interestingl
Hi David,
> A toy example with a half dozen operations won't make huge fractions. A
> loop over a million operations will often be a gigantic memory hog.
I do not propose to do that, and I agree that it would be stupid. Usually, the
fraction gets very quickly converted into a float, and your mil
Hi Paul,
> Agreed, it is appealing. The problem (and this is not a new
> suggestion, it's come up a number of times) is that of having language
> syntax depend on non-builtin classes. So either you have to *also*
> propose making the fractions module a builtin
That is absolutely what I would like
Hi Chris,
I would be willing to write such a PEP. It will take a while though, I am not
fast at those kinda things.
> Currently, fractions.py imports decimal.py, mainly (purely?) for the
> sake of being able to construct a Fraction from a Decimal. The decimal
> module is *large* and has other re
Hi Richard,
> I would say that I have enough code that does division of numbers that
> might be integers that expect it to be relatively efficient as floats,
> and I suspect so do others, that the backwards breaks would be
> significant.
Could I please see an example? This is a real question, by
Hi Chris,
I think you did not get my point. I do not want to allow x/y. I want to only
allow literals, as in 3/2. This would then be a new kind of literal, that has
the type of Fraction. Much like 2.5 is a float, but x.y means something
completely different, even though it has no spaces. So x/y
Hi Chris,
> Not seeing anything there about decoupling the two modules?
Well, the PR removes the line "from decimal import Decimal", I think that is
quite some decoupling. The other place decimal is imported is in a classmethod
only existing for backwards compatibility, so with this patch the d
Hi Paul,
> Also consider the section in the PEP format "How would we teach this?"
> How would you explain to someone with no programming background, maybe
> a high school student, that 3/4 and 3 / 4 mean different things in
> Python? Your audience might not even know that there is a difference
> b
Hi Chris, Hi List,
having slept over it, I think I have to take back my offer to write a PEP. Why?
Well, I am actually sure that it will get rejected anyways.
What I would like to have is that you can write 1/2 * m * v**2, and that can be
treated symbolically. Writing 1/2F instead looks ugly to
Hi List,
some days ago I posted about my idea let integer division result in fractions,
not floats. The upshot of the discussion was that it is a pity that we do not
have literals for fractions, but that there is nothing to do about it, as all
proposed syntaxes were a bit ugly.
But why do we n
Hi Steven,
> Python is never going to look good for symbolic maths, because symbolic
> maths is a two-dimensional layout and Python (like most programming
> languages) is line-oriented in a way that does not lend itself to
> complex mathematical notation.
While this is certainly true, I think
Hi Paul,
> > I'd actually prefer to write (m*v**2)/2. Or (m/2)*v**2. But those
> wouldn't work, the way you describe your proposal. And I'd be very
> concerned if they behaved differently than 1/2 * m * v**2...
Sure they do work, and they work exactly the same way. That is acually the
point: cur
Hi Paul,
> But *not* in sympy, in normal Python, if m == 1 and v == 1, then 1/2 *
> m * v**2 is 0.5 (a float) currently, as is (m/2) * v**2. But in your
> proposal, the former will be a float/fraction hybrid, whereas the
> latter will be a float.
No. In my proposal, this will simply be a float. W
Hi Oscar,
> The problem is that while SymPy expressions can define __div__(self,
> int) to be exact there isn't a way for SymPy to hook into an
> expression like 1/2 which is just a Python expression using the int
> type whose __div__ returns floats.
The entire point of my proposal is to give Sy
Hi Shreyan,
we need this for symbolic math, e.g. in sympy. Probably you have never seen
somebody doing symbolic math with Python, but believe me, there are many.
Let me walk you through a toy problem to show where the issues are. Let's say
we want to solve the equation x**2 == 3. Not a very tou
Hi list,
as you might have noticed, I am trying to improve the syntax and semantics for
symbolic math in Python. Until now, I have to say, my ideas were not that well
received, but I learned from the discussion and maybe this time I come up with
something people like.
To frame the problem, let
Hi list,
I am currently developing a Python library based on asyncio.
Unfortunately, not all users of my library have much experience with
asynchronous programming, so they often try to use blocking functions.
I thought it would be a good idea if we could somehow flag blocking
functions in the st
Hi,
> Honestly before writing a lot of code here I'd like to hear more from
> Martin about the spread of mistakes he's observed among his users.
Over the weekend, I tried to classify the mistakes I found. Most of
the times, it's something like "I'm just doing a quick lookup on the
database, that
Hi list,
> But when it comes to something like
> [f(x) + g(f(x)) for x in range(10)]
> you find you have to sacrifice some readableness if you don't want two
f(x)
> which might slow down your code.
>
> Someone may argue that one can write
> [y + g(y) for y in [f(x) for x in range(10)]]
personally
22 matches
Mail list logo
