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

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

Re: Simple if-exercises

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Simple if-exercises Jeff Higgins <jeff@invalid.invalid> - 2015-04-02 09:58 -0400
    Re: Simple if-exercises Jeff Higgins <jeff@invalid.invalid> - 2015-04-02 10:53 -0400
      Re: Simple if-exercises Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-02 15:08 -0400
    Re: Simple if-exercises Gene Wirchenko <genew@telus.net> - 2015-04-02 16:46 -0700
    Re: Simple if-exercises v_borchert@despammed.com (Volker Borchert) - 2015-04-03 06:29 +0000
      Re: Simple if-exercises Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-03 10:29 +0000
        Re: Simple if-exercises v_borchert@despammed.com (Volker Borchert) - 2015-04-03 18:05 +0000
          Re: Simple if-exercises Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-03 19:31 +0000
            Re: Simple if-exercises Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-04-03 16:07 -0400
              Re: Simple if-exercises Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-03 21:45 +0000
            Re: Simple if-exercises v_borchert@despammed.com (Volker Borchert) - 2015-04-03 23:49 +0000
      Re: Simple if-exercises Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-04-03 07:38 -0400
        Re: Simple if-exercises Jeff Higgins <jeff@invalid.invalid> - 2015-04-03 20:06 -0400

#31440 — Re: Simple if-exercises

On 04/01/2015 08:10 PM, Stefan Ram wrote:
>    I was looking for very simple if-exercises.
>
>    I usually found exercises like this:
>
>        »Print "positive" if x > 0, "non-positive", otherwise.«
>
>    The expected answer would be
>
> if( x > 0 )
> System.out.println( "positive" );
> else
> System.out.println( "non-positive" );
>
>    However, I already have taught »?:«, so the better
>    (shorter) solution would be:
>
> System.out.println( ( x > 0 ? "" : "non-" )+ "positive" );
>
>    . Do you know a very simple if-exercise whose solution
>    cannot be written more tersely with the ternary operator
>    or where the formulation with »if« is clearly better than
>    with the ternary operator?
>
>    Knowledge that can be assumed: calls and declarations of
>    static methods, +, -, *, /, usage of variables, declarations
>    of local variables, boolean, int, double, String, literals,
>    the block {...}, ?:, <, >, <=, >=, !=, ==.
>
Why don't we have a Quinary operator?
x ? y LT : EQ : GT

[toc] | [next] | [standalone]

#31441

On 04/02/2015 09:58 AM, Jeff Higgins wrote:
> On 04/01/2015 08:10 PM, Stefan Ram wrote:
>>    I was looking for very simple if-exercises.
>>
>>    I usually found exercises like this:
>>
>>        »Print "positive" if x > 0, "non-positive", otherwise.«
>>
>>    The expected answer would be
>>
>> if( x > 0 )
>> System.out.println( "positive" );
>> else
>> System.out.println( "non-positive" );
>>
>>    However, I already have taught »?:«, so the better
>>    (shorter) solution would be:
>>
>> System.out.println( ( x > 0 ? "" : "non-" )+ "positive" );
>>
>>    . Do you know a very simple if-exercise whose solution
>>    cannot be written more tersely with the ternary operator
>>    or where the formulation with »if« is clearly better than
>>    with the ternary operator?
>>
>>    Knowledge that can be assumed: calls and declarations of
>>    static methods, +, -, *, /, usage of variables, declarations
>>    of local variables, boolean, int, double, String, literals,
>>    the block {...}, ?:, <, >, <=, >=, !=, ==.
>>
> Why don't we have a Quinary operator?
> x ? y LT : EQ : GT
>
Or Senary might be better - avoids an unchecked exception.
x ? y LT : EQ : GT : NC

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

#31442

On 4/2/2015 10:53 AM, Jeff Higgins wrote:
> On 04/02/2015 09:58 AM, Jeff Higgins wrote:
>> On 04/01/2015 08:10 PM, Stefan Ram wrote:
>>>    I was looking for very simple if-exercises.
>>>
>>>    I usually found exercises like this:
>>>
>>>        »Print "positive" if x > 0, "non-positive", otherwise.«
>>>
>>>    The expected answer would be
>>>
>>> if( x > 0 )
>>> System.out.println( "positive" );
>>> else
>>> System.out.println( "non-positive" );
>>>
>>>    However, I already have taught »?:«, so the better
>>>    (shorter) solution would be:
>>>
>>> System.out.println( ( x > 0 ? "" : "non-" )+ "positive" );
>>>
>>>    . Do you know a very simple if-exercise whose solution
>>>    cannot be written more tersely with the ternary operator
>>>    or where the formulation with »if« is clearly better than
>>>    with the ternary operator?
>>>
>>>    Knowledge that can be assumed: calls and declarations of
>>>    static methods, +, -, *, /, usage of variables, declarations
>>>    of local variables, boolean, int, double, String, literals,
>>>    the block {...}, ?:, <, >, <=, >=, !=, ==.
>>>
>> Why don't we have a Quinary operator?
>> x ? y LT : EQ : GT
>>
> Or Senary might be better - avoids an unchecked exception.
> x ? y LT : EQ : GT : NC
> 

Why not?  FORTRAN has arithmetic IF statements, where the branch is made
dependent on whether the result of the expression is less than, equal to
or greater than 0.  I found it quite useful at times when I was doing
FORTRAN II programming.

Of course, it also has a computed GOTO statement, but that's similar to
(but more restrictive than) switch/case statements.  Of course, it's
also not structured programming.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#31443

On Thu, 02 Apr 2015 09:58:28 -0400, Jeff Higgins
<jeff@invalid.invalid> wrote:

[snip]

>Why don't we have a Quinary operator?
>x ? y LT : EQ : GT

     There is FORTRAN's arithmetic IF:
          IF (expression) ifnegative,ifzero,ifpositive
e.g.
          IF (A-B) 10,10,20

Sincerely,

Gene Wirchenko

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

#31444

Jeff Higgins wrote:

> Why don't we have a Quinary operator?
> x ? y LT : EQ : GT

One of those occasions where "newer" is not "better".

I _do_ miss FORTRAN's three-way IF statement.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

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

#31446

On Fri, 03 Apr 2015 06:29:59 +0000, Volker Borchert wrote:

> Jeff Higgins wrote:
> 
>> Why don't we have a Quinary operator?
>> x ? y LT : EQ : GT
> 
> One of those occasions where "newer" is not "better".
> 
> I _do_ miss FORTRAN's three-way IF statement.

It would be more in the style of Java to extend the switch statement's 
syntax by adding pseudo constants corresponding to <, == and > so you 
could write something like:

switch(arithmetic expression)
{
  case LT: ....; break;
  case EQ: ....; break;
  case GT: ....; break;
  default: ...; break;
}

As a bonus, you'd also get the equivalent of LE and GE without needing 
any additional syntactic extensions.
  

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#31448

Martin Gregorie wrote:
> On Fri, 03 Apr 2015 06:29:59 +0000, Volker Borchert wrote:
> 
> > Jeff Higgins wrote:
> > 
> >> Why don't we have a Quinary operator?
> >> x ? y LT : EQ : GT
> > 
> > One of those occasions where "newer" is not "better".
> > 
> > I _do_ miss FORTRAN's three-way IF statement.
> 
> It would be more in the style of Java to extend the switch statement's 
> syntax by adding pseudo constants corresponding to <, == and > so you 
> could write something like:
> 
> switch(arithmetic expression)
       sgn(                 )
> {
>   case LT: ....; break;
         -1
>   case EQ: ....; break;
          0
>   case GT: ....; break;
         +1
>   default: ...; break;
> }

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

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

#31449

On Fri, 03 Apr 2015 18:05:24 +0000, Volker Borchert wrote:

> Martin Gregorie wrote:
>> On Fri, 03 Apr 2015 06:29:59 +0000, Volker Borchert wrote:
>> 
>> > Jeff Higgins wrote:
>> > 
>> >> Why don't we have a Quinary operator?
>> >> x ? y LT : EQ : GT
>> > 
>> > One of those occasions where "newer" is not "better".
>> > 
>> > I _do_ miss FORTRAN's three-way IF statement.
>> 
>> It would be more in the style of Java to extend the switch statement's
>> syntax by adding pseudo constants corresponding to <, == and > so you
>> could write something like:
>> 
>> switch(arithmetic expression)
>        sgn(                 )
>
I think you meant Math.signum() - sgn isn't Java, its a VBA/Excel/Access
function.

But in any case using Math.signum() looks kind of messy by the time 
you've called the static function and then coerced its result to integer:

switch((int)Math.signum(n))
{
   case -1:
   case 0:  s = "Negative-or-equal"; break;
   case +1: s = "Positive"; break;          
   default: s = "Defaulted";
}

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#31450

On 4/3/2015 3:31 PM, Martin Gregorie wrote:
>[...]
> But in any case using Math.signum() looks kind of messy by the time
> you've called the static function and then coerced its result to integer:
>
> switch((int)Math.signum(n))
> {
>     case -1:
>     case 0:  s = "Negative-or-equal"; break;
>     case +1: s = "Positive"; break;
>     default: s = "Defaulted";
> }

     Note that the "default:" case will never execute.
Math.signum(n) can return Double.NaN (or Float.NaN, depending
on the type of "n"), but converting a NaN to int yields zero.
JLS 5.1.3.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#31451

On Fri, 03 Apr 2015 16:07:23 -0400, Eric Sosman wrote:

> On 4/3/2015 3:31 PM, Martin Gregorie wrote:
>>[...]
>> But in any case using Math.signum() looks kind of messy by the time
>> you've called the static function and then coerced its result to
>> integer:
>>
>> switch((int)Math.signum(n))
>> {
>>     case -1:
>>     case 0:  s = "Negative-or-equal"; break;
>>     case +1: s = "Positive"; break; default: s = "Defaulted";
>> }
> 
>      Note that the "default:" case will never execute.
> Math.signum(n) can return Double.NaN (or Float.NaN, depending on the
> type of "n"), but converting a NaN to int yields zero.
> JLS 5.1.3.
>
Of course. In the usual situations where I use a switch statement my only 
use for default is to trap errors, so this is best regarded as a token 
error trap. I did write a test program to check the Math.signum() 
behaviour which looped round something like:

for each command-line argument
  switch((int)Math.signum(Integer.parseInt(arg[i])))
  {
    case list
    default statement
  }
  print the result

so in those circumstances I'd argue that NOT using default would be poor 
practice.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#31452

Martin Gregorie wrote:
> On Fri, 03 Apr 2015 18:05:24 +0000, Volker Borchert wrote:
> 
> > Martin Gregorie wrote:
> >> switch(arithmetic expression)
> >        sgn(                 )
> >
> I think you meant Math.signum() - sgn isn't Java, its a VBA/Excel/Access
> function.
> 
> But in any case using Math.signum() looks kind of messy by the time 
> you've called the static function and then coerced its result to integer:

Write your own static int sgn(int). That would even be the type
of simple (but for once, useful!) exercise the OP was looking for.

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

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

#31447

On 4/3/2015 2:29 AM, Volker Borchert wrote:
> Jeff Higgins wrote:
>
>> Why don't we have a Quinary operator?
>> x ? y LT : EQ : GT
>
> One of those occasions where "newer" is not "better".
> 
> I _do_ miss FORTRAN's three-way IF statement.

     I miss it, but very rarely.  It's nice in a binary search,
and it's nice in heapsort, but I can't recall other contexts
that made me wish it were still around.

     An ironic oddity: In the numerical applications for which
FORTRAN is justly famous, the three-way IF is almost never the
right thing to use!  You don't want "negative,zero,positive"
but "noticeably negative,close to zero,noticeably positive."

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#31453

On 04/03/2015 07:38 AM, Eric Sosman wrote:
> On 4/3/2015 2:29 AM, Volker Borchert wrote:
>> Jeff Higgins wrote:
>>
>>> Why don't we have a Quinary operator?
>>> x ? y LT : EQ : GT
>>
>> One of those occasions where "newer" is not "better".
>> 
>> I _do_ miss FORTRAN's three-way IF statement.
>
>      I miss it, but very rarely.  It's nice in a binary search,
> and it's nice in heapsort, but I can't recall other contexts
> that made me wish it were still around.
>
>      An ironic oddity: In the numerical applications for which
> FORTRAN is justly famous, the three-way IF is almost never the
> right thing to use!  You don't want "negative,zero,positive"
> but "noticeably negative,close to zero,noticeably positive."
>
I don't recall having seen a java.lang.Comparable.compareTo(T o)
implementation that uses the full range of int values in its
output. I wonder if someone could point me toward such a thing.

If Comparable is indeed used this way then I wonder about a
pluggable reduce function for it.

[toc] | [prev] | [standalone]

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

csiph-web