On 21.09.2017 03:32, Nick Coghlan wrote:
> On 21 September 2017 at 10:51, Ned Batchelder wrote:
>> Write a document that proposes some quality metrics. Share it around. Get
>> people to like it. If it becomes popular, then people will start to value it
>> as a standard for project quality.
>
> An
On 21 September 2017 at 02:53, Steven D'Aprano wrote:
> On Thu, Sep 21, 2017 at 11:13:44AM +1000, Nick Coghlan wrote:
>
>> I think so, as consider this question: how do you write a script that
>> accepts a user-supplied string (e.g. from a CSV file) and treats it as
>> hex floating point if it has
On 9/20/17, alexandre.gal...@gmail.com wrote:
[...]
> But i think, as wee need to avoid to talk about any tool name in the PEP,
> we need to avoid to give a code example. The aim of this proposal is to
> have a guideline on minimal metrics to have minimal quality.
Michel Foucault wrote book
(ht
2017-09-21 3:53 GMT+02:00 Steven D'Aprano :
> float.fromhex(s) if s.startswith('0x') else float(s)
My vote is now -1 on extending the Python syntax to add hexadecimal
floating literals.
While I was first in favor of extending the Python syntax, I changed
my mind. Float constants written in hexade
On Thu, Sep 21, 2017 at 8:23 AM, Victor Stinner
wrote:
> While I was first in favor of extending the Python syntax, I changed
> my mind. Float constants written in hexadecimal is a (very?) rare use
> case, and there is already float.fromhex() available.
>
> A new syntax is something more to learn
-1
Writing a floating point literal requires A LOT more knowledge than writing
a hex integer.
What is the bit length of floats on your specific Python compile? What
happens if you specify more or less precision than actually available.
Where is the underflow to subnormal numbers? What is the bit
Tablet autocorrect: bit representation of inf and -inf.
On Sep 21, 2017 1:09 PM, "David Mertz" wrote:
> -1
>
> Writing a floating point literal requires A LOT more knowledge than
> writing a hex integer.
>
> What is the bit length of floats on your specific Python compile? What
> happens if you
One of my hesitations on this topic is that it could create a false sense of
security. And I mean security in both the 'comfortable with the code base'
sense leading to insufficient testing, as well as 'we have a top-notch quality
level, there are no vulnerabilities'. The one thing that I keep c
On Thu, Sep 21, 2017 at 01:09:11PM -0700, David Mertz wrote:
> -1
>
> Writing a floating point literal requires A LOT more knowledge than writing
> a hex integer.
>
> What is the bit length of floats on your specific Python compile?
Are there actually any Python implementations or builds which h
Lucas Wiman wrote:
It is inconsistent that you can write hexadecimal integers but not
floating point numbers. Consistency in syntax is /fewer/ things to
learn, not more.
You still need to learn the details of the hex syntax for
floats, though. It's not obvious e.g. that you need to use
"p" for
On Thu, Sep 21, 2017 at 1:57 AM, Paul Moore wrote:
> ...
>
> It's also worth remembering that there will be implementations other
> than CPython that will need changes, too - Jython, PyPy, possibly
> Cython, and many editors and IDEs. So setting the bar at "someone who
> wants this will have to s
On Thu, Sep 21, 2017 at 7:32 PM, Steven D'Aprano
wrote:
> On Thu, Sep 21, 2017 at 01:09:11PM -0700, David Mertz wrote:
> > -1
> >
> > Writing a floating point literal requires A LOT more knowledge than
> writing
> > a hex integer.
> >
> > What is the bit length of floats on your specific Python c
I think you are missing the point I was assuming at. Having a binary/hex
float literal would tempt users to think "I know EXACTLY what number I'm
spelling this way"... where most users definitely don't in edge cases.
Spelling it float.fromhex(s) makes it more obvious "this is an expert
operation I
[David Mertz ]
> -1
>
> Writing a floating point literal requires A LOT more knowledge than writing
> a hex integer.
But not really more than writing a decimal float literal in
"scientific notation". People who use floats are used to the latter.
Besides using "p" instead of "e" to mark the expone
On Thu, Sep 21, 2017 at 7:57 PM, David Mertz wrote:
> I think you are missing the point I was assuming at. Having a binary/hex
> float literal would tempt users to think "I know EXACTLY what number I'm
> spelling this way"... where most users definitely don't in edge cases.
>
That problem has ne
When I teach, I usually present this to students:
>>> (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)
False
This is really easy as a way to say "floating point numbers are
approximations where you often encounter rounding errors" The fact the
"edge cases" are actually pretty central and commonplace in de
On Thu, Sep 21, 2017 at 8:30 PM, David Mertz wrote:
> Simply because the edge cases for working with e.g. '0xC.68p+2' in a
> hypothetical future Python are less obvious and less simple to demonstrate,
> I feel like learners will be tempted to think that using this base-2/16
> representation saves
When I teach, I usually present this to students:
>>> (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)
False
This is really easy as a way to say "floating point numbers are
approximations where you often encounter rounding errors" The fact the
"edge cases" are actually pretty central and commonplace in de
On 22 September 2017 at 13:38, Guido van Rossum wrote:
> On Thu, Sep 21, 2017 at 8:30 PM, David Mertz wrote:
>>
>> Simply because the edge cases for working with e.g. '0xC.68p+2' in a
>> hypothetical future Python are less obvious and less simple to demonstrate,
>> I feel like learners will be te
19 matches
Mail list logo
