On Sun, Dec 29, 2019 at 03:48:07PM +, Steve Barnes wrote:
> I do have to disagree here as it is entirely possible, in the world of
> hardware interfacing, that an external hardware device could possibly
> supply an sNaN
Indeed. But since there's no guarantee in Python that this sNAN will
On Dec 29, 2019, at 23:50, Steven D'Aprano wrote:
>
> On Sun, Dec 29, 2019 at 06:23:03PM -0800, Andrew Barnert via Python-ideas
> wrote:
>
>> Likewise, it’s even easier to write ignore-nan yourself than to write the
>> DSU yourself:
>>
>>median = statistics.median(x for x in xs if not x.
On 30/12/19 12:19 pm, David Mertz wrote:
I'm sort of convinced that Posits better approximate the behavior of
rationals than do IEEE-754 floats:
https://en.m.wikipedia.org/wiki/Unum_(number_format)
Is it just me, or is that Wikipedia article abysmally written?
I feel like I gained a negative
On Sun, Dec 29, 2019 at 11:21:51PM -0500, David Mertz wrote:
> Has anyone actually ever used those available bits for the zillions of NaNs
> for anything good?
Absolutely.
Back in the 1980s, Apple released one of the first (if not the
first) IEEE-754 compliant maths library: SANE, the Standard
On 12/30/19 12:06 AM, Andrew Barnert wrote:
On Dec 29, 2019, at 20:04, Richard Damon wrote:
Thus your total_order, while not REALLY a total order, is likely good enough
for most purposes.
Well, it is a total order of equivalence classes (with all IEEE-equal values
being equivalent, all negat
64 bit binary floating point (what Python uses as Float) as 1 sign bit,
11 exponent bits, as 52 mantissa bits.
NaNs are numbers with the exponent bits being all ones, with the
exception that exponent bits all ones and mantissa bits all zeros is
infinity.
Within NaNs, the MSB of the mantissa in
Hello,
I was thinking about giving loops names. And It would be interesting if through
this name in a continue or break statement could be called.
A little example what I mean:
loop "outloop" while True:
actmonth = datetime.datetime.now().month
loop "innerloop" for i in range(0, int(inpu
A very similar proposal was rejected:
https://www.python.org/dev/peps/pep-3136/.
Also, see the discussion in
https://mail.python.org/archives/list/python-ideas@python.org/thread/26PAGUTJ66S3BIZTL57IHUIYAHA7YOTV/#23H2S2AJFPRK46UID5MBHJJ7A3ERUBJA
.
If you'd still like to propose this, you'll have t
On Mon, Dec 30, 2019 at 2:58 AM Steven D'Aprano wrote:
> Can you explain the scenario where somebody using median will want
> negative NANs to sort to the beginning, below -INF, and positive NANs to
> sort to the end, above +INF?
>
I can kinda-sorta provide a case. But overall, despite my whims
On Mon, Dec 30, 2019 at 3:32 AM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Dec 29, 2019, at 23:50, Steven D'Aprano wrote:
> >
> > On Sun, Dec 29, 2019 at 06:23:03PM -0800, Andrew Barnert via
> Python-ideas wrote:
> >
> >> Likewise, it’s even easier to write ignore-nan
On 12/30/19 2:10 AM, Chris Angelico wrote:
On Mon, Dec 30, 2019 at 3:52 PM Andrew Barnert wrote:
On Dec 29, 2019, at 18:50, Chris Angelico wrote:
On Mon, Dec 30, 2019 at 1:40 PM Andrew Barnert wrote:
On Dec 29, 2019, at 18:20, Chris Angelico wrote:
Counting numbers are intuitively number
Steven D'Aprano wrote:
> Can you explain the scenario where somebody using median will want
>> negative NANs to sort to the beginning, below -INF, and positive NANs to
>> sort to the end, above +INF?
>
>
No, and I don’t think anyone really wants that. I think it was proposed as
a possible improv
On 12/30/19 11:54 AM, David Mertz wrote:
On Mon, Dec 30, 2019 at 3:32 AM Andrew Barnert via Python-ideas
mailto:python-ideas@python.org>> wrote:
On Dec 29, 2019, at 23:50, Steven D'Aprano mailto:st...@pearwood.info>> wrote:
>
> On Sun, Dec 29, 2019 at 06:23:03PM -0800, Andrew Barne
On 12/30/19 12:18 PM, Christopher Barker wrote:
Steven D'Aprano mailto:st...@pearwood.info>> wrote:
Can you explain the scenario where somebody using median will
want
negative NANs to sort to the beginning, below -INF, and
positive NANs to
sort to the end,
On Mon, Dec 30, 2019 at 12:37 PM Richard Damon
wrote:
> My preference is that the interpretation that NaN means Missing Data
> isn't appropriate for for the statistics module.
You need to tel the entire PyData ecosystem, the entire R ecosystem, and a
pretty much all of Data Science that they ar
On 12/30/19 12:45 PM, David Mertz wrote:
On Mon, Dec 30, 2019 at 12:37 PM Richard Damon
mailto:rich...@damon-family.org>> wrote:
My preference is that the interpretation that NaN means Missing Data
isn't appropriate for for the statistics module.
You need to tel the entire PyData ec
On Dec 30, 2019, at 06:50, Richard Damon wrote:
>
> On 12/30/19 12:06 AM, Andrew Barnert wrote:
>>> On Dec 29, 2019, at 20:04, Richard Damon wrote:
>>> Thus your total_order, while not REALLY a total order, is likely good
>>> enough for most purposes.
>> Well, it is a total order of equivalenc
On 12/30/19 4:22 PM, Andrew Barnert via Python-ideas wrote:
On Dec 30, 2019, at 06:50, Richard Damon wrote:
On 12/30/19 12:06 AM, Andrew Barnert wrote:
On Dec 29, 2019, at 20:04, Richard Damon wrote:
Thus your total_order, while not REALLY a total order, is likely good enough
for most purpo
> On Dec 30, 2019, at 08:55, David Mertz wrote:
>> Presumably the end user (unlike the statistics module) knows what data they
>> have.
>
> No, Steven is right here. In Python we might very sensibly mix numeric
> datatypes.
The statistics module explicitly doesn’t support doing so. Which mea
On Mon, Dec 30, 2019, 5:17 PM Andrew Barnert
> The fact that all three of the alternate orders anyone’s asked for or
> suggested turned out to be spurious, and nobody can think of a good use for
> a different one, that’s a pretty good argument that YAGNI.
>
I think everyone agrees that the only a
On Mon, Dec 30, 2019 at 06:10:37PM +1100, Chris Angelico wrote:
> But the question is: What should the statistics module do with a nan?
> This can only be answered by understanding what "nan" means in a
> statistical context, which is only tangentially related to the
> question of whether nan is a
> On Dec 30, 2019, at 14:05, Richard Damon wrote:
>
> On 12/30/19 4:22 PM, Andrew Barnert via Python-ideas wrote:
>>> On Dec 30, 2019, at 06:50, Richard Damon wrote:
>>> On 12/30/19 12:06 AM, Andrew Barnert wrote:
> On Dec 29, 2019, at 20:04, Richard Damon wrote:
> Thus your total_ord
> The order he generates is very close to the IEEE total order, the
difference are:
> > 1) It doesn't seperate -0 for +0, which shouldn't matter for most
> applications.
> > 2) It doesn't provide an order between NaNs, but unless you are taking
> special measures to distinguish the NaNs anyway, th
On Dec 30, 2019, at 14:35, David Mertz wrote:
>
> On Mon, Dec 30, 2019, 5:17 PM Andrew Barnert
>> The fact that all three of the alternate orders anyone’s asked for or
>> suggested turned out to be spurious, and nobody can think of a good use for
>> a different one, that’s a pretty good argume
On Dec 30, 2019, at 15:56, David Mertz wrote:
>
>
> > The order he generates is very close to the IEEE total order, the
> > difference are:
>> > 1) It doesn't seperate -0 for +0, which shouldn't matter for most
>> > applications.
>> > 2) It doesn't provide an order between NaNs, but unless yo
On Mon, Dec 30, 2019 at 06:55:56PM -0500, David Mertz wrote:
> > The order he generates is very close to the IEEE total order, the
> difference are:
>
> > > 1) It doesn't seperate -0 for +0, which shouldn't matter for most
> > applications.
> > > 2) It doesn't provide an order between NaNs, but un
On 12/30/19 6:55 PM, David Mertz wrote:
> The order he generates is very close to the IEEE total order, the
difference are:
> 1) It doesn't seperate -0 for +0, which shouldn't matter for
most applications.
> 2) It doesn't provide an order between NaNs, but unless you are
taking
Marco Sulla wrote:
> First, C and assembly has no boolean type.
Not to focus on this because it's not particularly relevant to the original
topic, but this isn't true: C99 added the boolean type "_Bool", which can
be aliased as "bool" with the header.
On Thu, Dec 26, 2019 at 8:53 PM Marco Sulla
28 matches
Mail list logo
