Alexandru Moșoi wrote:
From: "Cesare Di Mauro"
So if Python will generate
LOAD_CONST 1
LOAD_CONST 2
BINARY_ADD
the constant folding code will simply replace them with a single
LOAD_CONST 3
When working with such kind of optimizations, the temptation is to
apply them at any sit
Cesare Di Mauro wrote:
On Tue, Apr 7, 2009 07:22PM, Guido van Rossum wrote:
In my experience it's better to discover a bug at compile time rather
than
at running time.
That's my point though, which you seem to be ignoring: if the user
explicitly writes "1/0" it is not likely to be a bug. That's
On 7 Apr 2009, at 11:59, Alexandru Moșoi wrote:
Not necessarily. For example C/C++ doesn't define the order of the
operations inside an expression (and AFAIK neither Python) and
therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
object with mul operator overloaded. Moreover one
On Tue, Apr 7, 2009 at 8:59 PM, Alexandru Moșoi wrote:
> Not necessarily. For example C/C++ doesn't define the order of the
> operations inside an expression (and AFAIK neither Python) and
> therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
> object with mul operator overloade
> From: "Cesare Di Mauro"
> So if Python will generate
>
> LOAD_CONST 1
> LOAD_CONST 2
> BINARY_ADD
>
> the constant folding code will simply replace them with a single
>
> LOAD_CONST 3
>
> When working with such kind of optimizations, the temptation is to
> apply them at any situat
On Tue, Apr 7, 2009 07:22PM, Guido van Rossum wrote:
>> In my experience it's better to discover a bug at compile time rather
>> than
>> at running time.
>
> That's my point though, which you seem to be ignoring: if the user
> explicitly writes "1/0" it is not likely to be a bug. That's very
> diff
On Tue, Apr 7, 2009 at 9:46 AM, Cesare Di Mauro
wrote:
> On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote:
>> Well I'm sorry Cesare but this is unacceptable. As Skip points out
>> there is plenty of code that relies on this.
>
> Guido, as I already said, in the final code the normal Python beha
On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote:
> Well I'm sorry Cesare but this is unacceptable. As Skip points out
> there is plenty of code that relies on this.
Guido, as I already said, in the final code the normal Python behaviour
will be kept, and the stricter one will be enabled solely
Well I'm sorry Cesare but this is unacceptable. As Skip points out
there is plenty of code that relies on this. Also, consider what
"problem" you are trying to solve here. What is the benefit to the
user of moving this error to compile time? I cannot see any.
--Guido
On Tue, Apr 7, 2009 at 8:19 A
In data 07 aprile 2009 alle ore 17:19:25, ha scritto:
>
> Cesare> The only difference at this time is regards invalid operations,
> Cesare> which will raise exceptions at compile time, not at running
> Cesare> time.
>
> Cesare> So if you write:
>
> Cesare> a = 1 / 0
>
> Ce
Cesare> The only difference at this time is regards invalid operations,
Cesare> which will raise exceptions at compile time, not at running
Cesare> time.
Cesare> So if you write:
Cesare> a = 1 / 0
Cesare> an exception will be raised at compile time.
I think I have to ca
2009/4/7 Cesare Di Mauro :
> The principle that I followed on doing constant folding was: "do what Python
> will do without constant folding enabled".
>
> So if Python will generate
>
> LOAD_CONST 1
> LOAD_CONST 2
> BINARY_ADD
>
> the constant folding code will simply replace them with a
On 07/04/2009, at 7:27 AM, Guido van Rossum wrote:
On Mon, Apr 6, 2009 at 7:28 AM, Cesare Di Mauro
wrote:
The Language Reference says nothing about the effects of code
optimizations.
I think it's a very good thing, because we can do some work here
with constant
folding.
Unfortunately the
On Apr 07, 2009 at 02:10AM, Steven D'Aprano wrote:
> On the other hand, I'm with Guido when he wrote "it is certainly not
> right to choose speed over correctness". This is especially a problem
> for floating point optimizations, and I urge Cesare to be conservative
> in any f.p. optimizations he
On Mon, Apr 6, 2009 at 5:10 PM, Steven D'Aprano wrote:
> On Tue, 7 Apr 2009 07:27:29 am Guido van Rossum wrote:
>
>> Unfortunately the language reference is not the only thing we have to
>> worry about. Unlike languages like C++, where compiler writers have
>> the moral right to modify the compile
On Mon, Apr 6, 2009 at 2:22 PM, Mark Dickinson wrote:
> Well, I'd say that the obvious solution here is to compute
> the constant 2.0**53 just once, somewhere outside the
> inner loop. In any case, that value would probably be better
> written as 2.0**DBL_MANT_DIG (or something similar).
>
> As A
On Mon, Apr 6, 2009 at 1:22 PM, Mark Dickinson wrote:
> On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger wrote:
>> The code for the lsum() recipe is more readable with a line like:
>>
>> exp = long(mant * 2.0 ** 53)
>>
>> than with
>>
>> exp = long(mant * 9007199254740992.0)
>>
>> It would be
On Mon, Apr 6, 2009 at 7:28 AM, Cesare Di Mauro
wrote:
> The Language Reference says nothing about the effects of code optimizations.
> I think it's a very good thing, because we can do some work here with constant
> folding.
Unfortunately the language reference is not the only thing we have to
w
On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger wrote:
> The code for the lsum() recipe is more readable with a line like:
>
> exp = long(mant * 2.0 ** 53)
>
> than with
>
> exp = long(mant * 9007199254740992.0)
>
> It would be ashamed if code written like the former suddenly
> started doing t
+1 for removing constant folding for floats (besides conversion
of -). There are just too many things to worry about:
FPU rounding mode and precision, floating-point signals and flags,
effect of compiler flags, and the potential benefit seems small.
If you're talking about the existing peepho
[Antoine]
> - Issue #5593: code like 1e16+2. is optimized away and its result stored
> as
> a constant (again), but the result can vary slightly depending on the internal
> FPU precision.
[Guido]
> I would just not bother constant folding involving FP, or only if the
> values involved have an
On Mon, Apr 6, 2009 18:57, s...@pobox.com wrote:
>
> Cesare> At this time with Python 2.6.1 we have these results:
> Cesare> def f(): return 1 + 2 * 3 + 4j
> ...
> Cesare> def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
>
> Guido can certainly correct me if I'm wrong, but I believe
On Lun, Apr 6, 2009 16:43, Antoine Pitrou wrote:
> Cesare Di Mauro a-tono.com> writes:
>> def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
> [...]
>>
>> With proper constant folding code, both functions can be reduced
>> to a single LOAD_CONST and a RETURN_VALUE (or, definitely, by
>> a single inst
Cesare> At this time with Python 2.6.1 we have these results:
Cesare> def f(): return 1 + 2 * 3 + 4j
...
Cesare> def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
Guido can certainly correct me if I'm wrong, but I believe the main point of
his message was that you aren't going to en
Cesare Di Mauro a-tono.com> writes:
> def f(): return ['a', ('b', 'c')] * (1 + 2 * 3)
[...]
>
> With proper constant folding code, both functions can be reduced
> to a single LOAD_CONST and a RETURN_VALUE (or, definitely, by
> a single instruction at all with an advanced peephole optimizer).
Lis
On Mar 29, 2009 at 05:36PM, Guido van Rossum wrote:
>> - Issue #5593: code like 1e16+2. is optimized away and its result stored
>> as
>> a constant (again), but the result can vary slightly depending on the
>> internal
>> FPU precision.
>
> I would just not bother constant folding involving
On Sun, Mar 29, 2009 at 9:42 AM, Antoine Pitrou wrote:
> There are a couple of ancillary portability concerns due to optimizations
> which
> store system-dependent results of operations between constants in pyc files:
>
> - Issue #5057: code like '\U00012345'[0] is optimized away and its result
Hello,
There are a couple of ancillary portability concerns due to optimizations which
store system-dependent results of operations between constants in pyc files:
- Issue #5057: code like '\U00012345'[0] is optimized away and its result stored
as a constant in the pyc file, but the result should
28 matches
Mail list logo
