Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SIGN
22 views
Skip to first unread message
Phillip Helbig---undress to reply
Apr 14, 2012, 11:38:32 AM4/14/12
to
SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B >= 0 and -1
if B < 0.
It seems to me it would be simpler to define it with just one argument,
i.e. like "sgn" above.
Presumably there is a reason why this is not the case. What is it?
One possible reason would be that there are common situations where the
definition would make for more compact code, but I find that it makes
for less compact code.
I could see the point if it were defined as A*sgn(B), i.e. instead of
multiplying a quantity by the sign function we have the quantity as the
first argument, but that is not the case.
Consider the following (real-example) code (bonus points if you can
guess what it is for). OMEGA is always >=0, LAMBDA is unrestricted and
K = OMEGA + LAMBDA - 1. (Thus the limit for LAMBDA=0 and K=0 should be
infinity, right?)
ALPHA = SIGN(1,K)*27*OMEGA**2*LAMBDA/(4*K**3) !K=0 handled separately
To me, it would make more sense to write
ALPHA = SIGN(27*OMEGA**2*LAMBDA/(4*K**3),K) !K=0 handled separately
but that is not how it works.
Does anyone have a real-life example which indicates WHY the SIGN
function is defined as it is?
The first example above is what is required. This leads to ALPHA being
positive if LAMBDA is. IN THIS PARTICULAR CASE, I could then write
ALPHA = SIGN(27*OMEGA**2*LAMBDA/(4*K**3),LAMBDA)
and get the desired result, but such a transformation is of course not
always possible. In general I find that the definition of SIGN leads to
less compact, not more compact, code.
if B < 0.
It seems to me it would be simpler to define it with just one argument,
i.e. like "sgn" above.
Presumably there is a reason why this is not the case. What is it?
One possible reason would be that there are common situations where the
definition would make for more compact code, but I find that it makes
for less compact code.
I could see the point if it were defined as A*sgn(B), i.e. instead of
multiplying a quantity by the sign function we have the quantity as the
first argument, but that is not the case.
Consider the following (real-example) code (bonus points if you can
guess what it is for). OMEGA is always >=0, LAMBDA is unrestricted and
K = OMEGA + LAMBDA - 1. (Thus the limit for LAMBDA=0 and K=0 should be
infinity, right?)
ALPHA = SIGN(1,K)*27*OMEGA**2*LAMBDA/(4*K**3) !K=0 handled separately
To me, it would make more sense to write
ALPHA = SIGN(27*OMEGA**2*LAMBDA/(4*K**3),K) !K=0 handled separately
but that is not how it works.
Does anyone have a real-life example which indicates WHY the SIGN
function is defined as it is?
The first example above is what is required. This leads to ALPHA being
positive if LAMBDA is. IN THIS PARTICULAR CASE, I could then write
ALPHA = SIGN(27*OMEGA**2*LAMBDA/(4*K**3),LAMBDA)
and get the desired result, but such a transformation is of course not
always possible. In general I find that the definition of SIGN leads to
less compact, not more compact, code.
glen herrmannsfeldt
Apr 14, 2012, 12:05:00 PM4/14/12
to
Phillip Helbig---undress to reply <hel...@astro.multiclothesvax.de> wrote:
> SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B >= 0 and -1
> if B < 0.
> It seems to me it would be simpler to define it with just one argument,
> i.e. like "sgn" above.
> Presumably there is a reason why this is not the case. What is it?
As far as I know, it has always been that way back to Fortran I.
> SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B >= 0 and -1
> if B < 0.
> It seems to me it would be simpler to define it with just one argument,
> i.e. like "sgn" above.
> Presumably there is a reason why this is not the case. What is it?
It might have to do with the instructions available on the 704.
(Which is a sign-magnitude machine, if that matters.)
-- glen
Tim Prince
Apr 14, 2012, 1:31:00 PM4/14/12
to
On 04/14/2012 11:38 AM, Phillip Helbig---undress to reply wrote:
> SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B>= 0 and -1
> if B< 0.
>
> It seems to me it would be simpler to define it with just one argument,
> i.e. like "sgn" above.
>
> Presumably there is a reason why this is not the case. What is it?
>
Back then, probably no one wanted to tackle optimizing around an
> SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B>= 0 and -1
> if B< 0.
>
> It seems to me it would be simpler to define it with just one argument,
> i.e. like "sgn" above.
>
> Presumably there is a reason why this is not the case. What is it?
>
expensive multiplication for this case.
> Does anyone have a real-life example which indicates WHY the SIGN
> function is defined as it is?
>
where SIGN was the only Fortran intrinsic which could be employed to
vectorize conditionals. MERGE has become widely available only in the
last 2 decades. I don't know whether you're asking for a justification
for SIGN to remain as it was historically without taking history into
account.
Phillip Helbig---undress to reply
Apr 14, 2012, 6:54:56 PM4/14/12
to
In article <9utqi...@mid.individual.net>, Tim Prince
solution?
<t...@nospamcomputer.org> writes:
> MERGE has become widely available only in the
> last 2 decades. I don't know whether you're asking for a justification
> for SIGN to remain as it was historically without taking history into
> account.
I just want to understand the history. Would MERGE offer a better
> MERGE has become widely available only in the
> last 2 decades. I don't know whether you're asking for a justification
> for SIGN to remain as it was historically without taking history into
> account.
solution?
glen herrmannsfeldt
Apr 14, 2012, 7:50:09 PM4/14/12
to
Phillip Helbig---undress to reply <hel...@astro.multiclothesvax.de> wrote:
SIGN goes back to at least Fortran II, when it would have been
called SIGNF.
Note that on sign-magnitude machines, it can be done by just replacing
the sign bit with the sign bit from another register.
Manuals for the instruction set of the 704 and 709 are available.
I believe that there is some work toward running IBSYS and the
Fortran II compiler on emulated 7090s. It would then be possible
to compiler a program using SIGNF or XSIGNF and see the generated
code. (The 704 through 7094 are sign magnitude in both fixed
and floating point.)
For extra challenge, someone should write a Fortran 90 compiler
for the 7090. (Too much to ask for 2003 or 2008.)
-- glen
dpb
Apr 14, 2012, 8:24:31 PM4/14/12
to
On 4/14/2012 10:38 AM, Phillip Helbig---undress to reply wrote:
> SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B>= 0 and -1
> if B< 0.
>
> It seems to me it would be simpler to define it with just one argument,
> i.e. like "sgn" above.
>
> Presumably there is a reason why this is not the case. What is it?
>
> One possible reason would be that there are common situations where the
> definition would make for more compact code, but I find that it makes
> for less compact code.
>
> I could see the point if it were defined as A*sgn(B), i.e. instead of
> multiplying a quantity by the sign function we have the quantity as the
> first argument, but that is not the case.
...
> SIGN(A,B) is defined as ABS(A)*sgn(B) where sgn(B) is 1 if B>= 0 and -1
> if B< 0.
>
> It seems to me it would be simpler to define it with just one argument,
> i.e. like "sgn" above.
>
> Presumably there is a reason why this is not the case. What is it?
>
> One possible reason would be that there are common situations where the
> definition would make for more compact code, but I find that it makes
> for less compact code.
>
> I could see the point if it were defined as A*sgn(B), i.e. instead of
> multiplying a quantity by the sign function we have the quantity as the
> first argument, but that is not the case.
"Why" I've no insight on other than "because".
If it bugs you sufficiently, why not write a function that does work as
you wish?
--
0 new messages