On Fri, Aug 26, 2016 at 4:54 PM, Steven D'Aprano wrote:
> But you're not in the world of circuit design any more, you are dealing
> with a programming language that will be used by people for many,
> many different purposes, for whom "unity" might mean (for example):
>
> 1 foot per second
> 1 foot
On 26 August 2016 at 16:54, Steven D'Aprano wrote:
> At best, we can choose descriptive variable names that hint what the
> correct dimensions should be:
>
> weight_of_contents + weight_of_container
>
>
> The argument that units would make it easier for the programmer to spot
> errors is, I th
On Thu, Aug 25, 2016 at 11:34:23PM -0400, Random832 wrote:
> On Thu, Aug 25, 2016, at 19:50, Steven D'Aprano wrote:
> > Historically, there are *three* different meanings for "MB", only one of
> > which is an official standard:
> >
> > http://physics.nist.gov/cuu/Units/binary.html
>
> The link d
On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> On 8/25/16, Ken Kundert wrote:
>
> [...]
>
> > Just allowing the units to be present, even it not
> >
> > retained, is a big advantage because it can bring a great deal of clarity to
> > the
> > meaning of the number. For example, eve
On Fri, Aug 26, 2016 at 06:31:30PM +1000, Nick Coghlan wrote:
> On 26 August 2016 at 16:54, Steven D'Aprano wrote:
> > At best, we can choose descriptive variable names that hint what the
> > correct dimensions should be:
> >
> > weight_of_contents + weight_of_container
> >
> >
> > The argumen
On 26 August 2016 at 13:01, Steven D'Aprano wrote:
> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> > On 8/25/16, Ken Kundert wrote:
> >
> > [...]
> >
> > > Just allowing the units to be present, even it not
> > >
> > > retained, is a big advantage because it can bring a great dea
On 26 August 2016 at 14:49, Ivan Levkivskyi wrote:
> On 26 August 2016 at 13:01, Steven D'Aprano wrote:
>
>> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
>> > On 8/25/16, Ken Kundert wrote:
>> >
>> > [...]
>> >
>> > > Just allowing the units to be present, even it not
>> > >
>> >
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
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
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 2016-08-26 07:54, Steven D'Aprano wrote:
[snip]
Specialist applications might be able to take shortcuts in
dimensional analysis when "everybody knows" what the suppressed units
must be. General purpose programming languages *cannot*. It is better
NOT to offer the illusion of dimensional analys
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 02:49:51PM +0300, Ivan Levkivskyi wrote:
> 1. By defining __mul__ and __truediv__ on m, s, and other units one can
> achieve the desirable semantics
I'm not entirely sure about that. I'm not even close to an expert on the
theory of types, so I welcome correction, but it d
On 26 August 2016 at 23:34, Chris Angelico wrote:
> Introduce "d" as a prefix meaning 1, and this could be the way of
> creating something that people have periodically asked for: Decimal
> literals.
>
> (Though IIRC there were some complexities involving Decimal literals
> and decimal.getcontext(
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 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
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
Steven,
This keeps coming up, so let me address it again.
First, I concede that you are correct that my proposal does not provide
dimensional analysis, so any dimensional errors that exist in this new code
will
not be caught by Python itself, as is currently the case.
However, you should c
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
On Fri, Aug 26, 2016 at 03:23:24PM -0700, Ken Kundert wrote:
> Second, I concede that there is some chance that users may be lulled into
> a false sense of complacency and that some dimensional errors would get
> missed
> by these otherwise normally very diligent users. But I would point out th
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
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
22 matches
Mail list logo
