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

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

in1To10

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

Contents

  in1To10 cdalten@gmail.com - 2014-08-09 12:12 -0700
    Re: in1To10 Jeff Higgins <jeff@invalid.invalid> - 2014-08-09 15:58 -0400
    Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-09 16:13 -0400
    Re: in1To10 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2014-08-09 22:56 +0200
      Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-09 17:02 -0400
        Re: in1To10 Marcel Mueller <news.5.maazl@spamgourmet.org> - 2014-08-09 23:43 +0200
          Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-09 19:49 -0400
          Re: in1To10 Torsten Kirschner <torsten@kirschner.no> - 2014-08-10 16:59 +0200
            Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-10 11:33 -0400
              Re: in1To10 Torsten Kirschner <torsten@kirschner.no> - 2014-08-11 22:23 +0200
              Re: in1To10 Gene Wirchenko <genew@telus.net> - 2014-08-12 11:10 -0700
                Re: in1To10 Arne Vajhøj <arne@vajhoej.dk> - 2014-08-19 16:54 -0400
                  Re: in1To10 Gene Wirchenko <genew@telus.net> - 2014-08-20 10:36 -0700
              Re: in1To10 Arne Vajhøj <arne@vajhoej.dk> - 2014-08-19 16:53 -0400
    Re: in1To10 cdalten@gmail.com - 2014-08-09 18:35 -0700
      Re: in1To10 Jeff Higgins <jeff@invalid.invalid> - 2014-08-09 22:13 -0400
      Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-09 22:23 -0400
      Re: in1To10 Jeff Higgins <jeff@invalid.invalid> - 2014-08-10 12:07 -0400
    Re: in1To10 Mike Amling <mamling@chaff.us> - 2014-08-10 00:29 -0500
    Re: in1To10 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-10 13:53 +0100
      Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-10 09:48 -0400
        Re: in1To10 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-10 15:01 +0100
          Re: in1To10 Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-10 10:32 -0400
            Re: in1To10 "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-10 15:53 +0100
    Re: in1To10 lipska the kat <lipskathekat@example.com> - 2014-08-10 14:07 +0100
    Re: in1To10, a simple test plan lipska the kat <lipskathekat@example.com> - 2014-08-10 16:43 +0100
      Re: in1To10, a simple test plan Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-10 12:01 -0400
        Re: in1To10, a simple test plan lipska the kat <lipskathekat@example.com> - 2014-08-10 17:41 +0100
        Re: in1To10, a simple test plan Arne Vajhøj <arne@vajhoej.dk> - 2014-08-19 16:57 -0400
    Re: in1To10 Roedy Green <see_website@mindprod.com.invalid> - 2014-08-12 02:59 -0700

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

#29623

On 8/10/2014 8:53 AM, Chris Uppal wrote:
> cdalten@gmail.com wrote:
>
>> The problem states: "Given a number n, return true if n is in the range
>> 1..10, inclusive. Unless "outsideMode" is true, in which case return true
>> if the number is less or equal to 1, or greater or equal to 10."
>
> Not really addressing the question, but nobody (I've seen) has mentioned what I
> would consider the most direct encoding of the problem which has IMO the most
> "eloquent" use of Boolean-valued variables.  It also, IMO, illustrates the need
> for /very carefully/ considered identifiers[*] (which for some reason seems to
> be at its most acute for Booleans -- I have no idea why, anyone ?).
>
> Not tested. Some might prefer more brackets.
>
> static boolean testAgainst1to10(int i, boolean trueIfOutside)
> {
>      boolean isOutside = i < 1 || i > 10;
>      return isOutside == trueIfOutside;
> }

     "Not really addressing the question" is a good opening, because
the offered code addresses a different question than the one posed.
(You've repeated Marcel Mueller's mistake, perhaps by reading a little
too quickly.)

-- 
esosman@comcast-dot-net.invalid

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

#29624

Eric Sosman wrote:

>     "Not really addressing the question" is a good opening, because
> the offered code addresses a different question than the one posed.
> (You've repeated Marcel Mueller's mistake, perhaps by reading a little
> too quickly.)

Drat...

    -- chris 

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

#29625

On 8/10/2014 10:01 AM, Chris Uppal wrote:
> Eric Sosman wrote:
>
>>      "Not really addressing the question" is a good opening, because
>> the offered code addresses a different question than the one posed.
>> (You've repeated Marcel Mueller's mistake, perhaps by reading a little
>> too quickly.)
>
> Drat...

     It's oddly interesting that at least three people have made the
same error (I did, too, but had the good fortune to catch myself
*before* posting).  Perhaps we're all thinking back to the days
when we took our first fumbling steps at Boolean logic, and we sort
of half-recognize the problem: "Aha!" we think, "this is somebody's
idea of a way to introduce exclusive-OR!"  Then we leap ahead to
solve a problem for which XOR would be useful (we may or may not
actually use XOR), and we wind up solving the wrong problem ...

-- 
esosman@comcast-dot-net.invalid

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

#29626

Eric Sosman wrote:

>     It's oddly interesting that at least three people have made the
> same error (I did, too, but had the good fortune to catch myself
> *before* posting).

Since [at least] three people have fallen into the same trap, I claim that it's 
a bug in the presentation of the problem ;-)  Specifications shouldn't be 
obfuscated any more (on fact less) than code.


> Perhaps we're all thinking back to the days
> when we took our first fumbling steps at Boolean logic, and we sort
> of half-recognize the problem: "Aha!" we think, "this is somebody's
> idea of a way to introduce exclusive-OR!"  Then we leap ahead to
> solve a problem for which XOR would be useful (we may or may not
> actually use XOR), and we wind up solving the wrong problem ...

In my case, I'm sure it was the speed reading thing (as you mentioned, but in 
my case natural rather than learned):  See first 2/3 of problem; visual systems 
forms hypothesis as to what remaining 1/3 will be; quick scan of remaining 1/3 
appears to confirm hypothesis; job [not] done [right].

All totally unconcious of course.  And /impossible/ to turn off (I'm a hopeless 
copy editor -- or rather I lack the ability to be a copy editor at all).  I 
did, in fact, "read" the spec several times...

...sigh

    -- chris 

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

#29622

On 09/08/14 20:12, cdalten@gmail.com wrote:
> from the url
>
> http://codingbat.com/prob/p137365
>

<snip>

>
> Would both catch all the cases? If not, which one would?
>
> Chad
>

Well, by now you should have a whole raft of 'solutions' to your problem.

How do you know if any of them are 'correct'
What is correct anyway?

What you *really* need is a test plan, I'm surprised nobody has 
mentioned it. Devise a test plan that meets the requirements and you can 
test all of these solutions with the same cases. You'll soon discover 
which ones are winners and which are not.

Has anyone discussed testing on your course.
Do you know what a 'boundary case' is?

-- 
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
GNU/Linux user #560883 - linuxcounter.net

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

#29630 — Re: in1To10, a simple test plan

On 09/08/14 20:12, cdalten@gmail.com wrote:
> from the url
>
> http://codingbat.com/prob/p137365

Here is an example of a simple test plan
Apply the tests to the different implementations
you have been given and see which ones comply.


/* Specification:
  *
  * Given a number n, return true if n is in the range 1..10, inclusive.
  * Unless "outsideMode" is true, in which case return true if the
  * number is less or equal to 1, or greater or equal to 10."
  */

/*
  * Test plan:
  *
  * boolean outsideMode = true;
  *
  * Test:			Expected result:
  * n = 1 && outsideMode		true
  * n = 1 && !outsideMode  	true
  * n = 10 && outsideMode	true
  * n = 10 && !outsideMode	true
  * n = 0 && outsideMode 	true
  * n = 0 && !outsideMode 	false
  * n = -1 && outsideMode 	true
  * n = -1 && !outsideMode 	false
  * n = 2 && outsideMode 	false
  * n = 2 && !outsideMode	true
  * n = 5 && outsideMode 	false
  * n = 5 && !outsideMode	true
  * n = 9 && outsideMode 	false
  * n = 9 && !outsideMode	true
  * n = 11 && outsideMode    	true
  * n = 11 && !outsideMode   	false
  */

public class In1To10 {
	
    static boolean in1To10(int n, boolean outsideMode){
       if(n == 1 || n == 10){
          return true;
       }
       else{
          return (n > 1 && n < 10) ^ outsideMode;
       }
    }
	
    public static void main(String[] args){
       boolean outsideMode = true;
                                                    //Expected:  Actual:
       System.out.println(in1To10(1, outsideMode));   //true	true
       System.out.println(in1To10(1, !outsideMode));  //true	true
       System.out.println(in1To10(10, outsideMode));  //true	true
       System.out.println(in1To10(10, !outsideMode)); //true	true
       System.out.println(in1To10(0, outsideMode));   //true	true
       System.out.println(in1To10(0, !outsideMode));  //false	false
       System.out .println(in1To10(-1, outsideMode)); //true	true
       System.out.println(in1To10(-1, !outsideMode)); //false	false
       System.out.println(in1To10(2, outsideMode));   //false	false
       System.out.println(in1To10(2, !outsideMode));  //true	true
       System.out.println(in1To10(5, outsideMode));   //false	false
       System.out.println(in1To10(5, !outsideMode));  //true     true
       System.out.println(in1To10(9, outsideMode));   //false	false
       System.out.println(in1To10(9, !outsideMode));  //true     true
       System.out.println(in1To10(11, outsideMode));  //true     true
       System.out.println(in1To10(11, !outsideMode)); //false	false
       //etc
    }
}


-- 
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
GNU/Linux user #560883 - linuxcounter.net

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

#29631 — Re: in1To10, a simple test plan

On 8/10/2014 11:43 AM, lipska the kat wrote:
> [...]
> public class In1To10 {
>
>     static boolean in1To10(int n, boolean outsideMode){
>        if(n == 1 || n == 10){
>           return true;
>        }
>        else{
>           return (n > 1 && n < 10) ^ outsideMode;
>        }
>     }
>
>     public static void main(String[] args){
>        boolean outsideMode = true;
>                                                     //Expected:  Actual:
>        System.out.println(in1To10(1, outsideMode));   //true    true
>        System.out.println(in1To10(1, !outsideMode));  //true    true
>        System.out.println(in1To10(10, outsideMode));  //true    true
>        System.out.println(in1To10(10, !outsideMode)); //true    true
>        System.out.println(in1To10(0, outsideMode));   //true    true
>        System.out.println(in1To10(0, !outsideMode));  //false    false
>        System.out .println(in1To10(-1, outsideMode)); //true    true
>        System.out.println(in1To10(-1, !outsideMode)); //false    false
>        System.out.println(in1To10(2, outsideMode));   //false    false
>        System.out.println(in1To10(2, !outsideMode));  //true    true
>        System.out.println(in1To10(5, outsideMode));   //false    false
>        System.out.println(in1To10(5, !outsideMode));  //true     true
>        System.out.println(in1To10(9, outsideMode));   //false    false
>        System.out.println(in1To10(9, !outsideMode));  //true     true
>        System.out.println(in1To10(11, outsideMode));  //true     true
>        System.out.println(in1To10(11, !outsideMode)); //false    false
>        //etc
>     }
> }

     While the notion of having a test plan is an excellent one, relying
on human eyeballs to verify the expected output is tedious and may be
error-prone.  I'd suggest writing a helper method, something like

	static void test(int number, boolean mode, boolean expected) {
	    boolean actual = in1To10(number, mode);
	    if (actual != expected) {
	        throw new AssertionError(String.format(
	            "in1To10(%d, %b) gave %b, expected %b",
	            number, mode, actual, expected);
	    }
	}

... and then write the test cases as

	test(1, true, true);
	test(1, false, true);
	...
	test(11, true, true);
	test(11, false, false);
	//etc

-- 
esosman@comcast-dot-net.invalid

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

#29633 — Re: in1To10, a simple test plan

On 10/08/14 17:01, Eric Sosman wrote:
> On 8/10/2014 11:43 AM, lipska the kat wrote:
>> [...]
>> public class In1To10 {
>>
>>     static boolean in1To10(int n, boolean outsideMode){
>>        if(n == 1 || n == 10){
>>           return true;
>>        }
>>        else{
>>           return (n > 1 && n < 10) ^ outsideMode;
>>        }
>>     }
>>
>>     public static void main(String[] args){
>>        boolean outsideMode = true;
>>                                                     //Expected:  Actual:
>>        System.out.println(in1To10(1, outsideMode));   //true    true
>>        System.out.println(in1To10(1, !outsideMode));  //true    true
>>        System.out.println(in1To10(10, outsideMode));  //true    true
>>        System.out.println(in1To10(10, !outsideMode)); //true    true
>>        System.out.println(in1To10(0, outsideMode));   //true    true
>>        System.out.println(in1To10(0, !outsideMode));  //false    false
>>        System.out .println(in1To10(-1, outsideMode)); //true    true
>>        System.out.println(in1To10(-1, !outsideMode)); //false    false
>>        System.out.println(in1To10(2, outsideMode));   //false    false
>>        System.out.println(in1To10(2, !outsideMode));  //true    true
>>        System.out.println(in1To10(5, outsideMode));   //false    false
>>        System.out.println(in1To10(5, !outsideMode));  //true     true
>>        System.out.println(in1To10(9, outsideMode));   //false    false
>>        System.out.println(in1To10(9, !outsideMode));  //true     true
>>        System.out.println(in1To10(11, outsideMode));  //true     true
>>        System.out.println(in1To10(11, !outsideMode)); //false    false
>>        //etc
>>     }
>> }
>
>      While the notion of having a test plan is an excellent one, relying
> on human eyeballs to verify the expected output is tedious and may be
> error-prone.  I'd suggest writing a helper method, something like

I agree, in the real world of course we would probably use a test 
framework, something like JUnit perhaps as part of our 'agile' 
development process ... I was big into agile for a while, pair 
programming, client representatives, write the test before the code etc 
whatever happened to agile, is it still 'in favour'?

Retirement can be a bitch, the garden needs attention NOW, so I'll have 
to leave reading that paper on process until later etc etc.


-- 
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
GNU/Linux user #560883 - linuxcounter.net

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

#29742 — Re: in1To10, a simple test plan

On 8/10/2014 12:01 PM, Eric Sosman wrote:
> On 8/10/2014 11:43 AM, lipska the kat wrote:
>> [...]
>> public class In1To10 {
>>
>>     static boolean in1To10(int n, boolean outsideMode){
>>        if(n == 1 || n == 10){
>>           return true;
>>        }
>>        else{
>>           return (n > 1 && n < 10) ^ outsideMode;
>>        }
>>     }
>>
>>     public static void main(String[] args){
>>        boolean outsideMode = true;
>>                                                     //Expected:  Actual:
>>        System.out.println(in1To10(1, outsideMode));   //true    true
>>        System.out.println(in1To10(1, !outsideMode));  //true    true
>>        System.out.println(in1To10(10, outsideMode));  //true    true
>>        System.out.println(in1To10(10, !outsideMode)); //true    true
>>        System.out.println(in1To10(0, outsideMode));   //true    true
>>        System.out.println(in1To10(0, !outsideMode));  //false    false
>>        System.out .println(in1To10(-1, outsideMode)); //true    true
>>        System.out.println(in1To10(-1, !outsideMode)); //false    false
>>        System.out.println(in1To10(2, outsideMode));   //false    false
>>        System.out.println(in1To10(2, !outsideMode));  //true    true
>>        System.out.println(in1To10(5, outsideMode));   //false    false
>>        System.out.println(in1To10(5, !outsideMode));  //true     true
>>        System.out.println(in1To10(9, outsideMode));   //false    false
>>        System.out.println(in1To10(9, !outsideMode));  //true     true
>>        System.out.println(in1To10(11, outsideMode));  //true     true
>>        System.out.println(in1To10(11, !outsideMode)); //false    false
>>        //etc
>>     }
>> }
>
>      While the notion of having a test plan is an excellent one, relying
> on human eyeballs to verify the expected output is tedious and may be
> error-prone.  I'd suggest writing a helper method, something like
>
>      static void test(int number, boolean mode, boolean expected) {
>          boolean actual = in1To10(number, mode);
>          if (actual != expected) {
>              throw new AssertionError(String.format(
>                  "in1To10(%d, %b) gave %b, expected %b",
>                  number, mode, actual, expected);
>          }
>      }
>
> ... and then write the test cases as
>
>      test(1, true, true);
>      test(1, false, true);
>      ...
>      test(11, true, true);
>      test(11, false, false);
>      //etc

Or use general assertFalse and assertTrue methods ...

Arne

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

#29639

On Sat, 9 Aug 2014 12:12:56 -0700 (PDT), cdalten@gmail.com wrote,
quoted or indirectly quoted someone who said :

>		if (outsideMode == false){
>			if (n >= 1 && n <=10) {
>				return true;
>			}
>		} else if (outsideMode == true){

this is what I call stuttering .

if (outsideMode == true) is the same thing as if (outsidemode)

if (!outsideMode is the same thing as if (!outsidemode)

You second test is redundant.  If outsideMode is false, there is no
other possibility than that outsideMode is true. You don't have to
retest.

see http://mindprod.com/jgloss/stuttering.html
for other examples.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [standalone]

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

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

csiph-web