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

Groups > comp.lang.c > #23318 > unrolled thread

Precedence Misunderstanding

Back to article view | Back to comp.lang.c

Contents

  Precedence Misunderstanding Charles Richmond <frizzle@aquaporin4.com> - 2012-07-16 23:18 -0500
    Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-16 21:54 -0700
      Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-16 22:13 -0700
        Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-16 22:36 -0700
          Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 13:57 +0100
      Re: Precedence Misunderstanding "Charles Richmond" <numerist@aquaporin4.com> - 2012-07-17 13:35 -0500
        Re: Precedence Misunderstanding "io_x" <a@b.c.invalid> - 2012-07-17 20:48 +0200
        Re: Precedence Misunderstanding Robert Wessel <robertwessel2@yahoo.com> - 2012-07-17 13:45 -0500
        Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-17 12:27 -0700
          Re: Precedence Misunderstanding Willem <willem@toad.stack.nl> - 2012-07-17 20:20 +0000
        Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 20:34 +0100
          Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-17 12:39 -0700
            Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 20:57 +0100
          Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-17 20:48 +0100
            Re: Precedence Misunderstanding Philip Lantz <prl@canterey.us> - 2012-07-17 21:12 -0700
              Re: Precedence Misunderstanding Ike Naar <ike@iceland.freeshell.org> - 2012-07-18 07:14 +0000
                Re: Precedence Misunderstanding "BartC" <bc@freeuk.com> - 2012-07-18 10:11 +0100
                  Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 09:18 -0700
                  Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 18:10 +0100
                    Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-18 18:27 +0100
                      Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 18:53 +0100
                        Re: Precedence Misunderstanding Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-18 21:07 +0100
                  Re: Precedence Misunderstanding Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-19 20:47 +0300
                Re: Precedence Misunderstanding Philip Lantz <prl@canterey.us> - 2012-07-18 23:54 -0700
                  Re: Precedence Misunderstanding Ike Naar <ike@sverige.freeshell.org> - 2012-07-19 07:21 +0000
        Re: Precedence Misunderstanding "BartC" <bc@freeuk.com> - 2012-07-17 20:42 +0100
        Re: Precedence Misunderstanding Willem <willem@toad.stack.nl> - 2012-07-17 20:38 +0000
          Re: Precedence Misunderstanding Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-19 20:54 +0300
            Re: Precedence Misunderstanding Willem <willem@toad.stack.nl> - 2012-07-19 22:02 +0000
        Re: Precedence Misunderstanding pete <pfiland@mindspring.com> - 2012-07-17 22:31 -0400
        Re: Precedence Misunderstanding Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-18 00:35 -0700
      Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-17 22:16 +0100
        Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-17 14:22 -0700
          Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 16:35 +0100
            Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 10:03 -0700
              Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 18:32 +0100
                Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 10:45 -0700
                  Re: Precedence Misunderstanding Rui Maciel <rui.maciel@gmail.com> - 2012-07-18 19:29 +0100
                    Re: Precedence Misunderstanding Ben Pfaff <blp@cs.stanford.edu> - 2012-07-18 11:45 -0700
                    Re: Precedence Misunderstanding Keith Thompson <kst-u@mib.org> - 2012-07-18 13:26 -0700
                    Re: Precedence Misunderstanding Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-19 00:51 -0700
                Re: Precedence Misunderstanding Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-19 00:11 -0700
    Re: Precedence Misunderstanding Robert Wessel <robertwessel2@yahoo.com> - 2012-07-17 00:05 -0500
    Re: Precedence Misunderstanding Ike Naar <ike@iceland.freeshell.org> - 2012-07-17 07:40 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#23368

Ben Bacarisse wrote:

> That's true as far as the "abstract machine" is concerned: i.e. the
> compiler must act *as if* the 'a' is evaluated, but unless 'a' is
> volatile, I'd expect a compiler to optimise it away.

You shouldn't expect it to, and a compiler better not do it.  Not only would 
it go against the standard, but there are also some techniques which it 
would break.  Consider, for example, the following:

<code>
#include <stdio.h>

int do_stuff(void)
{
   // do stuff
   if(succeeded)
      return 0;
   else
      return 42;
}

int expensive_operation_or_error_handling_function(void)
{
   fprintf(stderr,"an error occurred\n");
   return 42;
}

int main(void)
{
   do_stuff() || expensive_operation_or_error_handling_function();

   /*  // it is a bit easier on the eyes than:
   if(do_stuff())
   {
      expensive_operation_or_error_handling_function();
   }
   */
   
   return 0;
}
</code>


If the compiler optimizes this code so that the operator evaluates the 
expensive_operation_or_error_handling_function() prior to calling 
do_stuff(), do_stuff() might never be called.


Rui Maciel

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

#23372

Rui Maciel <rui.maciel@gmail.com> writes:

> Ben Bacarisse wrote:
>
>> That's true as far as the "abstract machine" is concerned: i.e. the
>> compiler must act *as if* the 'a' is evaluated, but unless 'a' is
>> volatile, I'd expect a compiler to optimise it away.
>
> You shouldn't expect it to, and a compiler better not do it.  Not only would 
> it go against the standard, but there are also some techniques which it 
> would break.  Consider, for example, the following:
>
> <code>
> #include <stdio.h>
>
> int do_stuff(void)
> {
>    // do stuff
>    if(succeeded)
>       return 0;
>    else
>       return 42;
> }
>
> int expensive_operation_or_error_handling_function(void)
> {
>    fprintf(stderr,"an error occurred\n");
>    return 42;
> }
>
> int main(void)
> {
>    do_stuff() || expensive_operation_or_error_handling_function();
>
>    /*  // it is a bit easier on the eyes than:
>    if(do_stuff())
>    {
>       expensive_operation_or_error_handling_function();
>    }
>    */
>    
>    return 0;
> }
> </code>
>
>
> If the compiler optimizes this code so that the operator evaluates the 
> expensive_operation_or_error_handling_function() prior to calling 
> do_stuff(), do_stuff() might never be called.

Eh?  I can't see any connection between this code and what I wrote.

-- 
Ben.

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

#23412

"BartC" <bc@freeuk.com> writes:

> "Ike Naar" <ike@iceland.freeshell.org> wrote in message
> news:slrn3vfsk0coir.5s0.ike@iceland.freeshell.org...
> > On 2012-07-18, Philip Lantz <prl@canterey.us> wrote:
> >> Ben Bacarisse wrote:
> >> [Referring to an expression containing only && and || operators]
> >>> an operand that is further to the right is never evaluated before one
> >>> to its left.
> >>
> >> Except when one to its left doesn't need to be evaluated.
> >>
> >> For example, in
> >>    (a || b) && c
> >> with a = 1, a is evaluated, b is not evaluated, and c is evaluated.
> >
> > It's not a counterexample to what Ben said.
> > Even in your example, no operand is evaluated before one to its left.
> 
> How about:
> 
>  a && 0
> 
> or:
> 
>  a || 1
> 
> a needn't be evaluated; but it is.

As if...

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#23390

Ike Naar wrote:
> 
> On 2012-07-18, Philip Lantz <prl@canterey.us> wrote:
> > Ben Bacarisse wrote:
> > [Referring to an expression containing only && and || operators]
> >> an operand that is further to the right is never evaluated before one
> >> to its left.
> >
> > Except when one to its left doesn't need to be evaluated.
> >
> > For example, in
> >    (a || b) && c
> > with a = 1, a is evaluated, b is not evaluated, and c is evaluated.
> 
> It's not a counterexample to what Ben said.
> Even in your example, no operand is evaluated before one to its left.

I guess you interpret the word "before" differently than I do.

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

#23392

On 2012-07-19, Philip Lantz <prl@canterey.us> wrote:
> Ike Naar wrote:
>> 
>> On 2012-07-18, Philip Lantz <prl@canterey.us> wrote:
>> > Ben Bacarisse wrote:
>> > [Referring to an expression containing only && and || operators]
>> >> an operand that is further to the right is never evaluated before one
>> >> to its left.
>> >
>> > Except when one to its left doesn't need to be evaluated.
>> >
>> > For example, in
>> >    (a || b) && c
>> > with a = 1, a is evaluated, b is not evaluated, and c is evaluated.
>> 
>> It's not a counterexample to what Ben said.
>> Even in your example, no operand is evaluated before one to its left.
>
> I guess you interpret the word "before" differently than I do.

I interpret it as "earlier in time". In the given example, a and c are
evaluated, and a is evaluated before c is. This is in accordance with
Ben's assertion that "an operand that is further to the right is never
evaluated before one to its left".
For the given example, I would interpret that assertion as:
-  the operands in left-to-right order are a, b, c.
-  b is not evaluated before a is (since b is not evaluated at all).
-  c is not evaluated before a is (since a is evaluated before c is).
-  c is not evaluated before b is (since b is not evaluated).

What is your interpretation?

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

#23343

"Charles Richmond" <numerist@aquaporin4.com> wrote in message 
news:ju4ba5$lso$1@dont-email.me...

> The crux of what I do *not* understand is this:
>
> Can someone explain how "&&" can have a *higher* precedence than
> "||"... when any series of AND's and OR's are just going to be
> done left to right???
>
> For example, if you have a long series of logical AND's and OR's like 
> this:
>
>    a && b || c || d && x && y || z
>
> How will "&&" having a higher precedence than "||" effect this at all??? 
> ISTM that evaluation would be the *same* if "&&" and "||" were of equal 
> precedence.
>
> Create any series of AND's and OR's you want, and please show me how the 
> precedence of "&&'" and "||" will make any difference under the current C 
> standard.

Your example:

( a && b || c || d && x && y || z)

might be written as follows, with parentheses added to show default 
structure**. The indices I've added are arbitrary:

((a and1 b) or2 c or3 ((d and4 x) and5 y) or6 z)

Or it can be written lisp-style like this:

(or6 (or3 (or2 (and1 a b) c) (and5 (and4 d x) y)) z)

You can see that evaluation would need to be 'bottom-up', rather than 
left-to-right, although they might sometimes correspond.

> Also ISTM that in the above expression, it will *not* matter if one adds 
> parentheses around any operator/operand pair or grouping.  The result 
> seems to be the same.  Please show me where I'm wrong.

Because of short-circuit evaluation, and because the result of such an 
expression is only ever going to be 0 or 1, it can be difficult to 
appreciate differences between one such logical expression and another.

(** I won't use the terms evaluation order, precedence, or associativity 
which are full of pit-falls.)

-- 
Bartc 

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

#23349

Charles Richmond wrote:
) The crux of what I do *not* understand is this:
)
) Can someone explain how "&&" can have a *higher* precedence than
) "||"... when any series of AND's and OR's are just going to be
) done left to right???

The precedence determines how the results *will be used*.
It does not determine the order in which they are evaluated.

) For example, if you have a long series of logical AND's and OR's like this:
)
)     a && b || c || d && x && y || z
)
) How will "&&" having a higher precedence than "||" effect this at all??? 

This is, step by step, what the program will do:

/* Construct for the expression  a && b || c || d && x && y || z */
int abcdxyz(int a, int b, int c, int d, int x, int y, int z)
{
  if (a) {
    if (b) {
      return 1;
    }
  }
  if (c) {
    return 1;
  }
  if (d) {
    if (x) {
      if (y) {
	return 1;
      }
    }
  }
  if (z) {
    return 1;
  }
  return 0;
}

Now, as you can see: a, b, c, d, x, y, z are evaluated in that order.

Suppose that '&&' had higher precedence, it would become the following:

/* Construct for the expression  a && b || c || d && x && y || z
 * with precedences reversed */
int abcdxyz(int a, int b, int c, int d, int x, int y, int z)
{
  if (!a) {
    return 0;
  }
  if (!b) {
    if (!c) {
      if (!d) {
	return 0;
      }
    }
  }
  if (!x) {
    return 0;
  }
  if (!y) {
    if (!z) {
      return 0;
    }
  }
  return 1;
}

As you can see, they are still evaluated in the same order, yet still they
are grouped differently.

) Create any series of AND's and OR's you want, and please show me how the 
) precedence of "&&'" and "||" will make any difference under the current C 
) standard.

See above.

) I can *not* understand how "&&" can have a higher precedence than "||"... 
) when it seems to make *no* difference in *any* expression I've seen.

  int a() { printf("a=0\n"); return 0; }
  int b() { printf("b=1\n"); return 1; }
  int c() { printf("c=1\n"); return 1; }
  int main() {
    printf("First\n");
    printf("Result: %d\n", (a() && b()) || c());
    printf("Second\n");
    printf("Result: %d\n", a() && (b() || c()));
    return 0;
  }

There you go.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#23413

Willem <willem@toad.stack.nl> writes:
> Charles Richmond wrote:
> ) The crux of what I do *not* understand is this:
> )
> ) Can someone explain how "&&" can have a *higher* precedence than
> ) "||"... when any series of AND's and OR's are just going to be
> ) done left to right???
> 
> The precedence determines how the results *will be used*.
> It does not determine the order in which they are evaluated.
> 
> ) For example, if you have a long series of logical AND's and OR's like this:
> )
> )     a && b || c || d && x && y || z
> )
> ) How will "&&" having a higher precedence than "||" effect this at all??? 
> 
> This is, step by step, what the program will do:
> 
> /* Construct for the expression  a && b || c || d && x && y || z */
> int abcdxyz(int a, int b, int c, int d, int x, int y, int z)
> {
>   if (a) {
>     if (b) {
>       return 1;
>     }
>   }
>   if (c) {
>     return 1;
>   }
>   if (d) {
>     if (x) {
>       if (y) {
> 	return 1;
>       }
>     }
>   }
>   if (z) {
>     return 1;
>   }
>   return 0;
> }
> 
> Now, as you can see: a, b, c, d, x, y, z are evaluated in that order.

It's possible to evaluate c when you've not evaluated b. There may be
a weak ordering, but I'm not sure a non-mathematical reading would 
include that as an interpretation.
 
> Suppose that '&&' had higher precedence, it would become the following:

s/&&/||/

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#23417

Phil Carmody wrote:
) Willem <willem@toad.stack.nl> writes:
)> This is, step by step, what the program will do:
)> 
)> /* Construct for the expression  a && b || c || d && x && y || z */
)> int abcdxyz(int a, int b, int c, int d, int x, int y, int z)
)> {
)>   if (a) {
)>     if (b) {
)>       return 1;
)>     }
)>   }
)>   if (c) {
)>     return 1;
)>   }
)>   if (d) {
)>     if (x) {
)>       if (y) {
)>         return 1;
)>       }
)>     }
)>   }
)>   if (z) {
)>     return 1;
)>   }
)>   return 0;
)> }
)> 
)> Now, as you can see: a, b, c, d, x, y, z are evaluated in that order.
)
) It's possible to evaluate c when you've not evaluated b. There may be
) a weak ordering, but I'm not sure a non-mathematical reading would 
) include that as an interpretation.

Yes, I wrote that piece of code to demonstrate exactly what will
happen, precisely because english wording tends to be so ambiguous.

You can either try to precisify the wording, or you can write in code.

)> Suppose that '&&' had higher precedence, it would become the following:
)
) s/&&/||/

Good catch.  Or s/higher/lower/, of course.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#23353

Charles Richmond wrote:
 
> I can *not* understand how "&&" 
> can have a higher precedence than "||"...
> when it seems to make *no* difference in *any* expression I've seen.

Here's a counter example, which shows that 
    a || b  && c
is different from    
   (a || b) && c


/* BEGIN new.c output */

a

ac

/* END new.c output */




/* BEGIN new.c */

#include <stdio.h>

#define a  printf("a") 
#define b (printf("b") - 1)
#define c    puts("c")

int 
main(void)
{
    puts("/* BEGIN new.c output */\n");

     a || b  && c;

     puts("\n");

    (a || b) && c;

    puts("\n/* END new.c output */\n");
    return 0;
}



/* END new.c */

-- 
pete

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

#23356

On Jul 17, 7:35 pm, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
> "Ben Pfaff" <b...@cs.stanford.edu> wrote in message
> news:874np7j8br.fsf@blp.benpfaff.org...
> > Charles Richmond <friz...@aquaporin4.com> writes:

> >> Can someone explain how "&&" can have a *higher* precedence than
> >> "||"... when the series of AND's and OR's are just going to be done
> >> left to right???

<snip>

> > Consider 2 * 3 + 4 * 5.  Precedence says that this must be
> > treated the same as (2 * 3) + (4 * 5).  But once you figure that
> > out, you have a choice: you can evaluate 2 * 3 first or you can
> > evaluate 4 * 5 first, because the order doesn't matter.  No one
> > bothers to say that you have to evaluate left-to-right or even
> > that you have to evaluate right-to-left, because that would not
> > change the eventual result in any way.
>
> > When side effects come in, the situation changes.  a() + b()
> > might do something completely different depending on which of a()
> > or b() you call first.  Extending it to a() + b() * c(), then
> > precedence comes in.  C doesn't say in what order a(), b(), and
> > c() are evaluated, but it does say that once they are evaluated,
> > you have to multiply b() by c(), not by a().
>
> Mr. Pfaff, I *do* understand about "side effects" with expression evaluation
> in programming languages.  I understand *why* short circuiting and
> guaranteeing the order of execution... *can* be helpful at times.
>
> The crux of what I do *not* understand is this:
>
> Can someone explain how "&&" can have a *higher* precedence than
> "||"... when any series of AND's and OR's are just going to be
> done left to right???

precedencde determines how the expressions are grouped

A || B && C means A || (B && C) not (A || B) && C

suppose A=T B=F C=?
in the first case the result is determind once A is found to be true
in
the second we have to evaulate C to find the result.


> For example, if you have a long series of logical AND's and OR's like this:
>
>     a && b || c || d && x && y || z
>
> How will "&&" having a higher precedence than "||" effect this at all???
> ISTM that evaluation would be the *same* if "&&" and "||" were of equal
> precedence.
>
> Create any series of AND's and OR's you want, and please show me how the
> precedence of "&&'" and "||" will make any difference under the current C
> standard.
>
> Also ISTM that in the above expression, it will *not* matter if one adds
> parentheses around any operator/operand pair or grouping.  The result seems
> to be the same.  Please show me where I'm wrong.

pretty much any expression involving && and || has this property...

> I can *not* understand how "&&" can have a higher precedence than "||"...
> when it seems to make *no* difference in *any* expression I've seen.

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

#23351

Ben Pfaff wrote:

> I think there's a lot of confusion on this point because we
> aren't taught about this in our math classes.  That's because
> side effects don't exist in math, so order of evaluation doesn't
> matter.  Precedence does, but that's a different issue.
<snip/>

This is nonsense.  What you refer as being "side effects" is nothing more 
than the result of ignoring an entire subspace of an operator's domain, and 
how the components of the subspace you chose to ignore can also influence 
how the remaining components are mapped.


Rui Maciel

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

#23352

Rui Maciel <rui.maciel@gmail.com> writes:

> Ben Pfaff wrote:
>
>> I think there's a lot of confusion on this point because we
>> aren't taught about this in our math classes.  That's because
>> side effects don't exist in math, so order of evaluation doesn't
>> matter.  Precedence does, but that's a different issue.
> <snip/>
>
> This is nonsense.  What you refer as being "side effects" is nothing more 
> than the result of ignoring an entire subspace of an operator's domain, and 
> how the components of the subspace you chose to ignore can also influence 
> how the remaining components are mapped.

Can you expand on that?  It sounds like you are referring to
linear algebra or other mathematical concepts, but I do not know
how they apply in this situation.

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

#23361

Ben Pfaff wrote:

> Can you expand on that?  It sounds like you are referring to
> linear algebra or other mathematical concepts, but I do not know
> how they apply in this situation.

Consider floating point operations.  When a floating-point exception is 
raised, the corresponding floating-point status flag is set.  This is 
described as a "side-effect" of exceptional floating-point operations.  

So, although conceptually we may perceive these operators as mapping a set 
of floating-point values to a floating-point value, they actually map a set 
of floating-point values to a tuple formed by a floating-point value and a 
fenv_t state.  More specifically, instead of performing a map similar to:

{float x, float y} -> operator(x,y) \in {float}

...these operators actually are similar to:

{float x, float y} -> operator(x,y) \in {float, fenv_t}

So, in this example, just because, conceptually, we tend to ignore the 
fenv_t type, it doesn't mean it doesn't exist or that it isn't a part of 
these operators' co-domain.  It does, and although it tends to be swept 
under the proverbial rug, it is very much an integral part of the definition 
of these floating-point operators.  

The same also happens with elements which are a part of an operator's domain 
but are ignored by a programmer.  If the outcome of an operator depends on 
some state then the state that influences this outcome, along with any flag 
that might be set in the process, are naturally a part of these operators' 
domain and co-domain.  Not being aware of these elements or how they 
influence the outcome of a computation doesn't mean that there is a hole in 
basic algebra or in lambda calculus.


Rui Maciel

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

#23363

Rui Maciel <rui.maciel@gmail.com> writes:

> Ben Pfaff wrote:
>
>> Can you expand on that?  It sounds like you are referring to
>> linear algebra or other mathematical concepts, but I do not know
>> how they apply in this situation.
>
> Consider floating point operations.  When a floating-point exception is 
> raised, the corresponding floating-point status flag is set.  This is 
> described as a "side-effect" of exceptional floating-point operations.  
>
> So, although conceptually we may perceive these operators as mapping a set 
> of floating-point values to a floating-point value, they actually map a set 
> of floating-point values to a tuple formed by a floating-point value and a 
> fenv_t state.  More specifically, instead of performing a map similar to:
>
> {float x, float y} -> operator(x,y) \in {float}
>
> ...these operators actually are similar to:
>
> {float x, float y} -> operator(x,y) \in {float, fenv_t}
>
> So, in this example, just because, conceptually, we tend to ignore the 
> fenv_t type, it doesn't mean it doesn't exist or that it isn't a part of 
> these operators' co-domain.  It does, and although it tends to be swept 
> under the proverbial rug, it is very much an integral part of the definition 
> of these floating-point operators.  
>
> The same also happens with elements which are a part of an operator's domain 
> but are ignored by a programmer.  If the outcome of an operator depends on 
> some state then the state that influences this outcome, along with any flag 
> that might be set in the process, are naturally a part of these operators' 
> domain and co-domain.  Not being aware of these elements or how they 
> influence the outcome of a computation doesn't mean that there is a hole in 
> basic algebra or in lambda calculus.

I didn't say that there was a hole in basic algebra or lambda
calculus.  I said that "we aren't taught about [side effects] in
our math classes" and "That's because side effects don't exist in
math."  I stand by those remarks: in the years of math classes
that I took, side effects never came up.  If I had spoken up in a
math class, saying "But what about side effects?", no one would
have understood what I was talking about.

Math textbooks don't tell you that you have to evaluate the
terminals from left to right, or in any other order, since the
order of evaluation just doesn't matter without introducing side
effects.

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

#23366

Ben Pfaff wrote:

> I didn't say that there was a hole in basic algebra or lambda
> calculus.  I said that "we aren't taught about [side effects] in
> our math classes" and "That's because side effects don't exist in
> math."  I stand by those remarks: in the years of math classes
> that I took, side effects never came up.  If I had spoken up in a
> math class, saying "But what about side effects?", no one would
> have understood what I was talking about.

As I've said, these "side effects" you mentioned clearly do "exist in math", 
and are covered right in basic algebra.  If your math classes covered the 
basic definition of a function then you obviously did covered them.  

I suspect that the only reason you claim otherwise is that you may not be 
aware that "side effects" are nothing more than operands and values of any 
given operator which you've ignored, and as a consequence you aren't aware 
that they are a part of an operator's domain and/or co-domain and how they 
influence the result of an operation.


> Math textbooks don't tell you that you have to evaluate the
> terminals from left to right, or in any other order, since the
> order of evaluation just doesn't matter without introducing side
> effects.

You are confusing things.  The operators in "math textbooks" are not the 
same as operators in C.  You don't see any operator defined in a "math 
textbook" that includes a fenv_t element in its domain or co-domain, nor 
does the real numbers set includes overflow or NaN values and flags.  
Floating point numbers may have been defined to represent real numbers, and 
floating point operators may have been defined to represent a set of 
mathematical operators but that doesn't mean they are the same.  


Rui Maciel

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

#23367

Rui Maciel <rui.maciel@gmail.com> writes:

> Ben Pfaff wrote:
>
>> I didn't say that there was a hole in basic algebra or lambda
>> calculus.  I said that "we aren't taught about [side effects] in
>> our math classes" and "That's because side effects don't exist in
>> math."  I stand by those remarks: in the years of math classes
>> that I took, side effects never came up.  If I had spoken up in a
>> math class, saying "But what about side effects?", no one would
>> have understood what I was talking about.
>
> As I've said, these "side effects" you mentioned clearly do "exist in math", 
> and are covered right in basic algebra.  If your math classes covered the 
> basic definition of a function then you obviously did covered them.  

The article I replied to talked about floating-point numbers and
fenv_t.  Certainly that's not covered in basic algebra.  Are you
referring to some other article?

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

#23370

Ben Pfaff wrote:

> The article I replied to talked about floating-point numbers and
> fenv_t.  Certainly that's not covered in basic algebra.  Are you
> referring to some other article?

Algebra is a branch of mathematics which covers operators and relations 
between sets.  These sets aren't limited to the real numbers set, and the 
operators aren't limited to the basic mathematical operators that take real 
values as operands.  In fact, typically the first contact with algebra tends 
not to involve real numbers at all, or basic math operators.  Take, for 
example, how Venn diagrams tend to be presented in kindergarten.

Regarding "side effects", the concepts which I've referred to are indeed 
covered, and they tend to be covered right in the very first explanation of 
what a function is supposed to be.  Once you were taught that a function f 
maps elements in a set A to elements in a set B, you covered all the math 
that is needed to explain and understand "side effects".  No new math is 
needed to describe a function assigning a certain value to a flag, or 
returning a different value depending on the value stored in any other flag.


Rui Maciel

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

#23371

Rui Maciel <rui.maciel@gmail.com> writes:

> Ben Pfaff wrote:
>
>> The article I replied to talked about floating-point numbers and
>> fenv_t.  Certainly that's not covered in basic algebra.  Are you
>> referring to some other article?
>
> Algebra is a branch of mathematics which covers operators and relations 
> between sets.  These sets aren't limited to the real numbers set, and the 
> operators aren't limited to the basic mathematical operators that take real 
> values as operands.  In fact, typically the first contact with algebra tends 
> not to involve real numbers at all, or basic math operators.  Take, for 
> example, how Venn diagrams tend to be presented in kindergarten.
>
> Regarding "side effects", the concepts which I've referred to are indeed 
> covered, and they tend to be covered right in the very first explanation of 
> what a function is supposed to be.  Once you were taught that a function f 
> maps elements in a set A to elements in a set B, you covered all the math 
> that is needed to explain and understand "side effects".  No new math is 
> needed to describe a function assigning a certain value to a flag, or 
> returning a different value depending on the value stored in any other flag.

Your math classes must have been very different from mine.

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

#23373

Rui Maciel <rui.maciel@gmail.com> writes:
> Ben Pfaff wrote:
>> The article I replied to talked about floating-point numbers and
>> fenv_t.  Certainly that's not covered in basic algebra.  Are you
>> referring to some other article?
>
> Algebra is a branch of mathematics which covers operators and relations 
> between sets.  These sets aren't limited to the real numbers set, and the 
> operators aren't limited to the basic mathematical operators that take real 
> values as operands.  In fact, typically the first contact with algebra tends 
> not to involve real numbers at all, or basic math operators.  Take, for 
> example, how Venn diagrams tend to be presented in kindergarten.
>
> Regarding "side effects", the concepts which I've referred to are indeed 
> covered, and they tend to be covered right in the very first explanation of 
> what a function is supposed to be.  Once you were taught that a function f 
> maps elements in a set A to elements in a set B, you covered all the math 
> that is needed to explain and understand "side effects".  No new math is 
> needed to describe a function assigning a certain value to a flag, or 
> returning a different value depending on the value stored in any other flag.

In my experience, a mathematical operator or function takes zero
or more operands and yields a value. The operands/arguments are
members of your "set A", and the result is a member of your "set B"
(either of which may or may not be numbers).

If an operator had "side effects" in the C sense, then those side
effects would normally be described as part of the result.

In C, side effects are effects (changes of state) involving something
other than the result of the function or operator. I have not seen
a similar concept applied in mathematics; instead, any such effects
are part of the result (since mathematics is not limited by C's
type system). For example, a mathematical function's result might
be the entire state of a machine, if that's what it's modelling --
and in that case I wouldn't call anything that's part of the machine
state a "side effect".

Do you have a specific concrete example of "side effects" in basic
mathematics?

--  
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web