Do we have vlookup function which can be used in dataframe same as used in
excel.
Can you please provide the pointer for the same?
Thanks!!!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
[Tim]
>> from trig functions doing argument reduction as if pi were represented
>> with infinite precision,
[Greg Ewing ]
> That sounds like an interesting trick! Can you provide
> pointers to any literature describing how it's done?
>
> Not doubting it's possible, just curious.
As I recall, when
Tim Peters wrote:
from trig functions doing argument reduction as if pi were represented
with infinite precision,
That sounds like an interesting trick! Can you provide
pointers to any literature describing how it's done?
Not doubting it's possible, just curious.
--
Greg
_
OK, we'll keep float.is_integer(), and that's a pronouncement, so that we
can hopefully end this thread soon.
It should also be added to int. After all that's what started this thread,
with the observation that mypy and PEP 484 consider an int valid whenever a
float is expected.
Since PEP 484 and
On Wed, Mar 21, 2018 at 6:48 PM, Chris Barker wrote:
> On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum
> wrote:
>
>> Thank you! As you may or may not have noticed in a different thread,
>> we're going through a small existential crisis regarding the usefulness of
>> is_integer() -- Serhiy beli
[Chris Barker ]
> ...
> ... "is it the "right" thing to do in most cases, when deployed by folks
> that haven't thought deeply about floating point.
Gimme a break ;-) Even people who _believe_ they've thought about
floating point still litter the bug tracker with
>>> .1 + .2
0.30004
Ok. I'm wrong on that example.
On Wed, Mar 21, 2018, 9:11 PM Tim Peters wrote:
> [David Mertz ]
> >> For example, this can be true (even without reaching inf):
> >>
> >> >>> x.is_integer()
> >> True
> >> >>> (math.sqrt(x**2)).is_integer()
> >> False
>
> [Mark Dickinson ]
> > If you have a momen
On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum wrote:
> Thank you! As you may or may not have noticed in a different thread, we're
> going through a small existential crisis regarding the usefulness of
> is_integer() -- Serhiy believes it is not useful (and even an attractive
> nuisance) and s
On Wed, Mar 21, 2018 at 12:38 PM, Steven D'Aprano
wrote:
> In fact, Serhiy's suggestion is not correct when x is not a float:
>
This is a key point -- see some of Tim's posts -- like ot or not, you
probably need to know when you are working with a float and when you aren't
-- and what the implic
[Devin Jeanpierre ]
> PyPy (5.8):
> x = 1e300
> x.is_integer()
> True
> math.sqrt(x**2).is_integer()
> False
> x**2
> inf
I think you missed that David said "even without reaching inf" (you
did reach inf), and that I said "such that x*x neither overflows nor
underflows". Those
On Wed, Mar 21, 2018 at 11:43 PM, Tim Peters wrote:
> Note: this is a top-posted essay much more about floating-point
> philosophy than about details. Details follow from the philosophy,
> and if philosophies don't match the desired details will never match
> either.
>
but of course :-)
> Fr
> [Mark Dickinson ]
>> If you have a moment to share it, I'd be interested to know what value of
>> `x` you used to achieve this, and what system you were on. This can't happen
>> under IEEE 754 arithmetic.
>
> I expect it might happen under one of the directed rounding modes
> (like "to +infinity
[David Mertz ]
>> For example, this can be true (even without reaching inf):
>>
>> >>> x.is_integer()
>> True
>> >>> (math.sqrt(x**2)).is_integer()
>> False
[Mark Dickinson ]
> If you have a moment to share it, I'd be interested to know what value of
> `x` you used to achieve this, and what syste
Note: this is a top-posted essay much more about floating-point
philosophy than about details. Details follow from the philosophy,
and if philosophies don't match the desired details will never match
either.
Understanding floating point requires accepting that they're a funky
subset of rational
On Wed, Mar 21, 2018 at 09:46:06AM -0700, Nathaniel Smith wrote:
[...]
> For me this is an argument against is_integer() rather than for it :-).
> is_prime(float) should *obviously*[1] be a TypeError. Primality is only
> meaningfully defined over the domain of integers
And 3.0 is an integer. Just
On Wed, Mar 21, 2018 at 8:49 PM, David Mertz wrote:
> For example, this can be true (even without reaching inf):
>
> >>> x.is_integer()
> True
> >>> (math.sqrt(x**2)).is_integer()
> False
>
If you have a moment to share it, I'd be interested to know what value of
`x` you used to achieve this, an
On Wed, Mar 21, 2018 at 3:02 PM, Tim Peters wrote:
> [David Mertz]
> > I've been using and teaching python for close to 20 years and I never
> > noticed that x.is_integer() exists until this thread.
>
> Except it was impossible to notice across most of those years, because
> it didn't exist acros
[David Mertz]
> I've been using and teaching python for close to 20 years and I never
> noticed that x.is_integer() exists until this thread.
Except it was impossible to notice across most of those years, because
it didn't exist across most of those years ;-)
> I would say the "one obvious way"
On Wed, Mar 21, 2018 at 11:14 AM, David Mertz wrote:
> I've been using and teaching python for close to 20 years and I never
> noticed that x.is_integer() exists until this thread. I would say the "one
> obvious way" is less than obvious.
>
> On the other hand, `x == int(x)` is genuinely obvious.
I've been using and teaching python for close to 20 years and I never
noticed that x.is_integer() exists until this thread. I would say the "one
obvious way" is less than obvious.
On the other hand, `x == int(x)` is genuinely obvious... and it immediately
suggests the probably better `math.isclose
El mié., 21 mar. 2018 a las 16:23, Guido van Rossum ()
escribió:
> Roberto,
>
> That looks like an interesting class. I presume you're intending to
> publish this as a pip package on PyPI.python.org?
>
>
Precisely.
I'm no lawyer, but I believe you can license your code under a new license
> (I re
I'd prefer to see `float.is_integer` stay. There _are_ occasions when one
wants to check that a floating-point number is integral, and on those
occasions, using `x.is_integer()` is the one obvious way to do it. I don't
think the fact that it can be misused should be grounds for deprecation.
As far
Here's an excerpted (and slightly simplified for consumption here) usage of
float.is_integer() from the top of a function which does some
convolution/filtering in a geophysics application. I've mostly seen it used
in guard clauses in this way to reject either illegal numeric arguments
directly, or
On Mar 21, 2018 05:40, "Steven D'Aprano" wrote:
I don't want to change the behaviour of pow(), but we shouldn't dismiss
the possibility of some other numeric function wanting to treat values
N.0 and N the same. Let's say, an is_prime(x) function that supports
floats as well as ints:
is_prim
On Wed, Mar 21, 2018 at 3:08 PM, Guido van Rossum wrote:
> I searched 6M LoC of Python code at Dropbox and found only three uses.
> They seem legit. Two are about formatting a number that's given as a float,
> deciding whether to print a float as 42 or 3.14. The third is attempting a
> conversion
21.03.18 17:13, Guido van Rossum пише:
Maybe spelunking in the Python 2 branch will help? It seems it was
introduced in 2005 by Jeremy Hylton with this comment:
/* The distinction between NEW_BLOCK and NEXT_BLOCK is subtle. (I'd
like to find better names.) NEW_BLOCK() creates a new block
Thank you! As you may or may not have noticed in a different thread, we're
going through a small existential crisis regarding the usefulness of
is_integer() -- Serhiy believes it is not useful (and even an attractive
nuisance) and should be deprecated. OTOH the existence of
dec_mpd_isinteger() seem
As requested on the bug tracker, I've submitted a pull request for
is_integer() support on the other numeric types.
https://github.com/python/cpython/pull/6121
These are the tactics I used to implement it:
- float: is_integer() already exists, so no changes
- int: return True
- Real: return x
Roberto,
That looks like an interesting class. I presume you're intending to publish
this as a pip package on PyPI.python.org?
I'm no lawyer, but I believe you can license your code under a new license
(I recommend BSD) as long as you keep a copy and a mention of the PSF
license in your distribut
Maybe spelunking in the Python 2 branch will help? It seems it was
introduced in 2005 by Jeremy Hylton with this comment:
/* The distinction between NEW_BLOCK and NEXT_BLOCK is subtle. (I'd
like to find better names.) NEW_BLOCK() creates a new block and sets
it as the current block. NEXT_
I searched 6M LoC of Python code at Dropbox and found only three uses. They
seem legit. Two are about formatting a number that's given as a float,
deciding whether to print a float as 42 or 3.14. The third is attempting a
conversion from float to integer where a non-integer must raise a specific
ex
Hi,
I've made a custom concurrent.futures.Executor mixing the
ProcessPoolExecutor and ThreadPoolExecutor.
I've published it here:
https://github.com/nilp0inter/threadedprocess
This executor is very similar to a ProcessPoolExecutor, but each process in
the pool have it's own ThreadPoolExecutor i
On Wed, Mar 21, 2018 at 10:31:19AM +, Chris Barker wrote:
> On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano wrote:
> > > Could float et al. add an __index__ method that would return a ValueError
> > > if the value was not an integer?
> >
> > That would allow us to write things like:
> >
> > "a
On 14 March 2018 at 08:29, Tim Peters wrote:
> [Tim]
> >> An obvious way to extend it is for Fraction() to look for a special
> >> method too, say "_as_integer_ratio()".
>
> [Greg Ewing]
> > Why not __as_integer_ratio__?
>
> Because. at this point, that would be beating a dead horse ;-)
>
I'm no
There is the NEXT_BLOCK() macro in compile.c. It creates a new block,
creates an implicit jump from the current block to the new block, and
sets it as the current block.
But why it is used? All seems working if remove NEXT_BLOCK(). If there
was a need of NEXT_BLOCK() (if it reduces the computa
>
>
> Does anybody know examples of the correct use of float.is_integer() in
> real programs? For now it looks just like a bug magnet. I suggest to
> deprecate it in 3.7 or 3.8 and remove in 3.9 or 3.10.
+1
It really doesn’t appear to be the right solution for any problem.
-CHB
--
Christopher
On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano wrote:
>
>
> > Could float et al. add an __index__ method that would return a ValueError
> > if the value was not an integer?
>
> That would allow us to write things like:
>
> "abcdefgh"[5.0]
>
> which is one of the things __index__ was invented to
I searched usages of is_integer() on GitHub and have found that it is
used *only* in silly code like (x/5).is_integer(), (x**0.5).is_integer()
(or even (x**(1/3)).is_integer()) and in loops like:
i = 0
while i < 20:
if i.is_integer():
print(i)
i += 0.1
(x/5).is_i
38 matches
Mail list logo