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 2 of 2 — ← Prev page 1 [2]

#39042 — Re: IntStream.rangeClosed()

On 7/31/2019 7:33 AM, Andreas Leitgeb wrote:
> 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"?

     I have long maintained that Javadoc is both a blessing and
a curse: A blessing in that the programmers *almost always*
write documentation, a curse in that the *programmers* almost
always write documentation.

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

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

#39043 — Re: IntStream.rangeClosed()

On Wednesday, July 31, 2019 at 8:00:05 AM UTC-4, Eric Sosman wrote:
> > PS: Apparently it does not. Is the javadoc "imprecise"?
> 
>      I have long maintained that Javadoc is both a blessing and
> a curse: A blessing in that the programmers *almost always*
> write documentation, a curse in that the *programmers* almost
> always write documentation.
> 

It would be helpful for someone who knows nothing about an API to work with the developer of the API on documenting it.  Everything looks intuitive to the one who designed it.

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

#39045 — Re: IntStream.rangeClosed()

On 7/31/2019 8:40 AM, Eric Douglas wrote:
> On Wednesday, July 31, 2019 at 8:00:05 AM UTC-4, Eric Sosman wrote:
>>> PS: Apparently it does not. Is the javadoc "imprecise"?
>>
>>       I have long maintained that Javadoc is both a blessing and
>> a curse: A blessing in that the programmers *almost always*
>> write documentation, a curse in that the *programmers* almost
>> always write documentation.
>>
> 
> It would be helpful for someone who knows nothing about an API to work with the developer of the API on documenting it.  Everything looks intuitive to the one who designed it.

     Exactly.  There's also the problem that programmers are trained
to write Java/Python/APL/whatever, but not so much to write English.
Meanwhile, the trained professional editor could probably improve the
programmers' Javadoc but is probably not authorized to make source
code changes!

     I have absolutely no idea how the translation of Javadoc comments
from one human language to another can be managed ...  Has anyone
ever seen SE Javadoc in French or Korean or Norsk, say?  If so, have
you any knowledge of its provenance?

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

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

#39046 — Re: IntStream.rangeClosed()

On Wednesday, July 31, 2019 at 11:02:38 AM UTC-4, Eric Sosman wrote:
>      Exactly.  There's also the problem that programmers are trained
> to write Java/Python/APL/whatever, but not so much to write English.
> Meanwhile, the trained professional editor could probably improve the
> programmers' Javadoc but is probably not authorized to make source
> code changes!
> 
>      I have absolutely no idea how the translation of Javadoc comments
> from one human language to another can be managed ...  Has anyone
> ever seen SE Javadoc in French or Korean or Norsk, say?  If so, have
> you any knowledge of its provenance?
> 

I don't know how Javadoc might translate with foreign languages but I would assume they're written in English, as Java is an English based language.
I know many Java developers come from India, and many of them don't speak English very well, so they could surely use a translator to help read/write documentation.

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

#39047 — Re: IntStream.rangeClosed()

On Wed, 31 Jul 2019 07:59:52 -0400, Eric Sosman wrote:

>      I have long maintained that Javadoc is both a blessing and
> a curse: A blessing in that the programmers *almost always* write
> documentation, a curse in that the *programmers* almost always write
> documentation.
>
As somebody who started programming and system maintenance when all we 
had was source code on cards (or in a COSY library on mag tape or disk if 
you were using ICL iron) and the requirements and other documentation 
were all on flow charts (UGH), typed and/or hand-written pages in ring-
binders, the idea of Javadocs was WONDERFUL simply because it would have 
meant that the system documentation, at module level anyway) didn't get 
lost or binned. Updated? In your dreams!

Fixing bugs in assembler and COBOL programs which had minimal or no 
useful comments in them and no other accessible documentation was the 
norm: at one point I worked in a programming shop where the systems 
analysts kept no documentation - it was shredded as soon as the code 
and/or changes to it had been accepted and signed off. Smiths Industries 
of Cricklewood, London - I'm looking at you!

Ideally, in a javadocs world the class-level and method-level comments 
would be written by the members of the design team responsible for 
specifying the class structure and public method interfaces with the 
intention that these comments, together with the empty method skeletons, 
each containing only a return statement if the method returns a result 
and/or a similar skeleton if it can throw an Exception, would be clean-
compiled and run through javadocs to eliminate typos etc, before being 
passed to a programmer for completion and unit testing.

Late in the day it also occurs to me that, it shouldn't be hard to 
generate a test harness from the sort of skeletal class definition I've 
just described. I currently use such a test harness, but hand-generate 
the code that interfaces the class to be tested to the generic parts of 
the test harness, i.e. that read, parse and execute test scripts. This 
works well and is trivially easy to use for regression testing too (just 
keep known good output and compare that with output from a new run of the 
test script - if there are differences the regression test has failed.   


-- 
Martin    | martin at
Gregorie  | gregorie dot org

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

#39048 — Re: IntStream.rangeClosed()

On Wednesday, July 31, 2019 at 12:46:28 PM UTC-4, Martin Gregorie wrote:
> Fixing bugs in assembler and COBOL programs which had minimal or no 
> useful comments in them and no other accessible documentation was the 
> norm: at one point I worked in a programming shop where the systems 
> analysts kept no documentation - it was shredded as soon as the code 
> and/or changes to it had been accepted and signed off. Smiths Industries 
> of Cricklewood, London - I'm looking at you!
> 
> 

I won a programming competition in college (against other colleges).  No one finished in the allotted time.  Mine was voted the closest, as they seemed to love the flower boxes.

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

#39034

Am 30.07.19 um 18:24 schrieb Cecil Westerhof:
> 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] {  }'?

I plead for exclusive upper bound wherever possible. It saves you 
headaches when dealing with intervals, because you do not always have to 
increment or decrement the bound for comparison. E.g.
   RangeIsAdjacent(int low1, int high1, int low2, int high2)
   => low1 == high2 || low2 == high1
It is also the way C++ iterator ranges are defined.

Another point comes into play, if the values are not whole numbers, e.g. 
DateTime or float. In Both cases there is not even a reasonable 
definition for increment and decrement. So you cannot check whether two 
ranges are adjacent nor you can partition a set of values into 
non-overlapping ranges easily.

The drawback is that you usually have to convert the upper value before 
showing it to an end user, because they do not understand that "up to 
Monday" means Monday exclusive.
But be careful. The meaning depends on the precision. "Up to Monday" 
usually means Tuesday 00:00 exclusive. While "Up to Monday 06:00" is 
sooner. The same value used as from would be /later/ than just "Monday".
So using exclusive upper bounds in the data model gives you the chance 
to increase precision without a semantic change.


Marcel

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

#39036

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] {  }'?

I believe in the inclusive model.

My reason:
* that is the intuitive expectation from people
   with no IT background
* the reasons for exclusive are IT nerdish
* I favor non-IT intuitive logic over
   IT nerdish

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web