SIGN

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.

Phillip Helbig---undress to reply <helbig@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.

It might have to do with the instructions available on the 704.
(Which is a sign-magnitude machine, if that matters.)

-- glen

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
expensive multiplication for this case.

> Does anyone have a real-life example which indicates WHY the SIGN
> function is defined as it is?
>

Most "real-life examples" are coded under the early Cray influence,
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.

In article <9utqilFlgU1@mid.individual.net>, Tim Prince
<tim@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
solution?

Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
> In article <9utqilFlgU1@mid.individual.net>, Tim Prince
> <tim@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
> solution?

In most cases, MERGE has different uses.

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

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.
....

"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?

--