www.digitalmars.com         C & C++   DMDScript  

D - Newbie.. Slicing

reply Zev Griner <Zev_member pathlink.com> writes:
Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Talk about bug-prone!!

Here I am looking at two numbers and I am supposed to remember that 'n' is to be
ignored. It's bad enough that C arrays, defined as [n], are accessed as 0 <= i <
n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner
Feb 02 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n] was
 defined as m <= i < n as opposed m <= i <= n?

 Talk about bug-prone!!

 Here I am looking at two numbers and I am supposed to remember that 'n' is

 ignored. It's bad enough that C arrays, defined as [n], are accessed as 0

 n. I don't see why that concept has to be promulgated to slicing. The ..
 operator should be the clue that slicing gives you the elements within the
 boundaries, inclusively.

 Thanx
 Zev Griner

Hi, The discussion about slices and ranges never dies around here ;-) There's are a couple of simple answers to this. First is that D has its origins on C, and in C every loop on arrays goes from 0 <= i < n, as you said, so in D a code to manually slice an array would use this notation. If the notation for slices were different people would always remember that slicing is inclusive in both ends, while common array loop is inclusive/exclusive. But the most important reason is that using this notation we can express empty slices without trouble. Writing "someArray[0 .. 0]" is always right, giving a empty array. When you write functions that slice arrays you usually have to deal with this problem, and if the default slicing is inclusive/exclusive you don't need to write tests to check for the empty slice case. The only language I know that use both ends inclusive notation and is useable is Icon, but their array indices are different (they happen between array slots, so 1..3 means before first and before third elements). The inclusive/exclusive notation is common in other languages (Java and Python use it). I agree that some people will be surprised by this, but they'll get used to this start/after end definition. If I defined this, I would prefer a start/length notation instead, because most of the time I write "someArray[n .. n + x]" instead of "someArray[n .. m]". Best regards, Daniel Yokomiso. "Being right too soon is socially unacceptable." - Robert A. Heinlein --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 02 2003
next sibling parent reply Antti Sykari <jsykari gamma.hut.fi> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n] was
 defined as m <= i < n as opposed m <= i <= n?


     The discussion about slices and ranges never dies around here ;-)

True :) A very religious issue. It seems that the notation x..y will cause bugs either way, if half of the people assume it means inclusive, and half of the people assume it's exclusive.
     There's are a couple of simple answers to this. First is that D
 has its origins on C, and in C every loop on arrays goes from 0 <= i
 < n, as you said, so in D a code to manually slice an array would
 use this notation.

One might ask: why not ditch the C(++) practice and use 0 <= i <= n, because, after all, that would be symmetric? Low-level efficiency concerns?
 the empty slice case. The only language I know that use both ends inclusive
 notation and is useable is Icon, but their array indices are different (they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).

I don't know what you consider a *useable* language :) However, of the languages of I know, perl, zsh and ruby have x..y in the meaning of "x through y inclusive" Non-inclusive ranges are needed, too, so ruby has solved the problem by introducing a "..." operator: 0 ... n means 0, 1, .., n-1. -Antti
Feb 02 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Antti Sykari" <jsykari gamma.hut.fi> escreveu na mensagem
news:86bs1tj3vm.fsf hoastest1-8c.hoasnet.inet.fi...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n]



 defined as m <= i < n as opposed m <= i <= n?


     The discussion about slices and ranges never dies around here ;-)

True :) A very religious issue. It seems that the notation x..y will cause bugs either way, if half of the people assume it means inclusive, and half of the people assume it's exclusive.
     There's are a couple of simple answers to this. First is that D
 has its origins on C, and in C every loop on arrays goes from 0 <= i
 < n, as you said, so in D a code to manually slice an array would
 use this notation.

One might ask: why not ditch the C(++) practice and use 0 <= i <= n, because, after all, that would be symmetric? Low-level efficiency concerns?
 the empty slice case. The only language I know that use both ends


 notation and is useable is Icon, but their array indices are different


 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).

I don't know what you consider a *useable* language :) However, of the languages of I know, perl, zsh and ruby have x..y in the meaning of "x through y inclusive"

The range notation for slicing isn't perfect, I think that using ":" a la Python would be better. But the rationale for the idiom is clear, and if we need one IMHO this is the best. Ruby has three forms of slicing IIRC "someArray[start, count]", "someArray[start .. end]" and "someArray[start ... afterEnd]", so they don't have this problem, but also don't have an unique notation.
 Non-inclusive ranges are needed, too, so ruby has solved the problem
 by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

 -Antti

--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 03 2003
prev sibling parent xyzzy <xyzzy adventure.com> writes:
On Mon, 03 Feb 2003 08:05:17 +0200, Antti Sykari <jsykari gamma.hut.fi> 
wrote:

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 Can someone point me to a discussion that explains why slicing [m..n] 
 was
 defined as m <= i < n as opposed m <= i <= n?


 The discussion about slices and ranges never dies around here ;-)

True :) A very religious issue. It seems that the notation x..y will cause bugs either way, if half of the people assume it means inclusive, and half of the people assume it's exclusive.

It really is too hard, isn't it. If a language has inclusive slices, to get a non-inclusive you do... [x..y-1] If a language has non-inclusive slices, to get an inclusive you do ... [x..y+1]
 There's are a couple of simple answers to this. First is that D
 has its origins on C, and in C every loop on arrays goes from 0 <= i
 < n, as you said, so in D a code to manually slice an array would
 use this notation.

One might ask: why not ditch the C(++) practice and use 0 <= i <= n, because, after all, that would be symmetric? Low-level efficiency concerns?

Or even 1 <= i <= n, if you want to get away from techo-thinking,
 the empty slice case. The only language I know that use both ends 
 inclusive
 notation and is useable is Icon, but their array indices are different 
 (they
 happen between array slots, so 1..3 means before first and before third
 elements). The inclusive/exclusive notation is common in other languages
 (Java and Python use it).


 I don't know what you consider a *useable* language :) However, of the
 languages of I know, perl, zsh and ruby have x..y in the meaning of "x
 through y inclusive"

 Non-inclusive ranges are needed, too, so ruby has solved the problem
 by introducing a "..." operator: 0 ... n means 0, 1, .., n-1.

And of course, no-one would accidently misread or miscode an extra '.', would they? -- xyzzy
Feb 04 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
If slicing is made inclusive (Delphi!), you could use [..] to express an 
empty slice ;)


Daniel Yokomiso wrote:
 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...
 
Can someone point me to a discussion that explains why slicing [m..n] was
defined as m <= i < n as opposed m <= i <= n?

Talk about bug-prone!!

Here I am looking at two numbers and I am supposed to remember that 'n' is

to be
ignored. It's bad enough that C arrays, defined as [n], are accessed as 0

<= i <
n. I don't see why that concept has to be promulgated to slicing. The ..
operator should be the clue that slicing gives you the elements within the
boundaries, inclusively.

Thanx
Zev Griner

Hi, The discussion about slices and ranges never dies around here ;-) There's are a couple of simple answers to this. First is that D has its origins on C, and in C every loop on arrays goes from 0 <= i < n, as you said, so in D a code to manually slice an array would use this notation. If the notation for slices were different people would always remember that slicing is inclusive in both ends, while common array loop is inclusive/exclusive. But the most important reason is that using this notation we can express empty slices without trouble. Writing "someArray[0 .. 0]" is always right, giving a empty array. When you write functions that slice arrays you usually have to deal with this problem, and if the default slicing is inclusive/exclusive you don't need to write tests to check for the empty slice case. The only language I know that use both ends inclusive notation and is useable is Icon, but their array indices are different (they happen between array slots, so 1..3 means before first and before third elements). The inclusive/exclusive notation is common in other languages (Java and Python use it). I agree that some people will be surprised by this, but they'll get used to this start/after end definition. If I defined this, I would prefer a start/length notation instead, because most of the time I write "someArray[n .. n + x]" instead of "someArray[n .. m]". Best regards, Daniel Yokomiso. "Being right too soon is socially unacceptable." - Robert A. Heinlein --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

Feb 04 2003
parent Ilya Minkov <midiclub 8ung.at> writes:
Oh, sorry. Now i was reading more carefully. Sure, D makes it the right 
way, i beleve...

Ilya Minkov wrote:
 If slicing is made inclusive (Delphi!), you could use [..] to express an 
 empty slice ;)
 
 
 Daniel Yokomiso wrote:
 
 "Zev Griner" <Zev_member pathlink.com> escreveu na mensagem
 news:b1j2vp$r4j$1 digitaldaemon.com...

 Can someone point me to a discussion that explains why slicing [m..n] 
 was
 defined as m <= i < n as opposed m <= i <= n?

 Talk about bug-prone!!

 Here I am looking at two numbers and I am supposed to remember that 
 'n' is

to be
 ignored. It's bad enough that C arrays, defined as [n], are accessed 
 as 0

<= i <
 n. I don't see why that concept has to be promulgated to slicing. The ..
 operator should be the clue that slicing gives you the elements 
 within the
 boundaries, inclusively.

 Thanx
 Zev Griner

Hi, The discussion about slices and ranges never dies around here ;-) There's are a couple of simple answers to this. First is that D has its origins on C, and in C every loop on arrays goes from 0 <= i < n, as you said, so in D a code to manually slice an array would use this notation. If the notation for slices were different people would always remember that slicing is inclusive in both ends, while common array loop is inclusive/exclusive. But the most important reason is that using this notation we can express empty slices without trouble. Writing "someArray[0 .. 0]" is always right, giving a empty array. When you write functions that slice arrays you usually have to deal with this problem, and if the default slicing is inclusive/exclusive you don't need to write tests to check for the empty slice case. The only language I know that use both ends inclusive notation and is useable is Icon, but their array indices are different (they happen between array slots, so 1..3 means before first and before third elements). The inclusive/exclusive notation is common in other languages (Java and Python use it). I agree that some people will be surprised by this, but they'll get used to this start/after end definition. If I defined this, I would prefer a start/length notation instead, because most of the time I write "someArray[n .. n + x]" instead of "someArray[n .. m]". Best regards, Daniel Yokomiso. "Being right too soon is socially unacceptable." - Robert A. Heinlein --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003


Feb 04 2003