(j3.2006) BEQ, BNE?

[Keith Bierman]

Thanks for sleuthing out f95

I have no recollection of why we added integer +-0 as new text at that time
Keith Bierman (nook)

Bill Long <longb at cray.com> wrote:




On 1/31/13 5:30 PM, Keith Bierman wrote:
> http://www.nasdaq.com/symbol/altr ?
>
> Using their fpga engines one could certainly build such a processor
> As far as I recall their library elements and premade chips don't
>
Reasonable if they want to actually sell the product.


> Multiple encoding a for fp 0 -0 were once common
> E.g. CDC 6600++
>

fp zero is a different issue.  We still have that and the standard has
text on when and when not they are distinguished.

> How many systems have the issue for integers?
>
> I certainly recall the older Standards allowing the -+0 issue.  Did we
> always allow it for integers or is that "new" ?

The words in the standard for integers:

"The integer type includes a zero value, which is considered to be
neither negative nor positive. The value of a signed integer zero is the
same as the value of an unsigned integer zero."

Appears to have shown up first in f95.   The second sentence says the
literal constants "+0", "-0" (signed integer zeros) and "0" (unsigned)
all have the same value.    The first sentence says that there is a zero
value.  Neither of these sentences is about internal representations of
integers. Only that whatever the processor does internally, these are
the required semantics for the value.

Cheers,
Bill

>
>
>
> khbkhb at gmail.com <mailto:khbkhb at gmail.com>
> kbiermank (AIM)
> 303-997-2749
>
> Sent from my iPhone
>
> On Jan 31, 2013, at 3:50 PM, Van Snyder <Van.Snyder at jpl.nasa.gov
> <mailto:Van.Snyder at jpl.nasa.gov>> wrote:
>
>> On Thu, 2013-01-31 at 08:07 -0600, Bill Long wrote:
>>>
>>> On 1/30/13 7:53 PM, Malcolm Cohen wrote:
>>>>> I assume this is a theoretical question
>>>>
>>>> Sorry, but I am with Van here.
>>>>
>>>> It is so far from inconceivable that machines will have this kind of
>>>> arithmetic
>>>> that there are machines currently being produced with this kind of
>>>> arithmetic.
>>>>
>>>> We have gone to great lengths in the real, integer, and bit models
>>>> in clause 13
>>>> to avoid gratuitous machine dependencies, even to the extent of
>>>> handling radices
>>>> other than 2.
>>>
>>> Parts of those lengths are in 13.3 where we make the interpretation of
>>> negative integers as bit sequences processor dependent, as well as
>>> pretty much everything related to bit sequences for non-binary integer
>>> representations.
>>
>> Don't forget 4.4.2.2p1, which says that the integer zero value is
>> considered to be neither negative nor positive, and that a signed zero
>> has the same mathematical value as an unsigned zero.  The standard
>> clearly contemplates platforms with two representations of zero.
>>
>>> (Of course, I would have preferred to just have left BITS in the draft
>>> standard, avoiding the need for any of the B** functions.  But that
>>> position did not get consensus.)
>>
>> You would have had my vote on BITS if you had specified a length
>> parameter instead of a kind parameter.
>>
>>> Ultimately, it is a question of where we put our efforts.  We can go to
>>> lengths to accommodate extinct (for good reason) hardware failures, or
>>> focus on challenges that we can be confident will be affecting
>>> scientific computing in the time scale of vendor implementations of the
>>> next standard.  Among those challenges, I don't see duplicate
>>> representation of integer values anywhere on the horizon.
>>
>> Except, as Malcolm points out, they are being manufactured now.  I don't
>> have as clear a crystal ball as Bill has, but I do have colleagues who
>> keep close track of developments in chips with literally thousands of
>> tiny processor cores.  There seem to be several new entrants into this
>> game every year.  The last one they alerted me to is Altera (or is it
>> Alterra?).  Who knows how many of those have (or will have) multiple
>> representations of zero?
>>
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org>
>> http://mailman.j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101