Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #110513 > unrolled thread

Assignment Versus Equality

Back to article view | Back to comp.lang.python

Contents

  Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-26 00:36 -0700
    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 11:48 +0100
      Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-26 23:21 +1000
        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-26 07:26 -0700
          Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-26 11:31 -0400
        Re: Assignment Versus Equality Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-26 11:47 -0700
        Re: Assignment Versus Equality Michael Torrie <torriem@gmail.com> - 2016-06-26 15:28 -0600
        Re: Assignment Versus Equality Bob Gailer <bgailer@gmail.com> - 2016-06-27 08:22 -0400
          Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 05:48 -0700
            Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-27 23:28 +1000
              Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-27 16:58 +0300
              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 07:23 -0700
                Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:05 +1000
                  Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 21:31 -0700
                    Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-28 15:42 +1000
                      Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 16:04 +1000
                        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 09:12 +0300
                          Re: Assignment Versus Equality Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-28 11:04 +0300
                      Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 23:09 -0700
                        Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 00:12 -0700
                          Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 17:26 +1000
                            Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 01:49 -0700
                              Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-28 20:34 +1000
                                Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 17:42 -0700
                    Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-28 10:13 -0400
                      Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 19:39 +0300
                        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 19:41 +0300
                        Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-28 13:19 -0400
                        Re: Assignment Versus Equality Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-28 12:27 -0600
                          Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 22:40 +0300
                            Re: Assignment Versus Equality Gene Heskett <gheskett@shentel.net> - 2016-06-28 16:59 -0400
                        Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-30 12:29 +1200
                          Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-30 12:50 +1000
                          Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-30 09:22 +0300
                      Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 12:27 +1000
                        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 20:52 -0700
                          Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 21:03 -0700
                        Re: Assignment Versus Equality Random832 <random832@fastmail.com> - 2016-06-29 00:52 -0400
                Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 18:14 -0700
              Re: Assignment Versus Equality Gene Heskett <gheskett@shentel.net> - 2016-06-27 11:21 -0400
            Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 20:04 -0400
      Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-26 11:21 -0400
        Re: Assignment Versus Equality Cousin Stanley <HooDunnit@didly42KahZidly.net> - 2016-06-26 08:47 -0700
          Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 16:56 +0100
            Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:38 +1200
            Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 07:30 -0400
              Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:17 +1200
            Re: Assignment Versus Equality Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-27 13:59 +0000
              Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-27 17:09 +0300
                Re: Assignment Versus Equality sohcahtoa82@gmail.com - 2016-06-27 17:33 -0700
                  Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-28 07:25 +0300
                    Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 23:54 -0700
              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 07:10 -0700
                Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 12:35 +1000
                  Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 14:19 +1000
                    Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 21:51 -0700
                      Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 15:07 +1000
                        Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 22:55 -0700
                          Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 16:26 +1000
                            Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 23:33 -0700
                              Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-28 23:37 -0700
                      Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-29 15:26 +1000
                        Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-28 22:51 -0700
                          Re: Assignment Versus Equality Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-29 16:45 +1000
                            Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-29 01:07 -0700
                            Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 18:09 +1000
                              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-29 22:36 +1000
                                Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 14:24 +0100
                                  Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 23:35 +1000
                                    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 15:47 +0100
                                Re: Assignment Versus Equality Chris Angelico <rosuav@gmail.com> - 2016-06-29 23:34 +1000
                        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 10:49 +0100
                          Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-29 02:56 -0700
                            Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-29 11:10 +0100
                  Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-29 03:24 -0700
              Re: Assignment Versus Equality Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2016-06-27 16:48 +0200
                Re: Assignment Versus Equality Rustom Mody <rustompmody@gmail.com> - 2016-06-27 22:00 -0700
              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:34 +1000
            Re: Assignment Versus Equality MRAB <python@mrabarnett.plus.com> - 2016-06-27 16:27 +0100
              Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 14:56 -0700
              Re: Assignment Versus Equality Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-27 15:45 -0700
                Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-28 00:08 +0100
                  Re: Assignment Versus Equality Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-27 20:11 -0400
                    Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-28 11:35 +0100
                  Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:59 +1200
              Re: Assignment Versus Equality Steven D'Aprano <steve@pearwood.info> - 2016-06-28 11:28 +1000
            Re: Assignment Versus Equality Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-27 15:42 +0000
        Re: Assignment Versus Equality Marko Rauhamaa <marko@pacujo.net> - 2016-06-26 19:11 +0300
      Re: Assignment Versus Equality MRAB <python@mrabarnett.plus.com> - 2016-06-26 16:41 +0100
        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-26 17:08 +0100
      Re: Assignment Versus Equality Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-26 11:53 -0700
        Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:41 +1200
      Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-27 11:22 +1200
        Re: Assignment Versus Equality BartC <bc@freeuk.com> - 2016-06-27 00:39 +0100
          Re: Assignment Versus Equality Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-28 18:15 +1200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#110620

On Mon, 27 Jun 2016 05:48:26 -0700 (PDT), Rustom Mody
<rustompmody@gmail.com> declaimed the following:


>In the past, APL's ? may not have been practicable (ie
>- without committing to IBM... which meant
>- $$$ 
>- Also it was a hardware commitment (trackball?)
>- etc
>
	APL was available on the Xerox Sigma under CP/V.

	For "real" APL one did need to use one of the rare Tektronix storage
display terminals that had the APL character set -- but many APLs were
designed to also parse words... $RHO instead of the greek rho character,
for example. This allowed APL to be used on plain (ASCII) terminals.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#110519

On Sun, 26 Jun 2016 11:48:30 +0100, BartC <bc@freeuk.com> declaimed the
following:

>
>(I think Fortran and PL/I also used "=" for assignment. Both were more 
>commercially successful than Algol or Pascal.)
>
	It did... but I'm sure we'd have a revolt if Python comparison
operators looked like:

	a .eq. b
	a .ne. b
	a .gt. b .or. c .lt. d
	a .le. b .and. c .ge. d

	Fortran 90 finally incorporated >= and kin as standard (some FORTRAN 77
compilers might have allowed them as non-standard extensions)... BTW: .eq.
is == in F90 (though, the .op. form is also valid), .ne. is /= (two
character representation of a slashed =).



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#110523

Dennis Lee Bieber wrote:

> ....
> but I'm sure we'd have a revolt 
> if Python comparison operators looked like:
> 
> a .eq. b
> a .ne. b
> a .gt. b .or. c .lt. d
> a .le. b .and. c .ge. d
> ....

  As someone who learned fortran in the mid 1960s
  and pounded a  lot  of fortran  code in the 1970s,
  the code above seems very readable ....


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

[toc] | [prev] | [next] | [standalone]

#110525

On 26/06/2016 16:47, Cousin Stanley wrote:
> Dennis Lee Bieber wrote:
>
>> ....
>> but I'm sure we'd have a revolt
>> if Python comparison operators looked like:
>>
>> a .eq. b
>> a .ne. b
>> a .gt. b .or. c .lt. d
>> a .le. b .and. c .ge. d
>> ....
>
>   As someone who learned fortran in the mid 1960s
>   and pounded a  lot  of fortran  code in the 1970s,
>   the code above seems very readable ....

I did a year of it in the 1970s. Looks funny in lower case though.

(Note, for those who don't know (old) Fortran, that spaces and tabs are 
not significant. So those dots are needed, otherwise "a eq b" would be 
parsed as "aeqb".)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#110544

BartC wrote:
> I did a year of it in the 1970s. Looks funny in lower case though.

It's interesting how our perceptions of such things change.
Up until my second year of university, my only experiences
of computing had all been in upper case. Then we got a
lecturer who wrote all his Pascal on the blackboard in
lower case, and it looked extremely weird. Until then the
idea of writing code in anything other than upper case
hadn't even occurred to me.

I quickly got used to it though, and nowadays, code written
in upper case looks very quaint and old-fashioned!

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#110571

On Sun, 26 Jun 2016 16:56:18 +0100, BartC <bc@freeuk.com> declaimed the
following:

>
>(Note, for those who don't know (old) Fortran, that spaces and tabs are 
>not significant. So those dots are needed, otherwise "a eq b" would be 
>parsed as "aeqb".)

	Or my favorite example of a parser headache: which is the loop
instruction and which is the assignment

	DO10I=3,14
	DO 10 I = 3.14

	Until the parser reaches the , or . it could be going down the wrong
branch and have to backtrack to the beginning of the statement to recover.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#110656

Dennis Lee Bieber wrote:
> 	Or my favorite example of a parser headache: which is the loop
> instruction and which is the assignment
> 
> 	DO10I=3,14
> 	DO 10 I = 3.14

And if the programmer and/or compiler gets it wrong,
your spacecraft crashes into the planet.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#110583

On 2016-06-26, BartC <bc@freeuk.com> wrote:

> (Note, for those who don't know (old) Fortran, that spaces and tabs are 
> not significant. So those dots are needed, otherwise "a eq b" would be 
> parsed as "aeqb".)

I've always been baffled by that.

Were there other languages that did something similar?

Why would a language designer think it a good idea?

Did the poor sod who wrote the compiler think it was a good idea?

-- 
Grant Edwards               grant.b.edwards        Yow! I left my WALLET in
                                  at               the BATHROOM!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#110586

Grant Edwards <grant.b.edwards@gmail.com>:

> On 2016-06-26, BartC <bc@freeuk.com> wrote:
>
>> (Note, for those who don't know (old) Fortran, that spaces and tabs
>> are not significant. So those dots are needed, otherwise "a eq b"
>> would be parsed as "aeqb".)
>
> I've always been baffled by that.
>
> Were there other languages that did something similar?

In XML, whitespace between tags is significant unless the document type
says otherwise. On the other hand, leading and trailing space in
attribute values is insignificant unless the document type says
otherwise.

> Why would a language designer think it a good idea?
>
> Did the poor sod who wrote the compiler think it was a good idea?

Fortran is probably not too hard to parse. XML, on the other hand, is
impossible to parse without the document type at hand. The document type
not only defines the whitespace semantics but also the availability and
meaning of the "entities" (e.g., &copy; for ©). Add namespaces to that,
and the mess is complete.


Marko

[toc] | [prev] | [next] | [standalone]

#110625

On Monday, June 27, 2016 at 7:09:35 AM UTC-7, Marko Rauhamaa wrote:
> Grant Edwards <grant.b.edwards@gmail.com>:
> 
> > On 2016-06-26, BartC <bc@freeuk.com> wrote:
> >
> >> (Note, for those who don't know (old) Fortran, that spaces and tabs
> >> are not significant. So those dots are needed, otherwise "a eq b"
> >> would be parsed as "aeqb".)
> >
> > I've always been baffled by that.
> >
> > Were there other languages that did something similar?
> 
> In XML, whitespace between tags is significant unless the document type
> says otherwise. On the other hand, leading and trailing space in
> attribute values is insignificant unless the document type says
> otherwise.
> 
> > Why would a language designer think it a good idea?
> >
> > Did the poor sod who wrote the compiler think it was a good idea?
> 
> Fortran is probably not too hard to parse. XML, on the other hand, is
> impossible to parse without the document type at hand. The document type
> not only defines the whitespace semantics but also the availability and
> meaning of the "entities" (e.g., &copy; for ©). Add namespaces to that,
> and the mess is complete.
> 
> 
> Marko

XML isn't a programming language.  I don't think it's relevant to the conversation.

[toc] | [prev] | [next] | [standalone]

#110641

sohcahtoa82@gmail.com:

> On Monday, June 27, 2016 at 7:09:35 AM UTC-7, Marko Rauhamaa wrote:
>> Grant Edwards <grant.b.edwards@gmail.com>:
>> > Were there other languages that did something similar?
>> 
>> In XML, whitespace between tags is significant unless the document type
>> says otherwise. On the other hand, leading and trailing space in
>> attribute values is insignificant unless the document type says
>> otherwise.
>> 
>> > Why would a language designer think it a good idea?
>> >
>> > Did the poor sod who wrote the compiler think it was a good idea?
>> 
>> Fortran is probably not too hard to parse. XML, on the other hand, is
>> impossible to parse without the document type at hand. The document type
>> not only defines the whitespace semantics but also the availability and
>> meaning of the "entities" (e.g., &copy; for ©). Add namespaces to that,
>> and the mess is complete.
>
> XML isn't a programming language. I don't think it's relevant to the
> conversation.

The question was about (formal) languages, not only programming
languages.

However, there are programming languages with XML syntax:

   <URL: https://en.wikipedia.org/wiki/XSLT>
   <URL: http://www.o-xml.org/spec/langspec.html>
   <URL: http://xplusplus.sourceforge.net/>


Marko

[toc] | [prev] | [next] | [standalone]

#110660

On Tuesday, June 28, 2016 at 9:55:39 AM UTC+5:30, Marko Rauhamaa wrote:
> sohcahtoa82:
> 
> > On Monday, June 27, 2016 at 7:09:35 AM UTC-7, Marko Rauhamaa wrote:
> >> Grant Edwards :
> >> > Were there other languages that did something similar?
> >> 
> >> In XML, whitespace between tags is significant unless the document type
> >> says otherwise. On the other hand, leading and trailing space in
> >> attribute values is insignificant unless the document type says
> >> otherwise.
> >> 
> >> > Why would a language designer think it a good idea?
> >> >
> >> > Did the poor sod who wrote the compiler think it was a good idea?
> >> 
> >> Fortran is probably not too hard to parse. XML, on the other hand, is
> >> impossible to parse without the document type at hand. The document type
> >> not only defines the whitespace semantics but also the availability and
> >> meaning of the "entities" (e.g., © for ©). Add namespaces to that,
> >> and the mess is complete.
> >
> > XML isn't a programming language. I don't think it's relevant to the
> > conversation.
> 
> The question was about (formal) languages, not only programming
> languages.
> 
> However, there are programming languages with XML syntax:
> 
>    <URL: https://en.wikipedia.org/wiki/XSLT>
>    <URL: http://www.o-xml.org/spec/langspec.html>
>    <URL: http://xplusplus.sourceforge.net/>

Seriously?!
You need to justify talking XML on a python list?

Which kind of 'python' this list is about?

https://www.facebook.com/nixcraft/photos/a.431194973560553.114666.126000117413375/1338469152833126/?type=3

[toc] | [prev] | [next] | [standalone]

#110587

On Monday, June 27, 2016 at 7:30:05 PM UTC+5:30, Grant Edwards wrote:
> On 2016-06-26, BartC 
> > (Note, for those who don't know (old) Fortran, that spaces and tabs are 
> > not significant. So those dots are needed, otherwise "a eq b" would be 
> > parsed as "aeqb".)
> 
> I've always been baffled by that.
> 
> Were there other languages that did something similar?
> 
> Why would a language designer think it a good idea?
> 
> Did the poor sod who wrote the compiler think it was a good idea?

I think modern ideas like lexical analysis preceding parsing
and so on came some decade after Fortran.
My guess is that Fortran was first implemented -- 'somehow or other'
Then these properties emerged -- more or less bugs that had got so entrenched
that they had to be dignified as 'features'

Analogy: Python's bool as 1½-class because bool came into python a good decade
after python and breaking old code is a bigger issue than fixing control 
constructs to be bool-strict

[toc] | [prev] | [next] | [standalone]

#110742

On Tue, 28 Jun 2016 12:10 am, Rustom Mody wrote:

> Analogy: Python's bool as 1½-class because bool came into python a good
> decade after python and breaking old code is a bigger issue than fixing
> control constructs to be bool-strict

That analogy fails because Python bools being implemented as ints is not a
bug to be fixed, but a useful feature.

There are downsides, of course, but there are also benefits. It comes down
to a matter of personal preference whether you think that bools should be
abstract True/False values or concrete 1/0 values. Neither decision is
clearly wrong, it's a matter of what you value.

Whereas some decisions are just dumb:

https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#110746

On Wed, Jun 29, 2016 at 12:35 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>
> Whereas some decisions are just dumb:
>
> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/

"""It would also be reasonable to assume that any sane language
runtime would have integers transparently degrade to BIGNUMs, making
the choice of accuracy over speed, but of course that almost never
happens..."""

Python 2 did this, but Python 3 doesn't. Does this mean that:

1) The performance advantage of native integers is negligible?
2) The performance benefit of having two representations for integers
isn't worth the complexity of one data type having two
representations?
3) The advantage of merging the types was so great that it was done in
the most straight-forward way, and then nobody got around to doing
performance testing?
4) Something else?

ChrisA

[toc] | [prev] | [next] | [standalone]

#110748

On Wednesday, June 29, 2016 at 4:20:24 PM UTC+12, Chris Angelico wrote:
>> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/
> 
> """It would also be reasonable to assume that any sane language
> runtime would have integers transparently degrade to BIGNUMs, making
> the choice of accuracy over speed, but of course that almost never
> happens..."""
> 
> Python 2 did this, but Python 3 doesn't.

Huh?

    ldo@theon:~> python3
    Python 3.5.1+ (default, Jun 10 2016, 09:03:40) 
    [GCC 5.4.0 20160603] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 2 ** 64
    18446744073709551616
    >>> type(2 ** 64)
    <class 'int'>

[toc] | [prev] | [next] | [standalone]

#110750

On Wed, Jun 29, 2016 at 2:51 PM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Wednesday, June 29, 2016 at 4:20:24 PM UTC+12, Chris Angelico wrote:
>>> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/
>>
>> """It would also be reasonable to assume that any sane language
>> runtime would have integers transparently degrade to BIGNUMs, making
>> the choice of accuracy over speed, but of course that almost never
>> happens..."""
>>
>> Python 2 did this, but Python 3 doesn't.
>
> Huh?
>
>     ldo@theon:~> python3
>     Python 3.5.1+ (default, Jun 10 2016, 09:03:40)
>     [GCC 5.4.0 20160603] on linux
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> 2 ** 64
>     18446744073709551616
>     >>> type(2 ** 64)
>     <class 'int'>

The transparent shift from machine-word to bignum is what no longer
exists. Both Py2 and Py3 will store large integers as bignums; Py2 has
two separate data types (int and long), with ints generally
outperforming longs, but Py3 simply has one (called int, but
functionally like Py2's long), and does everything with bignums.
There's no longer a boundary - instead, everything gets the "bignum
tax". How steep is that tax? I'm not sure, but microbenchmarking shows
that there definitely is one. How bad is it in real-world code? No
idea.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110753

On Wednesday, June 29, 2016 at 10:37:25 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Jun 29, 2016 at 2:51 PM, Lawrence D’Oliveiro wrote:
> > On Wednesday, June 29, 2016 at 4:20:24 PM UTC+12, Chris Angelico wrote:
> >>> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/
> >>
> >> """It would also be reasonable to assume that any sane language
> >> runtime would have integers transparently degrade to BIGNUMs, making
> >> the choice of accuracy over speed, but of course that almost never
> >> happens..."""
> >>
> >> Python 2 did this, but Python 3 doesn't.
> >
> > Huh?
> >
> >     ldo@theon:~> python3
> >     Python 3.5.1+ (default, Jun 10 2016, 09:03:40)
> >     [GCC 5.4.0 20160603] on linux
> >     Type "help", "copyright", "credits" or "license" for more information.
> >     >>> 2 ** 64
> >     18446744073709551616
> >     >>> type(2 ** 64)
> >     <class 'int'>
> 
> The transparent shift from machine-word to bignum is what no longer
> exists. Both Py2 and Py3 will store large integers as bignums; Py2 has
> two separate data types (int and long), with ints generally
> outperforming longs, but Py3 simply has one (called int, but
> functionally like Py2's long), and does everything with bignums.
> There's no longer a boundary - instead, everything gets the "bignum
> tax". How steep is that tax? I'm not sure, but microbenchmarking shows
> that there definitely is one. How bad is it in real-world code? No
> idea.
> 
> ChrisA

New to me -- thanks.
I thought it did an FSR type covert machine word → BigInt conversion under the hood.
Tax is one question
Justification for this change is another

[toc] | [prev] | [next] | [standalone]

#110755

On Wed, Jun 29, 2016 at 3:55 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> The transparent shift from machine-word to bignum is what no longer
>> exists. Both Py2 and Py3 will store large integers as bignums; Py2 has
>> two separate data types (int and long), with ints generally
>> outperforming longs, but Py3 simply has one (called int, but
>> functionally like Py2's long), and does everything with bignums.
>> There's no longer a boundary - instead, everything gets the "bignum
>> tax". How steep is that tax? I'm not sure, but microbenchmarking shows
>> that there definitely is one. How bad is it in real-world code? No
>> idea.
>>
>> ChrisA
>
> New to me -- thanks.
> I thought it did an FSR type covert machine word → BigInt conversion under the hood.
> Tax is one question
> Justification for this change is another

CPython doesn't currently do anything like that, but it would be
perfectly possible to do it invisibly, and thus stay entirely within
the language spec. I'm not aware of any Python implementation that
does this, but it wouldn't surprise me if PyPy has some magic like
that. It's PyPy's kind of thing.

It's also entirely possible that a future CPython will have this kind
of optimization too. It all depends on someone doing the
implementation work and then proving that it's worth the complexity.

ChrisA

[toc] | [prev] | [next] | [standalone]

#110756

On Wednesday, June 29, 2016 at 11:57:03 AM UTC+5:30, Chris Angelico wrote:
> On Wed, Jun 29, 2016 at 3:55 PM, Rustom Mody wrote:
> >> The transparent shift from machine-word to bignum is what no longer
> >> exists. Both Py2 and Py3 will store large integers as bignums; Py2 has
> >> two separate data types (int and long), with ints generally
> >> outperforming longs, but Py3 simply has one (called int, but
> >> functionally like Py2's long), and does everything with bignums.
> >> There's no longer a boundary - instead, everything gets the "bignum
> >> tax". How steep is that tax? I'm not sure, but microbenchmarking shows
> >> that there definitely is one. How bad is it in real-world code? No
> >> idea.
> >>
> >> ChrisA
> >
> > New to me -- thanks.
> > I thought it did an FSR type covert machine word → BigInt conversion under the hood.
> > Tax is one question
> > Justification for this change is another
> 
> CPython doesn't currently do anything like that, but it would be
> perfectly possible to do it invisibly, and thus stay entirely within
> the language spec. I'm not aware of any Python implementation that
> does this, but it wouldn't surprise me if PyPy has some magic like
> that. It's PyPy's kind of thing.
> 
> It's also entirely possible that a future CPython will have this kind
> of optimization too. It all depends on someone doing the
> implementation work and then proving that it's worth the complexity.
> 
> ChrisA

Huh? I though I was just describing python2's behavior:

$ python
Python 2.7.11+ (default, Apr 17 2016, 14:00:29) 
[GCC 5.3.1 20160413] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x=2
>>> type(x)
<type 'int'>
>>> y=x ** 80
>>> y
1208925819614629174706176L
>>> type(y)
<type 'long'>

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web