[Python-ideas] Re: Fwd: Optional kwarg for sequence methods in random module
Senhaji Rhazi hamza writes: > I think there is a way to map x <- [1; + inf] to y <- [0;1] by > putting y = 1/x I don't think that's the point. I'll put money on a poor choice of value for the random parameter in the example: the OP chose the Pareto variate because that's what he mentioned earlier. But there are plenty of distributions besides uniform that can be parametrized to have support included in [0,1]. To me, it also seems a little odd that random.choices supports only discrete populations (possibly with weights) but doesn't support float populations. I think r.choices(random=lambda: random.paretovariate(1.75), k=k) would be a nice way to spell "sample with replacement from Pareto distribution of size k". But as Steven d'Aprano points out, you can also spell it [ random.paretovariate(1.75) for _ in range(k) ] so there's no real need to generalize Random.choices. On the other hand, r.sample(random=lambda: random.paretovariate(1.75), k=k) doesn't make immediate sense to me. What does "sampling without replacement" mean if you don't have an explicit population? (Note that random.sample doesn't support weights for a similar reason, although it could support counts.) So this suggests to me that the proposed ``random`` parameter to sequence methods is actually a spurious generalization, and has different interpretations for different methods. So I'm not against this proposal at this point, but I think it needs to be fleshed out more, both in terms of the principle we're trying to implement, and some more detailed examples. Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JR3G22W4H3JTO4KC5DJGCTEZKI26KHUP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Adding support for adequately tagging AIX (pep425) to support distributed wheels
Goal - using wheels rather than RPM and/or installp formats for
distributing binary modules
Why bother?
One reason (there are likely more) - using wheels means packages/modules
can be loaded in a virtualenv
rather than require they are first loaded in the system environment
using installp/rpm/yum (with root authority). This alone has been reason
enough for me to do the research.
Introduction
The use of pip and wheels is commonplace in the worlds of Linux, macOS
and Windows.
Not so for AIX. Not because it couldn't be commonplace.
The current situation for AIX is comparable to the initial issue Linux
was facing
when PEP513 was written:
"Currently, distribution of binary Python extensions for Windows and OS
X is straightforward. ...
For Linux, the situation is much more delicate. ...
Build tools using PEP 425 platform tags [3] do not track information
about the particular Linux distribution or installed system libraries,
and instead assign all wheels the too-vague linux_i686 or linux_x86_64
tags. Because of this ambiguity, ..."
The root cause for the *ambiguity* that Linux systems had is not the
ambiguity that AIX faces.
AIX has provided a consistent way to "tag" it's runtime environment
since at least 2007 (AIX 5.3 TL7).
Since that time IBM AIX has also *guaranteed* binary compatibility for
migration of applications
from old to new OS levels.
I would like to see these tags added - at a minimum that they can be
retrieved by something such as sysconfig.get_var('AIC_BLD_TAG'). It
would be "nice" to see sysconfig.get_platform() updated to include these
values from the running system.
Further, while pip related tools can add the "bitness" to the platform
tags I would like to see something added to the AIX get_platform() tag
(b32, ppc, aix32), (b64, ppc64, aix64) for 32 and 64 bit operations,
respectively - as that is a "running" environment attribute. Open to
other ideas on what the bitness tag should be. IMHO - anything is better
than nothing. Maybe this could be considered a bug rather than as a new
feature.
Thank you for your feedback.
Michael
signature.asc
Description: OpenPGP digital signature
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/DVHVSY7HFAK6B6BASXER2FUGXZN567UY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Optional kwarg for sequence methods in random module
Hey Steven,
Thank you for having taken the time to comment qualitatively my response.
For the first part :
I think there is a way to map x <- [1; + inf] to y <- [0;1] by putting y =
1/x
I didn't pay attention of the fact stated by @Richard Damon
that the shape of distribution won't be
preserved not only because of the argument that the distribution will goes
from (0, 1] instead of [0. 1) but the pareto shape will change, and the
solution shifted, scaled, and truncated Pareto make more sens
For the second part
But i think there is another issue to consider :
for example if we want to sort :
random.choice(['a', 'b', 'c'], random=lambda: random.paretovariate(1.75)),
we should have a mapping
between the elements of the list (here :a,b,c) to [0, 1] and the reverser
mapping, having this mapping underline
that we have a notion of order and distance, "measurement" between the
elements, and it is not trivial to always
have a notion of "order" or "distance" between the elements we manipulate,
but it could be fun
to have this possibility.
At
To answer the following questions :
- What are you sorting ?
- What is this reverser mapping ?
- Why are you switching from probability concepts to metric theory
halfway through the paragraph?
- Maybe it would help if you could explain what you expected this to do.
What should the odds of a, b, and c be in your function?
At the best of my understanding, we define a probabilisable space by
(omega, tribute, P) and
*X* the random variable as the mesurable function that goes from (omega,
tribute, P) to the measurable
space (E, Eta)
the space omega could be anything for example it could be *['a','b','c'] *but
we need a function
that knows how to go from subset *s *of omega (where *s* <- tribute) to a
subset *s2* of E (where *s2* <- Eta)
and actually by measuring, *P('a')* we are measuring *P(X^-1(b) =a)* =
*Px(b)) *where (b <- Eta)
As an example for bernnouli law (flipping coin for example)
Ω = { ω 1 , ω 2 } ;
E = {0,1}
T (tribute) = P(Ω) ;
P( ω 1 ) = p, P( ω 2 ) = 1 − p où p ∈]0, 1[.
X( ω 1 ) = 1, X( ω 2 ) = 0.
Px(1) = P(X −1 (1)) = P( ω 1 ) = p et Px(0) = P(X −1 (0)) = P( ω 2 ) = 1 −
p.
So the mapping function is *X *and the reverse mapping function is *X^-1*
To resume the idea, the mapping *X *allow us to go from abstract elements
('a','b','c') that we do not
measure directly (P(a)) to elements we can measure(Px(1)) and by having *X *we
will be able to have the odds of a, b, and c
so my idea was to give this function *X* as a helper function that the user
should define, that will know how to map subsets of the starting space for
example subsets from *ASCII* to subsets of a measurable spaces (the
easiest one, would be [0,1], the measure in that space will be the identity)
This is why i have bringed some metric concepts.
I'm sorry i couldn't get the last part :
It sounds like a good idea on the face of it. The only obvious problems
are the limitations of only having a double rather than as many bits as
needed, and coming from a PRNG with a limited period compared to 2^N for
large N, both of which are if anything even bigger problems for shuffle,
which already allows a random argument. So, why not choice and sample too?
I don't know if we are better without it, but it seems to be complex for a
practical daily use !
Best regards,
--
SENHAJI RHAZI Hamza
Le dim. 18 août 2019 à 23:16, Andrew Barnert a écrit :
> On Aug 18, 2019, at 06:20, Senhaji Rhazi hamza <
> hamza.senhajirh...@gmail.com> wrote:
>
> Hey Steven,
>
> I think there is a way to map x <- [1; + inf] to y <- [0;1] by putting y =
> 1/x
>
>
> Well, that gives you a distribution from (0, 1] instead of [0. 1), which
> is technically not legal as a substitute for random, even though it’ll
> actually only matter 1 in about 2^42 runs. You could pass this to shuffle
> today and probably get away with it, so asking for the same in choice, etc.
> isn’t too outrageous. But it’s still hard to judge whether it’s a good
> suggestion, if we don’t actually know what you’re trying to accomplish.
>
> First, there’s no way random could even know that you needed anything
> transformed. The distribution functions don’t come with metadata describing
> their support, and, even if they did, a new lambda that you pass in
> wouldn’t. As far as it could possibly tell, you passed in something that
> claims to be a nullary function that returns values in [0, 1), and it is a
> nullary function, and that’s all it knows.
>
> More importantly, even if that weren’t a problem, 1/x is hardly the one
> and only one obvious guess at how to turn Pareto into something with the
> appropriate support. In fact, I suspect more people would probably want a
> shifted, scaled, and truncated Pareto if they asked for Pareto. (Much as
> people often tall about things like the mean of a Cauchy distribution,
> which doesn’t exist but can be approximated very well with the mean of a
> Cauchy distribution truncated to some very
[Python-ideas] Re: [Distutils] Linux binary wheels?
How does this proposal differ from manylinux2010? https://github.com/pypa/manylinux/blob/master/README.rst#example PEP 513: manylinux1 https://www.python.org/dev/peps/pep-0513/ PEP 571: The manylinux2010 Platform Tag (latest, as of 2019) https://www.python.org/dev/peps/pep-0571/ On Monday, August 19, 2019, Dan Stromberg wrote: > Hi folks. > I have a pair of ideas about Linux binary wheels, which are currently (I > heard) unsupported. > It seems like it should be possible to support Linux binary wheels using > one or both of these technologies: > * https://build.opensuse.org/ is a service that builds packages for a > variety of Linuxes > * Docker could be used to automate the building of wheels for a handful of > Linuxes with minimal dependencies. It seems like if you get > Debian/Ubuntu/Mint, Fedora/CentOS, openSUSE and perhaps one or two others, > that would cover almost all Linuxes and Linux users. > > I'm up to my hears in commitments already, but I sincerely someone will > grab onto one or both of these possibilities and run with them. > Thanks for reading. > > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HN7KH55YBWV2PCGKZBI23NAYWLW5OQQI/ Code of Conduct: http://python.org/psf/codeofconduct/
