digitalmars.D - Using map instead of iteration

Russel Winder (37/37) Mar 06 2011 I have a code fragment:

Simen kjaeraas (17/43) Mar 06 2011 You should use std.range.iota(0,numberOfThreads) instead of

Russel Winder (17/34) Mar 06 2011 Thanks for this pointer.
Jonathan M Davis (7/11) Mar 06 2011 I'm sure that part of the problem is the fact that a .. b is also used i...

bearophile (8/14) Mar 06 2011 Currently it has a design bug that I've underlined.

Jonathan M Davis (8/31) Mar 06 2011 If anything, I'd argue to simply remove .. from foreach and have iota be...
Russel Winder (24/30) Mar 07 2011 the way=20

Russel Winder <russel russel.org.uk> writes:

I have a code fragment:

  auto threads =3D new Thread[numberOfThreads] ; =20
  foreach ( i ; 0 .. numberOfThreads ) {
    void delegate ( ) closedPartialSum ( ) {
      immutable id =3D i ;
      return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
    }
    threads[i] =3D new Thread ( closedPartialSum ) ;
  }

which clearly should be doable using map from std.algorithm.  So I
tried:

  auto threads =3D map ! ( function Thread ( int i ) {
      void delegate ( ) closedPartialSum ( ) {
        immutable id =3D i ;
        return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
      }
      return new Thread ( closedPartialSum ) ;
    } ) ( 0 .. numberOfThreads )

which fails:

pi_d2_threadsGlobalState.d(41): found '..' when expecting ','
pi_d2_threadsGlobalState.d(57): semicolon expected following auto
declaration, not 'foreach'

So clearly 0 .. numberOfThreads only means a range of integers in a
foreach or array index only and not everywhere as it does in all
sensible languages :-((

I am clearly missing something, anyone any ideas?

Thanks.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Mar 06 2011

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

Russel Winder <russel russel.org.uk> wrote:

 I have a code fragment:

   auto threads = new Thread[numberOfThreads] ;
   foreach ( i ; 0 .. numberOfThreads ) {
     void delegate ( ) closedPartialSum ( ) {
       immutable id = i ;
       return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
     }
     threads[i] = new Thread ( closedPartialSum ) ;
   }

 which clearly should be doable using map from std.algorithm.  So I
 tried:

   auto threads = map ! ( function Thread ( int i ) {
       void delegate ( ) closedPartialSum ( ) {
         immutable id = i ;
         return ( ) { partialSum ( id , sliceSize , delta ) ; } ;
       }
       return new Thread ( closedPartialSum ) ;
     } ) ( 0 .. numberOfThreads )

 which fails:

 pi_d2_threadsGlobalState.d(41): found '..' when expecting ','
 pi_d2_threadsGlobalState.d(57): semicolon expected following auto
 declaration, not 'foreach'

 So clearly 0 .. numberOfThreads only means a range of integers in a
 foreach or array index only and not everywhere as it does in all
 sensible languages :-((

 I am clearly missing something, anyone any ideas?

You should use std.range.iota(0,numberOfThreads) instead of
0..numberOfThreads. Having a..b return a general interval range
has been proposed numerous times, but nothing has been implemented as
of yet.

If you like syntactic sugar, this is likely the closest you'll get at
this point:

import std.range;

struct _ {
     auto opSlice(B,E)(B begin, E end) {
         return iota(begin, end);
     }
}

// Example:
map!foo( _[0..numberOfThreads] );

-- 
Simen

Mar 06 2011

Russel Winder <russel russel.org.uk> writes:

On Sun, 2011-03-06 at 14:57 +0100, Simen kjaeraas wrote:
[ . . . ]
 You should use std.range.iota(0,numberOfThreads) instead of
 0..numberOfThreads. Having a..b return a general interval range
 has been proposed numerous times, but nothing has been implemented as
 of yet.

Thanks for this pointer.

 If you like syntactic sugar, this is likely the closest you'll get at
 this point:
=20
 import std.range;
=20
 struct _ {
      auto opSlice(B,E)(B begin, E end) {
          return iota(begin, end);
      }
 }
=20
 // Example:
 map!foo( _[0..numberOfThreads] );

Interesting.  I am not sure I would do this, instead just going with the
explicit iota.

It would be better though if x..y (and x..<y) were standard parts of the
syntax.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Mar 06 2011

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Sunday 06 March 2011 05:57:12 Simen kjaeraas wrote:
 You should use std.range.iota(0,numberOfThreads) instead of
 0..numberOfThreads. Having a..b return a general interval range
 has been proposed numerous times, but nothing has been implemented as
 of yet.

I'm sure that part of the problem is the fact that a .. b is also used in 
slicing, where it does not mean the same thing - that and iota works just fine, 
and increasingly, Andrei and Walter seem to prefer having stuff in the library 
rather than the language itself when there's no significant gain to be had by 
putting it in the language.

- Jonathan M Davis

Mar 06 2011

bearophile <bearophileHUGS lycos.com> writes:

Jonathan M Davis:

 I'm sure that part of the problem is the fact that a .. b is also used in 
 slicing, where it does not mean the same thing

It means the same thing, with a interval literal.


 - that and iota works just fine, 

Currently it has a design bug that I've underlined.


 and increasingly, Andrei and Walter seem to prefer having stuff in the library 
 rather than the language itself when there's no significant gain to be had by 
 putting it in the language.

The gain is simplifying the language, removing the special cased syntax of
foreach and switch and opSlice, and more, and replacing them with something
more general, more polished and generic, that allows more usages and more
runtime efficiency. This makes D look less like a pile of special cases and
more like a designed language. So you are quite off-mark.

See my recent answer:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=131378

Bye,
bearophile

Mar 06 2011

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Sunday 06 March 2011 17:20:33 bearophile wrote:
 Jonathan M Davis:
 I'm sure that part of the problem is the fact that a .. b is also used in
 slicing, where it does not mean the same thing

 
 It means the same thing, with a interval literal.
 
 - that and iota works just fine,

 
 Currently it has a design bug that I've underlined.
 
 and increasingly, Andrei and Walter seem to prefer having stuff in the
 library rather than the language itself when there's no significant gain
 to be had by putting it in the language.

 
 The gain is simplifying the language, removing the special cased syntax of
 foreach and switch and opSlice, and more, and replacing them with
 something more general, more polished and generic, that allows more usages
 and more runtime efficiency. This makes D look less like a pile of special
 cases and more like a designed language. So you are quite off-mark.
 
 See my recent answer:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&a
 rticle_id=131378

If anything, I'd argue to simply remove .. from foreach and have iota be the
way 
to do it. The only other inconsistency is with case statements, but making them 
have an open right end would likely be problematic (not to mention break tons
of 
code), whereas an open right end is exactly what it should be in the general 
case. I really don't see the problem other than the fact that using .. in 
foreach is completely redundant at this point, since we have iota.

- Jonathan M Davis

Mar 06 2011

Russel Winder <russel russel.org.uk> writes:

On Sun, 2011-03-06 at 17:41 -0800, Jonathan M Davis wrote:
[ . . . ]
 If anything, I'd argue to simply remove .. from foreach and have iota be =

the way=20
 to do it. The only other inconsistency is with case statements, but makin=

g them=20
 have an open right end would likely be problematic (not to mention break =

tons of=20
 code), whereas an open right end is exactly what it should be in the gene=

ral=20
 case. I really don't see the problem other than the fact that using .. in=

=20
 foreach is completely redundant at this point, since we have iota.

If .. is not going to mean a range of values everywhere then it should
be allowed nowhere.  This includes array slicing as well as foreach.
Having a special case that leads people to try and use it as the general
case is the worst of all worlds.

Case labels will be the problem.

range in Python is a range that is inclusive at the beginning and
exclusive at the end, there are no special cases.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Mar 07 2011

D Programming

C/C++ Programming

Other

digitalmars.D - Using map instead of iteration