(j3.2006) BEQ, BNE?

[Dick Hendrickson]

On Thu, Jan 31, 2013 at 9:01 PM, Keith Bierman <khbkhb at gmail.com> wrote:

> Thanks for sleuthing out f95
>
> I have no recollection of why we added integer +-0 as new text at that time
> Keith Bierman (nook)
>
> Actually, in FORTRAN 77 it says pretty much the same thing.

"4.1.3 Data Type Properties
.... For real, double precision, and integer data, the value zero is
considered neither positive nor negative. The value of a signed zero is the
same as the value of an unsigned zero."

Dick Hendrickson



> 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
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130201/12b72815/attachment.html