a = b = c order of evaluation weird

Discussion in 'Ruby' started by SpringFlowers AutumnMoon, Oct 2, 2007.

  1. i thought if it is

    a = b = c

    due to associativity rule, then it is

    a = (b = c)

    so (b = c) is evaluated first. and then now it will be a =
    (evaluated_value)

    now how come when

    a = Array(1..100)

    and to cut off the first 1/3 and last 1/3 of the array to get about 33
    elements, shouldn't we use

    a[0..a.size/2] = a[a.size*2/3..-1] = nil

    as after the last 1/3 is deleted, you got about 66 elements remaining
    and we want the other half deleted, to get to 33 elements. However, it
    won't work and requires

    a[0..a.size/3] = a[a.size*2/3..-1] = nil

    why is that?
    --
    Posted via http://www.ruby-forum.com/.
     
    SpringFlowers AutumnMoon, Oct 2, 2007
    #1
    1. Advertising

  2. SpringFlowers AutumnMoon

    7stud -- Guest

    SpringFlowers AutumnMoon wrote:
    >
    > why is that?
    >


    a = Array(1..6)
    p a

    puts "size: #{a.size/3}"
    a[p(0..a.size/3)] = a[p(a.size*2/3..-1)] = nil



    --
    Posted via http://www.ruby-forum.com/.
     
    7stud --, Oct 2, 2007
    #2
    1. Advertising

  3. SpringFlowers AutumnMoon

    7stud -- Guest

    7stud -- wrote:
    > SpringFlowers AutumnMoon wrote:
    >>
    >> why is that?


    Or even simpler:

    a = Array(1..6)

    a[puts "hello"] = a[puts "world"] = nil
    --
    Posted via http://www.ruby-forum.com/.
     
    7stud --, Oct 2, 2007
    #3
  4. Hi --

    On Tue, 2 Oct 2007, 7stud -- wrote:

    > SpringFlowers AutumnMoon wrote:
    >>
    >> why is that?
    >>

    >
    > a = Array(1..6)
    > p a
    >
    > puts "size: #{a.size/3}"
    > a[p(0..a.size/3)] = a[p(a.size*2/3..-1)] = nil


    Have you tried to run that? :)


    David

    --
    Upcoming training from Ruby Power and Light, LLC:
    * Intro to Ruby on Rails, Edison, NJ, October 23-26
    * Advancing with Rails, Edison, NJ, November 6-9
    Both taught by David A. Black.
    See http://www.rubypal.com for more info!
     
    David A. Black, Oct 2, 2007
    #4
  5. On Tue, 2 Oct 2007, 7stud -- wrote:

    > 7stud -- wrote:
    >> SpringFlowers AutumnMoon wrote:
    >>>
    >>> why is that?

    >
    > Or even simpler:
    >
    > a = Array(1..6)
    >
    > a[puts "hello"] = a[puts "world"] = nil


    puts returns nil, and you can't index an array with nil.


    David

    --
    Upcoming training from Ruby Power and Light, LLC:
    * Intro to Ruby on Rails, Edison, NJ, October 23-26
    * Advancing with Rails, Edison, NJ, November 6-9
    Both taught by David A. Black.
    See http://www.rubypal.com for more info!
     
    David A. Black, Oct 2, 2007
    #5
  6. Hi --

    On Tue, 2 Oct 2007, SpringFlowers AutumnMoon wrote:

    > i thought if it is
    >
    > a = b = c
    >
    > due to associativity rule, then it is
    >
    > a = (b = c)
    >
    > so (b = c) is evaluated first. and then now it will be a =
    > (evaluated_value)
    >
    > now how come when
    >
    > a = Array(1..100)
    >
    > and to cut off the first 1/3 and last 1/3 of the array to get about 33
    > elements, shouldn't we use
    >
    > a[0..a.size/2] = a[a.size*2/3..-1] = nil
    >
    > as after the last 1/3 is deleted, you got about 66 elements remaining
    > and we want the other half deleted, to get to 33 elements. However, it
    > won't work and requires
    >
    > a[0..a.size/3] = a[a.size*2/3..-1] = nil
    >
    > why is that?


    Although the = associates to the right, the subscript expressions are
    evaluated first. So you're really doing:

    a[0..50] = a[66..-1] = nil


    David

    --
    Upcoming training from Ruby Power and Light, LLC:
    * Intro to Ruby on Rails, Edison, NJ, October 23-26
    * Advancing with Rails, Edison, NJ, November 6-9
    Both taught by David A. Black.
    See http://www.rubypal.com for more info!
     
    David A. Black, Oct 2, 2007
    #6
  7. SpringFlowers AutumnMoon

    Chris Bailey Guest

    Variable scope in GServer

    I'm having a bit of a problem accessing variables in an instance of GServer.
    What I would like to do is make a hash that is effectively global to the
    current thread.

    -/Server.rb
    require 'gserver'
    require 'connect.rb'

    class TestServer < GServer
    def initialize(port = 4000, *args)
    super(port, *args)
    end
    def serve( io )
    @test_hash = Hash.new
    connect(io) #Defined in connect.rb
    loop do
    str = io.gets
    parser(str,io)
    end
    end
    end

    The way that I'm doing it doesn't allow each thread to have it's own copy of
    @test_hash and that's my problem. I need each thread to be able to change
    the data stored in the hash without affecting the data stored in the hash
    for all threads. I'm sure that my understanding of scope and GServer itself
    is causing my problem, but I just don't know what to do to fix it. I was
    thinking that I could pass the hash as a parameter to the connect function
    but that would quickly become a problem as it would need to be passed to
    several other functions after that and if possible I just don't want to have
    to use that many extra parameters in my functions. Any help would be
    appreciated.
     
    Chris Bailey, Oct 2, 2007
    #7
  8. Re: Variable scope in GServer

    Hi,

    Am Dienstag, 02. Okt 2007, 19:25:07 +0900 schrieb Chris Bailey:
    > I'm having a bit of a problem [...]


    Please have a look where your message appears when you just
    hit the "Reply" button:

    <http://news.gmane.org/gmane.comp.lang.ruby.general/cutoff=229420>

    Bertram


    --
    Bertram Scharpf
    Stuttgart, Deutschland/Germany
    http://www.bertram-scharpf.de
     
    Bertram Scharpf, Oct 2, 2007
    #8
  9. SpringFlowers AutumnMoon

    7stud -- Guest

    David A. Black wrote:
    > On Tue, 2 Oct 2007, 7stud -- wrote:
    >
    >> 7stud -- wrote:
    >>> SpringFlowers AutumnMoon wrote:
    >>>>
    >>>> why is that?

    >>
    >> Or even simpler:
    >>
    >> a = Array(1..6)
    >>
    >> a[puts "hello"] = a[puts "world"] = nil

    >
    > puts returns nil, and you can't index an array with nil.
    >
    >


    Yes, I know, but that isn't the point of the example. The output
    provides the answer to the question.
    --
    Posted via http://www.ruby-forum.com/.
     
    7stud --, Oct 2, 2007
    #9
  10. SpringFlowers AutumnMoon

    7stud -- Guest

    7stud -- wrote:
    >>>
    >>> a[puts "hello"] = a[puts "world"] = nil

    >>
    >> puts returns nil, and you can't index an array with nil.
    >>


    How's this:

    a = Array(1..6)

    a[(puts "hello", 0..a.size/2;0..a.size/2)] = a[(puts "world",
    a.size*2/3..1;a.size*2/3..1)] = nil
    p a


    --
    Posted via http://www.ruby-forum.com/.
     
    7stud --, Oct 2, 2007
    #10
  11. SpringFlowers AutumnMoon

    Calamitas Guest

    Re: a = b = c order of evaluation weird

    On 02/10/2007, 7stud -- <> wrote:
    > David A. Black wrote:
    > > On Tue, 2 Oct 2007, 7stud -- wrote:
    > >
    > >> 7stud -- wrote:
    > >>> SpringFlowers AutumnMoon wrote:
    > >>>>
    > >>>> why is that?
    > >>
    > >> Or even simpler:
    > >>
    > >> a = Array(1..6)
    > >>
    > >> a[puts "hello"] = a[puts "world"] = nil

    > >
    > > puts returns nil, and you can't index an array with nil.
    > >
    > >

    >
    > Yes, I know, but that isn't the point of the example. The output
    > provides the answer to the question.


    My impression was that the OP knew what the evaluation order is, but
    not why it is like that.

    But anyway, my take on this is that

    a[0..a.size/2] = a[a.size*2/3..-1] = nil

    is equivalent to:

    a.[]=(0..a.size/2, a.[]=(a.size*2/3..-1, nil))

    Arguments are evaluated left to right, completely explaining the
    evaluation order the OP is seeing.

    Peter
     
    Calamitas, Oct 2, 2007
    #11
  12. Re: a = b = c order of evaluation weird

    --HLsZ5Z1opAQvdr2J
    Content-Type: text/plain; charset=us-ascii
    Content-Disposition: inline
    Content-Transfer-Encoding: quoted-printable

    On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
    > My impression was that the OP knew what the evaluation order is, but
    > not why it is like that.
    >=20
    > But anyway, my take on this is that
    >=20
    > a[0..a.size/2] =3D a[a.size*2/3..-1] =3D nil
    >=20
    > is equivalent to:
    >=20
    > a.[]=3D(0..a.size/2, a.[]=3D(a.size*2/3..-1, nil))
    >=20
    > Arguments are evaluated left to right, completely explaining the
    > evaluation order the OP is seeing.


    I guess it's safer to say that the order of evaluating arguments is
    undefined, unless it is stated somewhere.

    Is it defined for ruby?

    --=20
    A thousand words are worth a picture, and they load a heck of a lot faster.

    --HLsZ5Z1opAQvdr2J
    Content-Type: application/pgp-signature
    Content-Disposition: inline

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)

    iD8DBQFHAjj+snU0scoWZKARAoc1AJ0RFUcxRWBIrLP/LJDIT6eCbjnOCwCfRFiJ
    EZNHB9Dy1eJMU48QT7BFhZs=
    =PoQK
    -----END PGP SIGNATURE-----

    --HLsZ5Z1opAQvdr2J--
     
    Mariusz Pękala, Oct 2, 2007
    #12
  13. Re: a = b = c order of evaluation weird

    --1926193751-378101879-1191331521=:14474
    Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-378101879-1191331521=:14474"

    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    --1926193751-378101879-1191331521=:14474
    Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
    Content-Transfer-Encoding: QUOTED-PRINTABLE

    Hi --

    On Tue, 2 Oct 2007, Mariusz P=C4~Ykala wrote:

    > On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
    >> My impression was that the OP knew what the evaluation order is, but
    >> not why it is like that.
    >>
    >> But anyway, my take on this is that
    >>
    >> a[0..a.size/2] =3D a[a.size*2/3..-1] =3D nil
    >>
    >> is equivalent to:
    >>
    >> a.[]=3D(0..a.size/2, a.[]=3D(a.size*2/3..-1, nil))
    >>
    >> Arguments are evaluated left to right, completely explaining the
    >> evaluation order the OP is seeing.

    >
    > I guess it's safer to say that the order of evaluating arguments is
    > undefined, unless it is stated somewhere.
    >
    > Is it defined for ruby?


    I believe that a subscript expression is always going to be evaluated
    first:

    irb(main):001:0> a =3D [1,2,3,4,5]
    =3D> [1, 2, 3, 4, 5]
    irb(main):002:0> b =3D 1
    =3D> 1
    irb(main):003:0> a =3D (b =3D 10)
    =3D> 10
    irb(main):004:0> a
    =3D> [1, 10, 3, 4, 5]


    David

    --=20
    Upcoming training from Ruby Power and Light, LLC:
    * Intro to Ruby on Rails, Edison, NJ, October 23-26
    * Advancing with Rails, Edison, NJ, November 6-9
    Both taught by David A. Black.
    See http://www.rubypal.com for more info!
    --1926193751-378101879-1191331521=:14474--
    --1926193751-378101879-1191331521=:14474--
     
    David A. Black, Oct 2, 2007
    #13
  14. SpringFlowers AutumnMoon

    Guest

    Re: a = b = c order of evaluation weird

    On 10/2/07, SpringFlowers AutumnMoon <> wrote:
    >
    > a = Array(1..100)
    >
    > a[0..a.size/2] = a[a.size*2/3..-1] = nil
    >
    > won't work and requires
    >
    > why is that?


    a = Array(1..100)
    a[0..a.size/2] = a[a.size*2/3..-1] = nil
    p a

    a = Array(1..100)

    a.[]=(
    0..(a.size)./(2),
    a.[]=(
    (((a.size).*(2))./(3))..-1, nil
    )
    )

    p a
     
    , Oct 2, 2007
    #14
  15. Re: a = b = c order of evaluation weird

    Hi,

    Am Dienstag, 02. Okt 2007, 22:25:26 +0900 schrieb David A. Black:
    > This message is in MIME format. The first part should be readable text,
    > while the remaining parts are likely unreadable without MIME-aware tool=

    s.
    > On Tue, 2 Oct 2007, Mariusz P=C4~Ykala wrote:
    >> On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
    >>> My impression was that the OP knew what the evaluation order is, but
    >>> not why it is like that.

    >>
    >> I guess it's safer to say that the order of evaluating arguments is
    >> undefined, unless it is stated somewhere.
    >>
    >> Is it defined for ruby?

    >
    > I believe that a subscript expression is always going to be evaluated
    > first:


    I never found it's good programming practice in any language
    to rely on evaluation order of function/method arguments.
    Understanding your own code will become unneccessarily hard.

    Bertram


    --=20
    Bertram Scharpf
    Stuttgart, Deutschland/Germany
    http://www.bertram-scharpf.de
     
    Bertram Scharpf, Oct 2, 2007
    #15
  16. Re: a = b = c order of evaluation weird

    --1926193751-454653753-1191334354=:15525
    Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-454653753-1191334354=:15525"

    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    --1926193751-454653753-1191334354=:15525
    Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
    Content-Transfer-Encoding: QUOTED-PRINTABLE

    Hi --

    On Tue, 2 Oct 2007, Bertram Scharpf wrote:

    > Hi,
    >
    > Am Dienstag, 02. Okt 2007, 22:25:26 +0900 schrieb David A. Black:
    >> This message is in MIME format. The first part should be readable tex=

    t,
    >> while the remaining parts are likely unreadable without MIME-aware too=

    ls.
    >> On Tue, 2 Oct 2007, Mariusz P=C4~Ykala wrote:
    >>> On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
    >>>> My impression was that the OP knew what the evaluation order is, but
    >>>> not why it is like that.
    >>>
    >>> I guess it's safer to say that the order of evaluating arguments is
    >>> undefined, unless it is stated somewhere.
    >>>
    >>> Is it defined for ruby?

    >>
    >> I believe that a subscript expression is always going to be evaluated
    >> first:

    >
    > I never found it's good programming practice in any language
    > to rely on evaluation order of function/method arguments.
    > Understanding your own code will become unneccessarily hard.


    I wouldn't go out of my way to do tricks involving evaluation order,
    but I certainly advocate understanding what's going to happen under
    what circumstances.


    David

    --=20
    Upcoming training from Ruby Power and Light, LLC:
    * Intro to Ruby on Rails, Edison, NJ, October 23-26
    * Advancing with Rails, Edison, NJ, November 6-9
    Both taught by David A. Black.
    See http://www.rubypal.com for more info!
    --1926193751-454653753-1191334354=:15525--
    --1926193751-454653753-1191334354=:15525--
     
    David A. Black, Oct 2, 2007
    #16
  17. SpringFlowers AutumnMoon

    7stud -- Guest

    Re: a = b = c order of evaluation weird

    David A. Black wrote:
    >
    > I believe that a subscript expression is always going to be evaluated
    > first:
    >
    > irb(main):001:0> a = [1,2,3,4,5]
    > => [1, 2, 3, 4, 5]
    > irb(main):002:0> b = 1
    > => 1
    > irb(main):003:0> a = (b = 10)
    > => 10
    > irb(main):004:0> a
    > => [1, 10, 3, 4, 5]
    >


    I think you missed Mariusz Pękala's point:

    Mariusz Pękala wrote:
    > On 2007-10-02 21:06:32 +0900 (Tue, Oct), Calamitas wrote:
    >>
    >> Arguments are evaluated left to right, completely explaining the
    >> evaluation order the OP is seeing.

    >


    I guess it's safer to say that the order of evaluating arguments is
    undefined, unless it is stated somewhere.

    Is it defined for ruby?
    ----------

    In other words, I think Mariusz was pointing out that, yes the subscript
    expressions are evaluated before the assignments, but does that
    necessarily mean the subscript expressions are guaranteed to be
    evaluated left to right. Since your example only has one subscript
    expression, it doesn't shed any light on that issue.

    --
    Posted via http://www.ruby-forum.com/.
     
    7stud --, Oct 2, 2007
    #17
  18. Arlen Christian Mart Cuss wrote:
    >> and to cut off the first 1/3 and last 1/3 of the array to get about 33
    >> elements, shouldn't we use
    >>
    >> a[0..a.size/2] = a[a.size*2/3..-1] = nil

    >
    > Or, just do a.slice!(a.size/3..a.size*2/3)


    there are so many people who are familiar with Ruby. Have been using
    Ruby for a long time? Do you find after using Ruby, a work day becomes
    a fun day?

    --
    Posted via http://www.ruby-forum.com/.
     
    SpringFlowers AutumnMoon, Oct 2, 2007
    #18
  19. SpringFlowers AutumnMoon

    7stud -- Guest

    Re: a = b = c order of evaluation weird

    Arlen Christian Mart Cuss wrote:
    > On Tue, 2007-10-02 at 23:25 +0900, 7stud -- wrote:
    >> Since your example only has one subscript
    >> expression, it doesn't shed any light on that issue.

    >
    > It demonstrates, at least, that one subscript op is evaluated
    > left-to-right, thus we expect all of them to be so.


    How do you know the subscript expression wasn't evaluated from right to
    left?
    --
    Posted via http://www.ruby-forum.com/.
     
    7stud --, Oct 2, 2007
    #19
  20. SpringFlowers AutumnMoon

    F. Senault Guest

    Re: a = b = c order of evaluation weird

    Le 02 octobre à 18:23, 7stud -- a écrit :

    > Arlen Christian Mart Cuss wrote:
    >> On Tue, 2007-10-02 at 23:25 +0900, 7stud -- wrote:
    >>> Since your example only has one subscript
    >>> expression, it doesn't shed any light on that issue.

    >>
    >> It demonstrates, at least, that one subscript op is evaluated
    >> left-to-right, thus we expect all of them to be so.

    >
    > How do you know the subscript expression wasn't evaluated from right to
    > left?


    You can play with set_trace_func :

    20:16 fred@vodka:~/ruby> cat toto.rb
    #! /usr/local/bin/ruby

    a = Array(1..100)

    set_trace_func proc { |e,f,l,i,b,c|
    printf "%8s %s:%-2d %10s %8s\n",e,f,l,i,c if e == 'c-call'
    }

    a[0..a.size/2] \
    = \
    a[a.size*2/3..-1] \
    = \
    nil

    20:16 fred@vodka:~/ruby> ruby toto.rb
    c-call toto.rb:9 size Array
    c-call toto.rb:9 / Fixnum
    c-call toto.rb:11 size Array
    c-call toto.rb:11 * Fixnum
    c-call toto.rb:11 / Fixnum
    c-call toto.rb:12 []= Array
    c-call toto.rb:10 []= Array

    (I didn't expect the real line numbers, by the way. Cooool !)

    Fred
    --
    Now that I think about it, having a (dense) group of Marketeers and
    Salesweasels play russian roulette with, say, an 88 Flak would be better
    than handing one of them an M1911 and convincing them that their odds
    are better than with a revolver. (Matt Olson in ATSR)
     
    F. Senault, Oct 2, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dejan budimir
    Replies:
    6
    Views:
    374
    Rolf Magnus
    Jul 4, 2004
  2. Prateek R Karandikar
    Replies:
    11
    Views:
    589
  3. Ilias Lazaridis
    Replies:
    2
    Views:
    393
    Ilias Lazaridis
    Apr 24, 2005
  4. Ilias Lazaridis
    Replies:
    74
    Views:
    764
    Ilias Lazaridis
    Apr 4, 2005
  5. Ilias Lazaridis
    Replies:
    18
    Views:
    335
    Bill Guindon
    Apr 9, 2005
Loading...

Share This Page