POV-Ray : Newsgroups : povray.beta-test : the umpteenth time: removed features :( Server Time
29 Jul 2024 16:26:45 EDT (-0400)
  the umpteenth time: removed features :( (Message 31 to 36 of 36)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Warp
Subject: Re: Doc: hat still in 6.5.4.2 (possibly elsewhere)
Date: 24 Jun 2002 15:03:42
Message: <3d176d0e@news.povray.org>
andrel linnenbank <a.c### [at] amcuvanl> wrote:
> Whoops sorry, a more correct expample would be 
> 2*2/2*2 
> which is 1 in Holland.

  Then you should not use programming languages like C, C++ or Java... ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: andrel linnenbank
Subject: Re: Doc: hat still in 6.5.4.2 (possibly elsewhere)
Date: 24 Jun 2002 16:39:12
Message: <3D17839F.9A35DEAF@amc.uva.nl>
Warp wrote:
> 
> andrel linnenbank <a.c### [at] amcuvanl> wrote:
> > Whoops sorry, a more correct expample would be
> > 2*2/2*2
> > which is 1 in Holland.
> 
>   Then you should not use programming languages like C, C++ or Java... ;)
What about POV?
In fact it is very simple: if you write a half as 0.5 then use one set
of precedence rules and if you write 0,5 use the dutch rules :)
(well at least that mostly works while staying in Holland)

	Andrel	

> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: Jaap Frank
Subject: Re: Doc: hat still in 6.5.4.2 (possibly elsewhere)
Date: 24 Jun 2002 17:30:30
Message: <3d178f76$1@news.povray.org>
"andrel linnenbank" <a.c### [at] amcuvanl> wrote in message
news:3D1767A2.B71AB835@amc.uva.nl...
>
> > > As a further note, precedence is always a difficult thing. There are
> > > even variations between countries. In Holland the precedence rules are
> > > that the order for binary operators is: ^ * / + - and none has the
same
> > > precedence. So 2*4/2 is 4 not 1 When something unexpected happens I
> > > always check precedence and use superfluous parenthesis, just to be
sure
> >
> > How could that equal 1? I don't see any precedence rule that could
produce
> > that result...it either comes out to 8/2 or 2*2. Or +-: 2 + 3 - 5 = 0
> > whether you do the addition or subtraction first.
> Whoops sorry, a more correct expample would be
> 2*2/2*2
> which is 1 in Holland. it parses as (2*2)/(2*2) and 4 in some other
> countries where they parse it as ((2*2)/2)*2
>
> Thank for pointing out, now I feel realy silly :)
>
> Andrel

Hello,

I'm sorry, but I don't agree with Andrel. I'm a Dutch teacher and I have
never heard
about this kind of precedence. The '*' and  the '/' have equal precedence,
so
they parse in the order of appearance. The same rules applies to '+' and
'-'.
If he had learned it this way, then that was wrong. Mathematics have the
same rules
all over the world!!

Greetings,

--
Jaap Frank


Post a reply to this message

From: Mark Wagner
Subject: Re: Doc: hat still in 6.5.4.2 (possibly elsewhere)
Date: 25 Jun 2002 02:17:45
Message: <3d180b09@news.povray.org>
andrel linnenbank wrote in message <3D1767A2.B71AB835@amc.uva.nl>...
>
>> > As a further note, precedence is always a difficult thing. There are
>> > even variations between countries. In Holland the precedence rules are
>> > that the order for binary operators is: ^ * / + - and none has the same
>> > precedence. So 2*4/2 is 4 not 1 When something unexpected happens I
>> > always check precedence and use superfluous parenthesis, just to be
sure
>>
>> How could that equal 1? I don't see any precedence rule that could
produce
>> that result...it either comes out to 8/2 or 2*2. Or +-: 2 + 3 - 5 = 0
>> whether you do the addition or subtraction first.
>Whoops sorry, a more correct expample would be
>2*2/2*2
>which is 1 in Holland. it parses as (2*2)/(2*2) and 4 in some other
>countries where they parse it as ((2*2)/2)*2


This is what I like about postfix notation: 2 2 * 2 / 2 * is unambiguously
4.

--
Mark

The Universe is expanding.
The budget for its exploration is shrinking.


Post a reply to this message

From: Christopher James Huff
Subject: Re: Doc: hat still in 6.5.4.2 (possibly elsewhere)
Date: 25 Jun 2002 10:33:58
Message: <pan.2002.06.25.09.33.38.700649.635@mac.com>
On Tue, 25 Jun 2002 02:18:15 -0500, Mark Wagner wrote:

> This is what I like about postfix notation: 2 2 * 2 / 2 * is
> unambiguously 4.

Have fun convincing anyone to use that... ;-)

Really, it seems like a tree would be a better representation than any
linear string:

      4
      =
      *
    /   2
  *   2
2   2

However, that makes it a bit difficult to write and takes up a lot of
room, and doesn't really work well anyway with plain text, maybe we can
use some kind of notation to let it all fit on a line and be easy to
type...I know, lets use () marks to enclose each branch: (((2*2)/2)*2)

Typing all those () is a pain though, maybe make some simple rules for
which operations to do first, people can still use () to force a different
order or clarify the meaning when needed. ;-)


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/


Post a reply to this message

From: TinCanMan
Subject: Re: Doc: hat still in 6.5.4.2 (possibly elsewhere)
Date: 25 Jun 2002 10:43:32
Message: <3d188194$1@news.povray.org>
> Typing all those () is a pain though, maybe make some simple rules for
> which operations to do first, people can still use () to force a different
> order or clarify the meaning when needed. ;-)

In spite of this thread going on too long I have to add my 2 pennies.  I
have kikved by BEDMAS since grade school and whenever I am in doubt on how
the equation will be interpreted, I add brackets.


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.