![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Mark Gordon
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 3 Aug 2000 20:22:50
Message: <398A0D84.245410EE@mailbag.com>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
pk wrote:
> In most programming languages, they assign a value to TRUE, and another
> to FALSE(in the case above, FALSE=0, and TRUE=NOT(FALSE) )
> In other languages, fe, C(for which i dont't really remember the
> standard), it's something like TRUE = -1 (binary 11111111) and FALSE
> would be 0(binary 00000000)...
And then there are the Unix shells...
$ true
$ echo $?
0
$ false
$ echo $?
1
Just to keep everyone confused. ;-)
-Mark Gordon
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mark Gordon wrote:
> And then there are the Unix shells...
>
> $ true
> $ echo $?
> 0
> $ false
> $ echo $?
> 1
>
> Just to keep everyone confused. ;-)
They teach you that at Siggraph 2000 ?
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 4 Aug 2000 05:51:21
Message: <398a9219@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Peter Popov <pet### [at] usa net> wrote:
: Why am I thinking that this issue has not been standardised yet?
What do you mean?
It is clearly stated in the C and C++ standards.
If you mean that there's no common standard for all programming languages,
that's only good. If in a specific programming language it's a lot more
natural to state that 'false' is -1 (for example for speed reasons), then
there's no reason to force it to be anything else.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 4 Aug 2000 05:59:05
Message: <398a93e8@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Dick Balaska <dic### [at] buckosoft com> wrote:
: I have also seen #define TRUE ~FALSE
This is horrible. It doesn't work!
Suppose we have:
#define FALSE 0
#define TRUE ~FALSE
Then TRUE will be -1 (ie. all bits set).
Now suppose we want to add a "boolean" type:
typedef int BOOL;
This will NOT work as it should:
int x=2, y=2;
BOOL b;
b = (x==y);
if(b == TRUE)
puts("Equal");
else
puts("Different");
This will print "Different" although x and y are equal.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 4 Aug 2000 06:05:03
Message: <398a954f@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
pk <thi### [at] videotron ca> wrote:
: What do you mean? Isosurfaces are booleans for me: at location <x, y,
: z>, there's a point(true, or 1), or there isn't any(false or 0)... So,
: you have a function that draw a plane, and another one that draws a
: sphere...
: You AND them... the result? a circle... You & them... the result? a
: circle...
Well, here you are thinking about the set theory union. This has little to
do with the logical and-operator.
And besides, the logical and-operator in programming languages has lower
precedence than + and - anyways. So in either way you want to think about it,
the current implementation is wrong.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Vahur Krouverk
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 4 Aug 2000 06:25:44
Message: <398A9A4E.24B1018A@aetec.ee>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>
> Dick Balaska <dic### [at] buckosoft com> wrote:
> : I have also seen #define TRUE ~FALSE
>
> This is horrible. It doesn't work!
>
> Suppose we have:
>
> #define FALSE 0
> #define TRUE ~FALSE
>
> Then TRUE will be -1 (ie. all bits set).
>
> Now suppose we want to add a "boolean" type:
>
> typedef int BOOL;
>
> This will NOT work as it should:
>
> int x=2, y=2;
> BOOL b;
>
> b = (x==y);
>
> if(b == TRUE)
> puts("Equal");
> else
> puts("Different");
>
> This will print "Different" although x and y are equal.
>
It is generally not good idea to compare against #define-d TRUE anyhow.
Better is to use != FALSE (although it is not very readable with its
double negative. Fortunately with C++ bool type this shouldn't be issue
any more.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Dick Balaska
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 6 Aug 2000 02:14:37
Message: <398D0212.8F73338E@buckosoft.com>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>
> Dick Balaska <dic### [at] buckosoft com> wrote:
> : I have also seen #define TRUE ~FALSE
>
> This is horrible. It doesn't work!
>
> Suppose we have:
>
> #define FALSE 0
> #define TRUE ~FALSE
>
> Then TRUE will be -1 (ie. all bits set).
>
> Now suppose we want to add a "boolean" type:
>
> typedef int BOOL;
>
> This will NOT work as it should:
>
> int x=2, y=2;
> BOOL b;
>
> b = (x==y);
>
> if(b == TRUE)
> puts("Equal");
> else
> puts("Different");
>
> This will print "Different" although x and y are equal.
You are a young pup.
And you are correct that this doesn't work on 2000 C compilers
because the (user) definition of TRUE doesn't match the system
definition.
But suppose you are working on a 6502 :) or a PDP-11, which can
deal with a -1 much easier than a 1; then it makes sense.
The PDP-11 is big-endian, so when you truncate a 1, you get 0
like down casting from int to word to char. The -1 always stayed
consistent across casts.
dik
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 6 Aug 2000 10:47:36
Message: <398d7a88@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Dick Balaska <dic### [at] buckosoft com> wrote:
: But suppose you are working on a 6502 :) or a PDP-11, which can
: deal with a -1 much easier than a 1; then it makes sense.
: The PDP-11 is big-endian, so when you truncate a 1, you get 0
: like down casting from int to word to char. The -1 always stayed
: consistent across casts.
This can't work this way. If it did, then if you make this:
char c = 1;
the variable 'c' will have the value 0.
'1' is of type int.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thorsten Froehlich
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 6 Aug 2000 14:41:17
Message: <398db14d@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <398d7a88@news.povray.org> , Warp <war### [at] tag povray org> wrote:
> This can't work this way. If it did, then if you make this:
>
> char c = 1;
>
> the variable 'c' will have the value 0.
>
> '1' is of type int.
Sorry, but you are misunderstanding the concepts here: You have to view the
problem on a lower level than the C programming language. You have to look
at the hardware: In case of a memory based CPU architecture, an access to a
int casted to a char will have certain side effects that are usually
"hidden" by a compiler, however, especially in the early days of C it was
common to use the knowledge about the CPU the code would run on to increase
speed.
Even today you can use this trick of CPU dependency, i.e. when you want to
determine the endianess on the fly - simply cast an pointer to an int to a
char and look at the result on different architectures. After all, C
explicitly allows low level programming; this makes it such an popular
language for implementing operating systems and embedded applications.
A good textbook explaining such issues is "Computer Organization and Design:
The Hardware/Software Interface" (ISBN 1558604286). It uses the original
(32 bit) MIPS architecture as example for the assembler code (and there is a
software emulator of a simple MIPS system available - even one that runs on
Solaris). It also explains how high-level language constructs are actually
implemented on the assembly level. This is in particular useful if you want
to write efficient C/C++ code.
The only negative point is the US$80 price tag. Anyway, it is available
even in a lot of European university libraries. Alternatively, there will
surely be a lot of similar, but older books (usually covering the 68000 CPU
architecture) available in next to any library.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Dick Balaska
Subject: Re: Why & has higher precedence than + or - in isosurface functions?
Date: 6 Aug 2000 20:39:41
Message: <398E0511.E784637@buckosoft.com>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
>
> This can't work this way. If it did, then if you make this:
It works. It wasn't pretty.
On x86, if you lay out 0x01020304 in memory, it becomes
04 03 02 01 which is what you are used to.
if you read this as a (32 bit) int then you get back your 0x01020304.
Reading it as a char you get 0x04.
So using TRUE=1 flows naturally with this scheme.
01 00 00 00 is 1 whether read as 8 or 32 bits.
But on a big endian machine, i=0x01020304 is laid out
01 02 03 04. So if you read (char)i you get 01.
So if (int)i = TRUE=1 or 00 00 00 01, then reading (char)i gives you 0.
So (int)i = TRUE = -1 or FF FF FF FF, gives you non-zero in any size.
Like i said, these were the old days. Now i believe on Sparcs and 680x0
there is an implied offset, such that (char)i is read as *((char)i)+3).
Hmm, that seems even weirder; what would ((char)i)+1) give you.
Beats me. So i took a jaunt through my old K&R and there is no mention
anywhere of TRUE, FALSE, BOOL or boolean. It does mention that UNIX
is 16000 lines of C :) and that the assignment
int i 1; /* is legal but deprecated */
Also, the equivilant of += and -= , which is =+ and =- is now frowned upon
for obvious reasons. x =-1;
Old book.
dik
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |