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

Groups > comp.lang.java.programmer > #39029 > unrolled thread

Inclusive or exclusive array

Back to article view | Back to comp.lang.java.programmer

Contents

  Inclusive or exclusive array Cecil Westerhof <Cecil@decebal.nl> - 2019-07-30 18:24 +0200
    Re: Inclusive or exclusive array Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-07-30 12:52 -0400
      Re: Inclusive or exclusive array Cecil Westerhof <Cecil@decebal.nl> - 2019-07-30 20:41 +0200
        Re: Inclusive or exclusive array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-07-31 02:19 +0200
          Re: Inclusive or exclusive array Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-07-31 07:22 -0400
            Re: Inclusive or exclusive array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-08-01 00:44 +0200
            Re: Inclusive or exclusive array Andreas Leitgeb <avl@logic.at> - 2019-08-01 08:02 +0000
              Re: Inclusive or exclusive array Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-01 07:47 -0400
                Re: Inclusive or exclusive array Arne Vajhøj <arne@vajhoej.dk> - 2019-08-01 11:19 -0400
                  Re: Inclusive or exclusive array Eric Douglas <e.d.programmer@gmail.com> - 2019-08-01 10:04 -0700
                    Re: Inclusive or exclusive array nobody@example.org (Scott) - 2019-08-02 17:51 +0000
                      Re: Inclusive or exclusive array Eric Douglas <e.d.programmer@gmail.com> - 2019-08-02 10:58 -0700
                        Re: Inclusive or exclusive array nobody@example.org (Scott) - 2019-08-03 05:40 +0000
                          Re: Inclusive or exclusive array Arne Vajhøj <arne@vajhoej.dk> - 2019-08-03 21:32 -0400
                          Re: Inclusive or exclusive array Eric Douglas <e.d.programmer@gmail.com> - 2019-08-05 05:04 -0700
                            Re: Inclusive or exclusive array Arne Vajhøj <arne@vajhoej.dk> - 2019-08-05 19:30 -0400
                  Re: Inclusive or exclusive array Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-01 14:20 -0400
                    Re: Inclusive or exclusive array Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2019-08-02 01:15 +0200
                      Re: Inclusive or exclusive array Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-08-02 16:17 -0400
      IntStream.rangeClosed()   (was: Re: Inclusive or exclusive array) Andreas Leitgeb <avl@logic.at> - 2019-07-31 11:33 +0000
        Re: IntStream.rangeClosed() Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-07-31 07:59 -0400
          Re: IntStream.rangeClosed() Eric Douglas <e.d.programmer@gmail.com> - 2019-07-31 05:40 -0700
            Re: IntStream.rangeClosed() Eric Sosman <esosman@comcast-dot-net.invalid> - 2019-07-31 11:02 -0400
              Re: IntStream.rangeClosed() Eric Douglas <e.d.programmer@gmail.com> - 2019-07-31 08:39 -0700
          Re: IntStream.rangeClosed() Martin Gregorie <martin@mydomain.invalid> - 2019-07-31 16:46 +0000
            Re: IntStream.rangeClosed() Eric Douglas <e.d.programmer@gmail.com> - 2019-07-31 10:16 -0700
    Re: Inclusive or exclusive array Marcel Mueller <news.5.maazl@spamgourmet.org> - 2019-07-30 23:21 +0200
    Re: Inclusive or exclusive array Arne Vajhøj <arne@vajhoej.dk> - 2019-07-30 19:43 -0400

Page 1 of 2  [1] 2  Next page →

#39029 — Inclusive or exclusive array

I am writing the following method:
    Long[] getFibonacciArray(int from, int to);

What is more logical: an inclusive or an exclusive array?

Should:
    getFibonacciArray(12, 12)

return 'Long[1] { 144 }', or 'Long[0] {  }'?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#39030

On 7/30/2019 12:24 PM, Cecil Westerhof wrote:
> I am writing the following method:
>      Long[] getFibonacciArray(int from, int to);
> 
> What is more logical: an inclusive or an exclusive array?
> 
> Should:
>      getFibonacciArray(12, 12)
> 
> return 'Long[1] { 144 }', or 'Long[0] {  }'?

     There are precedents for both, the latter being noticeably
more common.  There is also precedent for

Long[12] {144, 233, 377, 610, 987, 1597,
           2584, 4181, 6765, 10946, 17711, 28657}

... with a likely change of parameter name.

     Citations:

	java.lang.String::substring(int, int)
	java.util.stream.IntStream::rangeClosed(int, int)
	java.lang.String::new(char[], int, int)

-- 
esosman@comcast-dot-net.invalid
Five hundred forty days to go.

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

#39032

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> On 7/30/2019 12:24 PM, Cecil Westerhof wrote:
>> I am writing the following method:
>>      Long[] getFibonacciArray(int from, int to);
>>
>> What is more logical: an inclusive or an exclusive array?
>>
>> Should:
>>      getFibonacciArray(12, 12)
>>
>> return 'Long[1] { 144 }', or 'Long[0] {  }'?
>
>     There are precedents for both, the latter being noticeably
> more common.  There is also precedent for
>
> Long[12] {144, 233, 377, 610, 987, 1597,
>           2584, 4181, 6765, 10946, 17711, 28657}
>
> ... with a likely change of parameter name.
>
>     Citations:
>
> 	java.lang.String::substring(int, int)
> 	java.util.stream.IntStream::rangeClosed(int, int)
> 	java.lang.String::new(char[], int, int)

I was later also thinking about the third, but for the moment I go for
exclusive.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#39038

On 2019-07-30 20:41, Cecil Westerhof wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> 
>> On 7/30/2019 12:24 PM, Cecil Westerhof wrote:
>>> I am writing the following method:
>>>      Long[] getFibonacciArray(int from, int to);
>>>
>>> What is more logical: an inclusive or an exclusive array?
>>>
>>> Should:
>>>      getFibonacciArray(12, 12)
>>>
>>> return 'Long[1] { 144 }', or 'Long[0] {  }'?
>>
>>     There are precedents for both, the latter being noticeably
>> more common.  There is also precedent for
>>
>> Long[12] {144, 233, 377, 610, 987, 1597,
>>           2584, 4181, 6765, 10946, 17711, 28657}
>>
>> ... with a likely change of parameter name.
>>
>>     Citations:
>>
>> 	java.lang.String::substring(int, int)
>> 	java.util.stream.IntStream::rangeClosed(int, int)
>> 	java.lang.String::new(char[], int, int)
> 
> I was later also thinking about the third, but for the moment I go for
> exclusive.

To be clear, what Eric was trying to say, was that likely the most
common idiom of the sort, in Java, is:

[zero-based-index-inclusive, *length*]

... which largely alleviates the very issue you're referring to.

-- 
DF.

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

#39040

On 7/30/2019 8:19 PM, Daniele Futtorovic wrote:
> [...]
> To be clear, what Eric was trying to say, was that likely the most
> common idiom of the sort, in Java, is:
> 
> [zero-based-index-inclusive, *length*]

     Sorry if I was too telegraphic, but that's not what I meant.
What I *did* mean was

     - (inclusive start, exclusive end) is most common
     - (inclusive start, length) is seen, less commonly
     - (inclusive start, inclusive end) is seen, but is rare

-- 
esosman@comcast-dot-net.invalid
Five hundred thirty-nine days to go.

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

#39049

On 2019-07-31 13:22, Eric Sosman wrote:
> On 7/30/2019 8:19 PM, Daniele Futtorovic wrote:
>> [...]
>> To be clear, what Eric was trying to say, was that likely the most
>> common idiom of the sort, in Java, is:
>>
>> [zero-based-index-inclusive, *length*]
> 
>     Sorry if I was too telegraphic, but that's not what I meant.
> What I *did* mean was
> 
>     - (inclusive start, exclusive end) is most common
>     - (inclusive start, length) is seen, less commonly
>     - (inclusive start, inclusive end) is seen, but is rare

Whoopsie, then. Thanks for correcting me.

-- 
DF.

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

#39050

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> What I *did* mean was
>      - (inclusive start, exclusive end) is most common
>      - (inclusive start, length) is seen, less commonly
>      - (inclusive start, inclusive end) is seen, but is rare

Just curious: on what analysis is this based? 
  - some complete classification of all range-accepting JSL methods?
  - some complete classification of those JSL methods you actually use?
  - gut feeling based on the JSL methods you actually use? ;-)

I'm not disputing it, but there might be different results based 
on different weighing of importance of each method, and whether one
only considers integral ranges or also float,Date,... ranges.

PS: my own gut feeling was that ranges in Java "from/length" would be
  more common for integral, while in C++ "from/excl-to" would be more
  common - as in C+++ integral ranges are often just a special case of
  iterator-based ranges.

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

#39051

On 8/1/2019 4:02 AM, Andreas Leitgeb wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> What I *did* mean was
>>       - (inclusive start, exclusive end) is most common
>>       - (inclusive start, length) is seen, less commonly
>>       - (inclusive start, inclusive end) is seen, but is rare
> 
> Just curious: on what analysis is this based?

     Details are in my forthcoming paper in the September "Proceedings
of the Royal and Ancient Society of Distracted Dizzy Doofuses."  :-)

     That is, it's my own informal impression of the practice among
Java SE methods, necessarily biased toward those I myself wind up
using frequently.  YMMV, naturally.

-- 
esosman@comcast-dot-net.invalid
Five hundred thirty-eight days to go.

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

#39053

On 8/1/2019 7:47 AM, Eric Sosman wrote:
> On 8/1/2019 4:02 AM, Andreas Leitgeb wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>> What I *did* mean was
>>>       - (inclusive start, exclusive end) is most common
>>>       - (inclusive start, length) is seen, less commonly
>>>       - (inclusive start, inclusive end) is seen, but is rare
>>
>> Just curious: on what analysis is this based?
> 
>      Details are in my forthcoming paper in the September "Proceedings
> of the Royal and Ancient Society of Distracted Dizzy Doofuses."  :-)
> 
>      That is, it's my own informal impression of the practice among
> Java SE methods, necessarily biased toward those I myself wind up
> using frequently.  YMMV, naturally.

java.lang.String.substring() is one noticeable example of exclusive end.

It may be worth noting that .NET System.String.Substring(),
C++ std::string::substr() and PHP substr() all chose length.

Arne

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

#39054

On Thursday, August 1, 2019 at 11:19:55 AM UTC-4, Arne Vajhøj wrote:
> 
> java.lang.String.substring() is one noticeable example of exclusive end.
> 
> It may be worth noting that .NET System.String.Substring(),
> C++ std::string::substr() and PHP substr() all chose length.
> 
> Arne

substring is a fun animal.  I'm used to start position, length from other languages then we get to java with start index, end index.

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

#39063

On Thu, 1 Aug 2019 10:04:37 -0700 (PDT), Eric Douglas
<e.d.programmer@gmail.com> wrote:

>On Thursday, August 1, 2019 at 11:19:55 AM UTC-4, Arne Vajh=C3=B8j wrote:
>>=20
>> java.lang.String.substring() is one noticeable example of exclusive end.
>>=20
>> It may be worth noting that .NET System.String.Substring(),
>> C++ std::string::substr() and PHP substr() all chose length.
>>=20
>> Arne
>
>substring is a fun animal.  I'm used to start position, length from other l=
>anguages then we get to java with start index, end index.

What make it 'click' for me is when I realized that where other
languages use {start,len}, Java convention uses {start,start+len}.

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

#39064

On Friday, August 2, 2019 at 1:48:53 PM UTC-4, Scott wrote:
> >substring is a fun animal.  I'm used to start position, length from other l=
> >anguages then we get to java with start index, end index.
> 
> What make it 'click' for me is when I realized that where other
> languages use {start,len}, Java convention uses {start,start+len}.

It's also the 0-base vs 1-base.
If you want to parse the "DEF" out of "ABCDEFG" it could reference as (4,3) or (3,6)

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

#39067

On Fri, 2 Aug 2019 10:58:52 -0700 (PDT), Eric Douglas
<e.d.programmer@gmail.com> wrote:

>On Friday, August 2, 2019 at 1:48:53 PM UTC-4, Scott wrote:
>> >substring is a fun animal.  I'm used to start position, length from other l=
>> >anguages then we get to java with start index, end index.
>> 
>> What make it 'click' for me is when I realized that where other
>> languages use {start,len}, Java convention uses {start,start+len}.
>
>It's also the 0-base vs 1-base.
>If you want to parse the "DEF" out of "ABCDEFG" it could reference as (4,3) or (3,6)

I haven't seen 1-based indexing in a very long time. Not since I last
touched BASIC I think.

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

#39072

On 8/3/2019 1:40 AM, Scott wrote:
> On Fri, 2 Aug 2019 10:58:52 -0700 (PDT), Eric Douglas
> <e.d.programmer@gmail.com> wrote:
>> On Friday, August 2, 2019 at 1:48:53 PM UTC-4, Scott wrote:
>>>> substring is a fun animal.  I'm used to start position, length from other l=
>>>> anguages then we get to java with start index, end index.
>>>
>>> What make it 'click' for me is when I realized that where other
>>> languages use {start,len}, Java convention uses {start,start+len}.
>>
>> It's also the 0-base vs 1-base.
>> If you want to parse the "DEF" out of "ABCDEFG" it could reference as (4,3) or (3,6)
> 
> I haven't seen 1-based indexing in a very long time. Not since I last
> touched BASIC I think.

Fortran uses 1 based array indexes.

Cobol may as well.

Wirth languages have explicit array index start.

It varies.

Even JDBC use 1 based indexes for parameters and columns.

Arne

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

#39073

On Saturday, August 3, 2019 at 1:37:32 AM UTC-4, Scott wrote:
> I haven't seen 1-based indexing in a very long time. Not since I last
> touched BASIC I think.

Different languages and methods go back and forth on the 1-based vs 0-based.
I'm used to substring being 1-based because the language we work with started out as a Business BASIC, is now a BASIC-Java hybrid.  Before that I worked in COBOL.
Java is also 1-based, just not on the substring.
https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html#setString-int-java.lang.String-

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

#39074

On 8/5/2019 8:04 AM, Eric Douglas wrote:
> On Saturday, August 3, 2019 at 1:37:32 AM UTC-4, Scott wrote:
>> I haven't seen 1-based indexing in a very long time. Not since I last
>> touched BASIC I think.
> 
> Different languages and methods go back and forth on the 1-based vs 0-based.
> I'm used to substring being 1-based because the language we work with started out as a Business BASIC, is now a BASIC-Java hybrid.  Before that I worked in COBOL.
> Java is also 1-based, just not on the substring.
> https://docs.oracle.com/javase/8/docs/api/java/sql/PreparedStatement.html#setString-int-java.lang.String-

Java is 0-based for both arrays and strings.

But yes - JDBC is 1-based.

Inconsistent.

One should probably always use names and not indexes in JDBC in 2019.

Arne

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

#39056

On 8/1/2019 11:19 AM, Arne Vajhøj wrote:
> [...]
> java.lang.String.substring() is one noticeable example of exclusive end.

     It turns out that java.lang.String offers examples of all
three approaches:

     - Exclusive end:
	codePointCount(int, int)
	getBytes(int, int, byte[], int), deprecated
	getChars(int, int, char[], int)
	subSequence(int, int)
	substring(int, int)

     - Count:
	new(byte[], int, int)
	new(byte[], int, int, Charset)
	new(byte[], int, int, int), deprecated
	new(byte[], int, int, String)
	new(char[], int, int)
	new(int[], int, int)
	copyValueOf(char[], int, int)
	regionMatches(boolean, int, int, String, int)

     - Inclusive end (I may be quibbling):
	lastIndexOf(int, int)
	lastIndexOf(String, int)

     Of these, the only ones I encounter in day-by-day work are
substring(), the first new(), and both lastIndexOf() variants.
YMMV, especially if you've gone beyond the Java 8 I'm using.

-- 
esosman@comcast-dot-net.invalid
Five hundred thirty-eight days to go.

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

#39057

On 2019-08-01 20:20, Eric Sosman wrote:
>     - Exclusive end:
>     - Count:
>     - Inclusive end (I may be quibbling):

Any preferences?

-- 
DF.

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

#39066

On 8/1/2019 7:15 PM, Daniele Futtorovic wrote:
> On 2019-08-01 20:20, Eric Sosman wrote:
>>      - Exclusive end:
>>      - Count:
>>      - Inclusive end (I may be quibbling):
> 
> Any preferences?

     Mild ones.

     In string-bashing, it seems a frequent task is to find the start
of an interesting piece, scan forward for a delimiter of some kind,
and snip out the interesting piece.  String::substring(int, int) fits
very naturally into this sort of scenario, IMHO, especially since the
exclusive end of one piece is exactly the inclusive start of the
piece that follows.

-- 
esosman@comcast-dot-net.invalid
Five hundred thirty-seven days to go.

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

#39041 — IntStream.rangeClosed() (was: Re: Inclusive or exclusive array)

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> 	java.util.stream.IntStream::rangeClosed(int, int)

Doc says that the sequence is equivalent to the following for loop:
   for (int i = startInclusive; i <= endInclusive ; i++) { ... }

Does that mean in practice that an IntStream.rangeClosed() with
Integer.MAX_VALUE given for endInclusive should produce an "infinite"
stream of integers, as the for loop would do with such a condition?

PS: Apparently it does not. Is the javadoc "imprecise"?

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web