Ah, always mess up micro = 6/9 until I think about it for half a second.
Maybe a "n" suffix could have saved me there ;) For "long" numbers there's
the new _ so you can say 0.000_000_1 if you so preferred for 0.1 micro (I
generally see _ as more useful for high-precison numbers with more non-zero
d
On Sat, Oct 29, 2016 at 12:43 PM, Nick Timkovich
wrote:
> From that page:
>
>> User-defined literals are basically normal function calls with a fancy
>> syntax. [...] While user defined literals look very neat, they are not much
>> more than syntactic sugar. There is not much difference between d
On 2016-10-29 17:43, Nick Timkovich wrote:
[snip]
Also, for discussion, remember to make the distinction between 'units'
(amps, meters, seconds) and 'prefixes' (micro, milli, kilo, mega). Right
away from comments, it seems 1_m could look like 1 meter to some, or
0.001 to others. Typically when I
>From that page:
> User-defined literals are basically normal function calls with a fancy
> syntax. [...] While user defined literals look very neat, they are not much
> more than syntactic sugar. There is not much difference between defining
> and calling a literal operator with "foo"_bar and doi
I'd certainly be interested in hearing about how this has worked with C++,
but this would certainly make scientific code less easy to misuse due to
unclear units.
-Ryan Birmingham
On 28 October 2016 at 16:45, Sven R. Kunze wrote:
> On 28.10.2016 22:06, MRAB wrote:
>
>> On 2016-08-26 13:47, Stev
On 28.10.2016 22:06, MRAB wrote:
On 2016-08-26 13:47, Steven D'Aprano wrote:
Ken has made what I consider a very reasonable suggestion, to introduce
SI prefixes to Python syntax for numbers. For example, typing 1K will be
equivalent to 1000.
Just for the record, this is what you can now do in
On 2016-08-26 13:47, Steven D'Aprano wrote:
Ken has made what I consider a very reasonable suggestion, to introduce
SI prefixes to Python syntax for numbers. For example, typing 1K will be
equivalent to 1000.
Just for the record, this is what you can now do in C++:
User-Defined Literals
http:/
On Sun, Aug 28, 2016 at 11:37:00AM +0100, Paul Moore wrote:
> And if you're concerned about larger numbers, such as 160, and
> the need to count zeroes, I'd argue that you should name such a
> constant - and Python 3.6 will allow you to write it as 16_000_000_000
> in any case, making thin
On 27 August 2016 at 23:39, Arek Bulski wrote:
> They can be used simply out of convenience, like 4K is a shorthand for 4000.
> And 9G is definitely easier to write and *therefore less prone to error*
> than a full literal.
I dispute "less prone to error". Like it or not, there are a lot of
peopl
Just to mention, these K M G suffixes are dimensionless. They can be used
simply out of convenience, like 4K is a shorthand for 4000. And 9G is
definitely easier to write and *therefore less prone to error* than a full
literal. Dimensional analysis is fine but not the only reason to add these.
poz
Ken Kundert writes:
> The rule is you cannot give unit without a scale factor, and the
> unity scale factor is _, so if you wanted to say 1 mol you would
> use 1_mol. 1mol means one milli ol. These look a little strange,
> but that is because the use they unit scale factor, which is the
> on
SI units are a standard that was kind of imposed top down on the computer
science community. But we learned to use KB MB so why no keep the defacto
standard we already have? Kibibytes and mibibytes were never really
adopted.
1K == 1000
1KB == 1024
1M == 1000**2
1MB == 1024**2
Suffixes, simple.
i
On Sat, Aug 27, 2016 at 03:24:49PM +0900, Stephen J. Turnbull wrote:
> If you want to change the *language* you need to provide answers to
> the following. I have no answers to them that I like, but maybe you
> can do better.
>
> How about 2.4Gaunitwithaveryveryveryveryveryverylongname?
Why woul
Steven D'Aprano wrote:
Why is it obvious that you're expecting a float and not
a decimal in that case?
Because if you search the list archives you'll see that, in the short
term at least, I'm not in favour of changing the default floating point
type from binary floats to decimal floats *wink
>> Proposal number two: don't make any changes to the syntax, but treat
these as *literally* numeric scale factors.
>> k = kilo = 10**3
>> M = mega = 10**6
>> G = giga = 10**9
>>
>> int_value = 8*M float_value = 8.0*M
>> fraction_value = Fraction(1, 8)*M
>> decimal_value = Decimal("1.2345")*M
This
On Sat, Aug 27, 2016 at 01:16:42PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
>
> >Obviously if I write 1.1K then I'm expecting a float.
>
> Why is it obvious that you're expecting a float and not
> a decimal in that case?
Because if you search the list archives you'll see that, in the sh
Ken Kundert writes:
> I'd like to continue the discussion because I believe there is some
> chance that we could reach that bar even though Guido is clearly
> skeptical.
OK.
> input to the language. To be consistent with that, it seems like 2G
> or 2GHz should be preferred over 2_G or 2_GHz
Steven D'Aprano wrote:
Obviously if I write 1.1K then I'm expecting a float.
Why is it obvious that you're expecting a float and not
a decimal in that case?
The SI units are all decimal, and I think if we support these, we should
insist that K == 1000, not 1024. For binary scale factors, the
On 2016-08-26 22:25, Ken Kundert wrote:
Okay, so I talked to Guido about this, and all he was trying to convey is that
there is an extremely high bar that must be reached before he will consider
changing the base language, which of course is both prudent and expected.
I'd like to continue the di
Okay, so I talked to Guido about this, and all he was trying to convey is that
there is an extremely high bar that must be reached before he will consider
changing the base language, which of course is both prudent and expected.
I'd like to continue the discussion because I believe there is some c
On 8/26/2016 8:47 AM, Steven D'Aprano wrote:
This leads to my first proposal: require an explicit numeric prefix on
numbers before scale factors are allowed, similar to how we treat
non-decimal bases.
8M # remains a syntax error
-1 for the syntax, +1 for keeping it an error
0s8M # unambig
On 8/26/16, Steven D'Aprano wrote:
[...]
> from scaling import *
> int_value = 8*M
> float_value = 8.0*M
> fraction_value = Fraction(1, 8)*M
> decimal_value = Decimal("1.2345")*M
[...]
> Disadvantages: none I can think of.
Really interesting idea, but from my POV a little disadvantage is
"import
On 2016-08-26 14:34, Chris Angelico wrote:
On Fri, Aug 26, 2016 at 10:47 PM, Steven D'Aprano wrote:
[snip]
Or if that's too heavy (two whole characters, plus the suffix!) perhaps
we could have a rule that the suffix must follow the final underscore
of the number:
8_M # int 8*10*6
123_456_789
On Fri, Aug 26, 2016 at 5:47 AM, Steven D'Aprano
wrote:
> Ken has made what I consider a very reasonable suggestion, to introduce
> SI prefixes to Python syntax for numbers. For example, typing 1K will be
> equivalent to 1000.
>
> However, there are some complexities that have been glossed over.
On Fri, Aug 26, 2016 at 10:47 PM, Steven D'Aprano wrote:
> (1) Are the results floats, ints, or something else?
>
> I would expect that 1K would be int 1000, not float 1000. But what about
> fractional prefixes, like 1m? Should that be a float or a decimal?
>
> If I write 7981m I would expect 7.98
Ken has made what I consider a very reasonable suggestion, to introduce
SI prefixes to Python syntax for numbers. For example, typing 1K will be
equivalent to 1000.
However, there are some complexities that have been glossed over.
(1) Are the results floats, ints, or something else?
I would ex
26 matches
Mail list logo