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

"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

"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

"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]
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"

    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

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
> 
> 

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
>>
>>
> 

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).
hmmm... "usable" ?
> 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