Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #20067 > unrolled thread

two fpu compared

Back to article view | Back to comp.arch.embedded

Contents

  two fpu compared al.basili@gmail.com (alb) - 2015-02-12 08:30 +0000
    Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-12 10:51 +0100
      Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-13 14:14 +0000
        Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-13 16:23 +0100
          Re: two fpu compared Colin Paul de Gloucester <not_a_real_email@address.com> - 2015-02-13 17:37 +0100
            Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-16 08:01 +0000
              Re: two fpu compared Colin Paul de Gloucester <not_a_real_email@address.com> - 2015-02-16 11:43 +0100
                Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-17 10:35 +0000
                  Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-17 12:18 +0100
                    Re: two fpu compared George Neuner <gneuner2@comcast.net> - 2015-02-17 09:26 -0500
                      Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-17 16:47 +0100
                        Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-17 20:54 +0200
          Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-16 07:58 +0000
            Re: two fpu compared David Brown <david.brown@hesbynett.no> - 2015-02-16 09:53 +0100
              Re: two fpu compared al.basili@gmail.com (alb) - 2015-02-16 09:47 +0000
                Re: two fpu compared Richard Damon <Richard@Damon-Family.org> - 2015-02-16 08:27 -0500
          Re: two fpu compared Nobody <nobody@nowhere.invalid> - 2015-02-23 00:13 +0000
        Re: two fpu compared George Neuner <gneuner2@comcast.net> - 2015-02-13 18:43 -0500
        Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-14 15:30 +0000
          Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-14 23:19 +0200
            Re: two fpu compared Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-02-14 23:28 +0100
            Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-15 14:33 +0000
              Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-17 20:53 +0200
                Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-18 01:55 +0000
                  Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-18 17:54 +0200
                    Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-18 16:52 +0000
                      Re: two fpu compared Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-02-18 18:12 +0100
                        Re: two fpu compared Robert Wessel <robertwessel2@yahoo.com> - 2015-02-18 18:02 -0600
                          Re: two fpu compared Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-02-19 09:42 +0200
                            Re: two fpu compared Robert Wessel <robertwessel2@yahoo.com> - 2015-02-19 11:04 -0600
                              Re: two fpu compared Reinhardt Behm <rbehm@hushmail.com> - 2015-02-19 23:26 +0800
                      Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-18 19:18 +0200
                        Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-19 02:28 +0200
                        Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-19 16:29 +0000
                          Re: two fpu compared Dimiter_Popoff <dp@tgi-sci.com> - 2015-02-21 16:07 +0200
    Re: two fpu compared glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-12 11:26 +0000
    Re: two fpu compared "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2015-02-12 12:29 +0100
    Re: two fpu compared Dennis <dennis@none.none> - 2015-02-12 09:45 -0600

Page 2 of 2 — ← Prev page 1 [2]

#20091

Am 14.02.2015 um 22:19 schrieb Dimiter_Popoff:
> On 14.2.2015 г. 17:30, glen herrmannsfeldt wrote:

>> (There is only one question left, and that is the way division
>> works when one operand is negative.)
>
> Why is that, what pitfalls do you envisage?

That would be those regarding the expected result of such operations.

To name but the simplest case, there are opposing, but roughly equally 
valid lines of reasoning about what the result of (-5)/3 should be: -2 
or -1.  One keeps the remainder positive and yields a curve for x/3 
without a "kink" as x passes zero.  The other allows independent 
treatment of the operands' signs, i.e. it guarantees (-a)/b = -(a/b).

Negative divisors have a similar issue, with different arguments being 
brought forth.

As is to be expected in such a case, not just MCUs, but also 
higher-level programming languages disagree on these issues.  Some 
language definitions opted not to specify them at all.

This means that the same calculation, even though it's just basic 
operations, and in integers, just by being run in different programming 
languages can easily yield different results.  And sometimes just 
picking a different toolchain for the same language will change the 
outcome ... or a compiler option, or a change to the execution 
environment at runtime, by other code, will.

For floating point operations, these same issues exist under the topic 
name of "rounding modes", and the applicable IEEE 754, 754 and IEC 60559 
standard require support for several of them, plus the ability two 
switch between them at run-time.  For integer divisional rounding, we're 
usually not that lucky: the MCU vendor or HLL specification decide for 
us, and they decide once and for all.

[toc] | [prev] | [next] | [standalone]

#20092

Dimiter_Popoff <dp@tgi-sci.com> wrote:

(snip on validating floating point calculations, where someone wrote)

>>>>> assuming two differently implemented FPU, both validated against the
>>>>> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I
>>>>> be sure that provided the inputs operands are the same the result would
>>>>> be the same bit wise?

(snip, then I wrote)

>> Are you sure the calculation should be done in floating point?
>> Without more details, I suspect it could be done in fixed point,
>> the results would not vary depending on implementations, and
>> everyone would be happy.
 
> Sometimes the choice to do something using an FPU is not because things
> cannot be done using the integer unit but just because one needs the
> horsepowers the FPU adds to the chip. Was the case with me on my
> netMCA-3 design - the FPU did make things a bit more complicated but
> using it was the only way to do what I did. Apart from the sheer
> ops per clock cycle it (being 64 bit of course, 32 bit FPU-s are
> pretty much useless) gave me the dynamic range I needed (32 bits
> integers would not have sufficed and multiprecision would have
> slowed things down beyond any practical usability).

Many science and engineering problems have a large dynamic
range, and require results with a relative error (uncertainty).

Lengths can be from nanometers to gigameter, times from picoseconds
to gigayears, and masses from eV to the mass of large stars. 
One can measure the atomic spacing in a crystal lattice or the
distance between planets with a relative uncertainty of about
one part in a million. Floating point is great for this.

But there are calculations where the required uncertainty does
not scale with the size of the problem. I expect a bank to keep
my balance to the cent, if I have one dollar or billions of
dollars in my account. (Well, I won't have billions of dollars,
but a big corporation might.) 

Note also that for such quantities the values never get really
small or really big. There is no use in computing with picodollars
or exadollars. The US IRS allows rounding to the nearest dollar,
there there are a few cases where ratios are computed to a
specified number of decimal places. These calculations are best
done in fixed point.

Because of the demand from scientists, many computers do have
faster floating point processors than fixed point, but often
enough the difference isn't all that large. Within a reasonable
range one can get exact results from floating point add,
subtract, and multiply. You have to be a lot more careful with
divide.

With approriate values, add, subtract, and multiply will never
round off the result, but divide can always do that. 

>> (There is only one question left, and that is the way division
>> works when one operand is negative.)
 
> Why is that, what pitfalls do you envisage? "Normally" one would
> divide the absolute values and just xor the sign bits after that,
> you must have something else/more to it than that in mind.

That is the usual way, at least partly for historical reasons.

It is usual for fixed point divide to return a quotient and
remainder. (Floating point pretty much never returns a remainder.)

In the case of a negative divisor, there are cases where one still
wants a positive remainder. 

Consider the simple case where one is keeping track of a date
and time, with some epoch (time origin). It simplifies many 
calculations, if you keep the time positive even when the date
goes negative. If it is now 06:22 on the 15th day, 30 days
ago, the clock will have read 06:22 on the -15th day, and 
not -13:38 on the -14th day. (No matter what the day, a clock
never reads a negative time.)

There are a fair number of problems in mathematics where one
wants a modulo (remainder) operations with this property.

The early binary computers used sign magnitude representation,
where the XOR of the two signs is applied to the quotient
and remainder. That isn't so obvious for twos complement, but
is commonly done.

Traditionally C allowed for either quotient and remainder in
the case of a negative divisor, as long as the two were consistent.
(That is, the / and % operators had to give appropriate results.)

Fortran, which originated on sign magnitude machines, requires
the remainder sign to match the divisor sign. (I believe C has
changed to require this, too.)  When Fortran required one,
and C allowed both, it was obvious to hardware designers which
way to go.  Many mathematicians would disagree.  (It is mostly
in discrete mathematics where one wants an unsigned modulo.)

-- glen

[toc] | [prev] | [next] | [standalone]

#20114

On 15.2.2015 г. 16:33, glen herrmannsfeldt wrote:
> Dimiter_Popoff <dp@tgi-sci.com> wrote:
>
> (snip on validating floating point calculations, where someone wrote)
>
>>>>>> assuming two differently implemented FPU, both validated against the
>>>>>> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I
>>>>>> be sure that provided the inputs operands are the same the result would
>>>>>> be the same bit wise?
>
> (snip, then I wrote)
>
>>> Are you sure the calculation should be done in floating point?
>>> Without more details, I suspect it could be done in fixed point,
>>> the results would not vary depending on implementations, and
>>> everyone would be happy.
>
>> Sometimes the choice to do something using an FPU is not because things
>> cannot be done using the integer unit but just because one needs the
>> horsepowers the FPU adds to the chip. Was the case with me on my
>> netMCA-3 design - the FPU did make things a bit more complicated but
>> using it was the only way to do what I did. Apart from the sheer
>> ops per clock cycle it (being 64 bit of course, 32 bit FPU-s are
>> pretty much useless) gave me the dynamic range I needed (32 bits
>> integers would not have sufficed and multiprecision would have
>> slowed things down beyond any practical usability).
>
> Many science and engineering problems have a large dynamic
> range, and require results with a relative error (uncertainty).
>
> Lengths can be from nanometers to gigameter, times from picoseconds
> to gigayears, and masses from eV to the mass of large stars.
> One can measure the atomic spacing in a crystal lattice or the
> distance between planets with a relative uncertainty of about
> one part in a million. Floating point is great for this.

Yes, this is the primary purpose of FP. I just gave an example how
it can be practical to use an FPU for some other reason, not the
primary one (i.e. one can make use of the horsepowers it provides
in parallel to the integer unit even though the calculations can
be done quite well in integers (the first time I implemented that
same conversion algorithm of mine was on a TI 5420 DSP, using integers).


>
> There are a fair number of problems in mathematics where one
> wants a modulo (remainder) operations with this property.

I did not realize you were talking integer divide, I though you
were referring to FP division hence me being puzzled. FP (IEEE FP
at least) maintains the mantissa as an absolute value and the sign
is not a part of it, then there is no remainder etc :-).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20117

Dimiter_Popoff <dp@tgi-sci.com> wrote:

(snip, I wrote)

>> Many science and engineering problems have a large dynamic
>> range, and require results with a relative error (uncertainty).

>> Lengths can be from nanometers to gigameter, times from picoseconds
>> to gigayears, and masses from eV to the mass of large stars.
>> One can measure the atomic spacing in a crystal lattice or the
>> distance between planets with a relative uncertainty of about
>> one part in a million. Floating point is great for this.
 
> Yes, this is the primary purpose of FP. I just gave an example how
> it can be practical to use an FPU for some other reason, not the
> primary one (i.e. one can make use of the horsepowers it provides
> in parallel to the integer unit even though the calculations can
> be done quite well in integers (the first time I implemented that
> same conversion algorithm of mine was on a TI 5420 DSP, 
> using integers).

Yes, but you want to be sure that it gives the right answer.
 
>> There are a fair number of problems in mathematics where one
>> wants a modulo (remainder) operations with this property.
 
> I did not realize you were talking integer divide, I though you
> were referring to FP division hence me being puzzled. FP (IEEE FP
> at least) maintains the mantissa as an absolute value and the sign
> is not a part of it, then there is no remainder etc :-).

If a problem is defined in fixed point, and you want to do it
in floating point instead, you want to be sure it will give the
right result. Floating point rounding can give a different result
than integer divide would, after converting the result to integer.

The discussion on remainder has to do with the way integer divide
works. 

It should always be true that (a/b)*b+a%b==b (C notation).
That is, divide and modulo (remainder) have to be consistent,
though in the case of negative operands there are two possible
choices.

But even with both positive, floating point can round in an
unexpected way.

Assuming you avoid the problems of negative division, fixed point
should always give the same result, but floating point might not.

-- glen

[toc] | [prev] | [next] | [standalone]

#20119

On 18.2.2015 г. 03:55, glen herrmannsfeldt wrote:
> Dimiter_Popoff <dp@tgi-sci.com> wrote:
>
> (snip, I wrote)
>
>>> Many science and engineering problems have a large dynamic
>>> range, and require results with a relative error (uncertainty).
>
>>> Lengths can be from nanometers to gigameter, times from picoseconds
>>> to gigayears, and masses from eV to the mass of large stars.
>>> One can measure the atomic spacing in a crystal lattice or the
>>> distance between planets with a relative uncertainty of about
>>> one part in a million. Floating point is great for this.
>
>> Yes, this is the primary purpose of FP. I just gave an example how
>> it can be practical to use an FPU for some other reason, not the
>> primary one (i.e. one can make use of the horsepowers it provides
>> in parallel to the integer unit even though the calculations can
>> be done quite well in integers (the first time I implemented that
>> same conversion algorithm of mine was on a TI 5420 DSP,
>> using integers).
>
> Yes, but you want to be sure that it gives the right answer.

Well of course. But then arithmetic is not such a high science,
you know. All you have to do is do the respective homework :-).

>
>>> There are a fair number of problems in mathematics where one
>>> wants a modulo (remainder) operations with this property.
>
>> I did not realize you were talking integer divide, I though you
>> were referring to FP division hence me being puzzled. FP (IEEE FP
>> at least) maintains the mantissa as an absolute value and the sign
>> is not a part of it, then there is no remainder etc :-).
>
> If a problem is defined in fixed point, and you want to do it
> in floating point instead, you want to be sure it will give the
> right result. Floating point rounding can give a different result
> than integer divide would, after converting the result to integer.

Hmmmm, not really. As long as there is no precision lost during
normalization/denormalization the result should be the same, rounded
to the nearest (or whatever the rounding mode has been set to, if
settable). Integer divide would round to the smaller value if
it returns quotient and remainder, it is up to the programmer to
resolve the remainder and round to the nearest (I usually do it
this way unless there are other considerations).

> The discussion on remainder has to do with the way integer divide
> works.
>
> It should always be true that (a/b)*b+a%b==b (C notation).
> That is, divide and modulo (remainder) have to be consistent,
> though in the case of negative operands there are two possible
> choices.

Yes, I have lost the count of divides I have written for various
processors over the years, there is nothing special about it.

> But even with both positive, floating point can round in an
> unexpected way.

Ouch, no. Different yes, unexpected - no, one has to know how
the FPU behaves, otherwise it is just broken.

>
> Assuming you avoid the problems of negative division, fixed point
> should always give the same result, but floating point might not.

Hmmm, I can't think of a way the FPU would yield two different
results for the same calculation without its controls being altered.
Especially if the operation is doable using integer division,
this would mean no mantissa bits will be lost during
normalization/denormalization (assuming 32 bit integer divide,
obviously one can write integer divide for a longer word than
the typical 53 bits on FP).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20120

Dimiter_Popoff <dp@tgi-sci.com> wrote:

(snip regarding integer divide)

>> Yes, but you want to be sure that it gives the right answer.
 
> Well of course. But then arithmetic is not such a high science,
> you know. All you have to do is do the respective homework :-).
 
(snip)
>> If a problem is defined in fixed point, and you want to do it
>> in floating point instead, you want to be sure it will give the
>> right result. Floating point rounding can give a different result
>> than integer divide would, after converting the result to integer.
 
> Hmmmm, not really. As long as there is no precision lost during
> normalization/denormalization the result should be the same, rounded
> to the nearest (or whatever the rounding mode has been set to, if
> settable). Integer divide would round to the smaller value if
> it returns quotient and remainder, it is up to the programmer to
> resolve the remainder and round to the nearest (I usually do it
> this way unless there are other considerations).

I haven't thought of the fine details recently, but I believe that
if you have round to nearest floating point, it is not so easy to
get the appropriate truncated integer quotient.

From the double rounding rule, I suspect that it can be done if
the floating point quotient is more than twice the needed length.
Of course, for efficent use of hardware you don't want it that long.

(snip)

> Yes, I have lost the count of divides I have written for various
> processors over the years, there is nothing special about it.
 
>> But even with both positive, floating point can round in an
>> unexpected way.
 
> Ouch, no. Different yes, unexpected - no, one has to know how
> the FPU behaves, otherwise it is just broken.
 
Given a 53 bit quotient of two integers, can you find the correct 32
bit integer quotient?

>> Assuming you avoid the problems of negative division, fixed point
>> should always give the same result, but floating point might not.
 
> Hmmm, I can't think of a way the FPU would yield two different
> results for the same calculation without its controls being altered.
> Especially if the operation is doable using integer division,
> this would mean no mantissa bits will be lost during
> normalization/denormalization (assuming 32 bit integer divide,
> obviously one can write integer divide for a longer word than
> the typical 53 bits on FP).

The favorite for many years was the x87 temporary real. You 
couldn't (from a high-level language) be sure that your values
were consistently kept at 53 bits or 64 bits, so sometimes got
different results.

As the compiler might keep values in registers between statements,
even assigning to a double wasn't always enough.

Otherwise, an older favorite was the Cray machine with non-commutative
multiply.  A*B-B*A might not be zero.

-- glen

[toc] | [prev] | [next] | [standalone]

#20121

Am 18.02.2015 um 17:52 schrieb glen herrmannsfeldt:

> Otherwise, an older favorite was the Cray machine with non-commutative
> multiply.  A*B-B*A might not be zero.

If memory serves Seymour Cray also gained some notoriety for building 
machines where A*1 might not be equal to A.

[toc] | [prev] | [next] | [standalone]

#20128

On Wed, 18 Feb 2015 18:12:20 +0100, Hans-Bernhard Bröker
<HBBroeker@t-online.de> wrote:

>Am 18.02.2015 um 17:52 schrieb glen herrmannsfeldt:
>
>> Otherwise, an older favorite was the Cray machine with non-commutative
>> multiply.  A*B-B*A might not be zero.
>
>If memory serves Seymour Cray also gained some notoriety for building 
>machines where A*1 might not be equal to A.


While I'm not sure A*1 was ever not equal to A, there were certainly
cases where A*B was not equal to B*A.

[toc] | [prev] | [next] | [standalone]

#20130

On 19.2.15 02:02, Robert Wessel wrote:
> On Wed, 18 Feb 2015 18:12:20 +0100, Hans-Bernhard Bröker
> <HBBroeker@t-online.de> wrote:
>
>> Am 18.02.2015 um 17:52 schrieb glen herrmannsfeldt:
>>
>>> Otherwise, an older favorite was the Cray machine with non-commutative
>>> multiply.  A*B-B*A might not be zero.
>>
>> If memory serves Seymour Cray also gained some notoriety for building
>> machines where A*1 might not be equal to A.
>
>
> While I'm not sure A*1 was ever not equal to A, there were certainly
> cases where A*B was not equal to B*A.
>

The classical example is 10.0 * 0.1. It is due to 0.1 having an 
infinitely long binary fraction (001100110011....).

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#20134

On Thu, 19 Feb 2015 09:42:50 +0200, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:

>On 19.2.15 02:02, Robert Wessel wrote:
>> On Wed, 18 Feb 2015 18:12:20 +0100, Hans-Bernhard Bröker
>> <HBBroeker@t-online.de> wrote:
>>
>>> Am 18.02.2015 um 17:52 schrieb glen herrmannsfeldt:
>>>
>>>> Otherwise, an older favorite was the Cray machine with non-commutative
>>>> multiply.  A*B-B*A might not be zero.
>>>
>>> If memory serves Seymour Cray also gained some notoriety for building
>>> machines where A*1 might not be equal to A.
>>
>>
>> While I'm not sure A*1 was ever not equal to A, there were certainly
>> cases where A*B was not equal to B*A.
>>
>
>The classical example is 10.0 * 0.1. It is due to 0.1 having an 
>infinitely long binary fraction (001100110011....).


That's a general issue with FP.  And on most machines you're going to
get the same (slightly off) result if you do 10*.01 or .01*10.

We're talking about some early Cray machines, which had a tendency to
curdle a few low bits of various FP operations, so that while 10*.01
and .01*10 would still not produce 1.0 exactly, they'd produce
slightly *different* values.

Numerical analysis on the early Crays was a contact sport.

[toc] | [prev] | [next] | [standalone]

#20138

On 20.02.2015 01:04, Robert Wessel wrote:
> On Thu, 19 Feb 2015 09:42:50 +0200, Tauno Voipio
> <tauno.voipio@notused.fi.invalid> wrote:
>
>> On 19.2.15 02:02, Robert Wessel wrote:
>>> On Wed, 18 Feb 2015 18:12:20 +0100, Hans-Bernhard Bröker
>>> <HBBroeker@t-online.de> wrote:
>>>
>>>> Am 18.02.2015 um 17:52 schrieb glen herrmannsfeldt:
>>>>
>>>>> Otherwise, an older favorite was the Cray machine with non-commutative
>>>>> multiply.  A*B-B*A might not be zero.
>>>>
>>>> If memory serves Seymour Cray also gained some notoriety for building
>>>> machines where A*1 might not be equal to A.
>>>
>>>
>>> While I'm not sure A*1 was ever not equal to A, there were certainly
>>> cases where A*B was not equal to B*A.
>>>
>>
>> The classical example is 10.0 * 0.1. It is due to 0.1 having an
>> infinitely long binary fraction (001100110011....).
>
>
> That's a general issue with FP.  And on most machines you're going to
> get the same (slightly off) result if you do 10*.01 or .01*10.
>
> We're talking about some early Cray machines, which had a tendency to
> curdle a few low bits of various FP operations, so that while 10*.01
> and .01*10 would still not produce 1.0 exactly, they'd produce
> slightly *different* values.
>
> Numerical analysis on the early Crays was a contact sport.
>
I remember that one version had PI wrong in their Fortran real*16 
routines. A colleague found this when his calculation differed between 
Cray and IBM-370.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#20122

On 18.2.2015 г. 18:52, glen herrmannsfeldt wrote:
> Dimiter_Popoff <dp@tgi-sci.com> wrote:
>
> (snip regarding integer divide)
>
>>> Yes, but you want to be sure that it gives the right answer.
>
>> Well of course. But then arithmetic is not such a high science,
>> you know. All you have to do is do the respective homework :-).
>
> (snip)
>>> If a problem is defined in fixed point, and you want to do it
>>> in floating point instead, you want to be sure it will give the
>>> right result. Floating point rounding can give a different result
>>> than integer divide would, after converting the result to integer.
>
>> Hmmmm, not really. As long as there is no precision lost during
>> normalization/denormalization the result should be the same, rounded
>> to the nearest (or whatever the rounding mode has been set to, if
>> settable). Integer divide would round to the smaller value if
>> it returns quotient and remainder, it is up to the programmer to
>> resolve the remainder and round to the nearest (I usually do it
>> this way unless there are other considerations).
>
> I haven't thought of the fine details recently, but I believe that
> if you have round to nearest floating point, it is not so easy to
> get the appropriate truncated integer quotient.

Absolutely correct of course. Setting the FPU rounding mode "to zero"
would solve this (if available, otherwise it would take some work).
I got bitten not so long ago by a similar, simpler error I had made;
instead of using "convert FP to integer and round to zero" (there is
such a power architecture opcode) I had used just "move FP to integer".
The latter rounds to nearest and I had to locate and fix it.... :-).


> ...
>> Yes, I have lost the count of divides I have written for various
>> processors over the years, there is nothing special about it.
>
>>> But even with both positive, floating point can round in an
>>> unexpected way.
>
>> Ouch, no. Different yes, unexpected - no, one has to know how
>> the FPU behaves, otherwise it is just broken.
>
> Given a 53 bit quotient of two integers, can you find the correct 32
> bit integer quotient?

Hmmmm, you make me scratch my head. I think yes, using the correct
rounding modes etc., but I would not claim anything without
thinking about it in "doing work" mode, which I can't at the
moment (head busy doing other things).

>>> Assuming you avoid the problems of negative division, fixed point
>>> should always give the same result, but floating point might not.
>
>> Hmmm, I can't think of a way the FPU would yield two different
>> results for the same calculation without its controls being altered.
>> Especially if the operation is doable using integer division,
>> this would mean no mantissa bits will be lost during
>> normalization/denormalization (assuming 32 bit integer divide,
>> obviously one can write integer divide for a longer word than
>> the typical 53 bits on FP).
>
> The favorite for many years was the x87 temporary real. You
> couldn't (from a high-level language) be sure that your values
> were consistently kept at 53 bits or 64 bits, so sometimes got
> different results.
>
> As the compiler might keep values in registers between statements,
> even assigning to a double wasn't always enough.

Well this is a compiler issue, not an FP one, although related.

>
> Otherwise, an older favorite was the Cray machine with non-commutative
> multiply.  A*B-B*A might not be zero.

Hah! Now such a bug could drive one insane if one has
to discover it :D .

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20129

On 18.2.2015 г. 19:18, Dimiter_Popoff wrote:
> On 18.2.2015 г. 18:52, glen herrmannsfeldt wrote:
>....
 >....
>>
>>
>> Given a 53 bit quotient of two integers, can you find the correct 32
>> bit integer quotient?
>
> Hmmmm, you make me scratch my head. I think yes, using the correct
> rounding modes etc., but I would not claim anything without
> thinking about it in "doing work" mode, which I can't at the
> moment (head busy doing other things).

LOL, head must have been busy with other nonsense indeed.
Of course you can. On the power FPU - if it is a 32 bit power - you
can get the correct integer quotient if it fits into 32 bits (signed,
so 31 bits really).
All one has to do is the divide, then convert to integer rounding
towards zero (there is such an opcode); for the remainder, subtract
and multiply will do it. On 64 bit power I think the limit is 64
(63) bits but I am not sure, yet to lay my hands on a 64 bit beast.

My head would have to work a bit more about the limits/data loss
re the remainder though, some other time :D .

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20133

Dimiter_Popoff <dp@tgi-sci.com> wrote:

(snip, I wrote)

>> I haven't thought of the fine details recently, but I believe that
>> if you have round to nearest floating point, it is not so easy to
>> get the appropriate truncated integer quotient.
 
> Absolutely correct of course. Setting the FPU rounding mode "to zero"
> would solve this (if available, otherwise it would take some work).
> I got bitten not so long ago by a similar, simpler error I had made;
> instead of using "convert FP to integer and round to zero" (there is
> such a power architecture opcode) I had used just "move FP to integer".
> The latter rounds to nearest and I had to locate and fix it.... :-).
 
(and I also wrote)
>> Given a 53 bit quotient of two integers, can you find the correct 32
>> bit integer quotient?
 
> Hmmmm, you make me scratch my head. I think yes, using the correct
> rounding modes etc., but I would not claim anything without
> thinking about it in "doing work" mode, which I can't at the
> moment (head busy doing other things).

The assumption of round to nearest from above was supposed to apply
to this case.

Traditionally, you got what the hardware gave you. 

IBM S/360 and successor hexadecimal floating point truncates
on division (except on the 360/91 where it rounds).

Many other processors from before IEEE 754 round only.

For discussion of double rounding, see:

https://en.wikipedia.org/wiki/Rounding#Double_rounding

-- glen

[toc] | [prev] | [next] | [standalone]

#20151

On 19.2.2015 г. 18:29, glen herrmannsfeldt wrote:
> Dimiter_Popoff <dp@tgi-sci.com> wrote:
>
> .....
>>> Given a 53 bit quotient of two integers, can you find the correct 32
>>> bit integer quotient?
>
>> Hmmmm, you make me scratch my head. I think yes, using the correct
>> rounding modes etc., but I would not claim anything without
>> thinking about it in "doing work" mode, which I can't at the
>> moment (head busy doing other things).
>
> The assumption of round to nearest from above was supposed to apply
> to this case.
>
> Traditionally, you got what the hardware gave you.
>
> IBM S/360 and successor hexadecimal floating point truncates
> on division (except on the 360/91 where it rounds).
>
> Many other processors from before IEEE 754 round only.
>
> For discussion of double rounding, see:
>
> https://en.wikipedia.org/wiki/Rounding#Double_rounding

Hmmmm, while I did not know what they call "double rounding"
obviously I knew what it is, as well as the obvious consequences.

On the power FPU there is the "round towards zero" mode, though.
Meaning the infinitely precise result absolute value will always be
rounded down. IOW it will not be rounded after the operation (at
least this is how I understand it, seems clear enough).
So doing divide such that the integer part of the quotient will
fit in the 53 bits - or let's say in 31 bits for simplicity - will
always be precise (unrounded).
Once one turns "round to nearest" on (which is how I keep it most if
not all of the time) obviously prior to recording the result in the FP
register they will add a 1 to the bit just below the LSB and all of
the problems you point to will apply.
I am not that frightened by that sort of thing because I write in VPA,
with the register model in mind, and if I begin to scratch my head
about how practical it is to use FP for something I will  just not
use it, or will take into account the applicable rounding etc. side
effects. On the example I gave earlier (the netmca-3) I used the FPU
as a DSP, doing plenty of MAC and other messy calculations, where
the LSB of the result (used up to 14 bits though more are available)
is thinner than the noise of the incoming signal I don't remember
even having to care much about rounding. I have had my moments with
it, obviously, but I don't remember when and doing what .... :-) .

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20069

alb <al.basili@gmail.com> wrote:
 
> assuming two differently implemented FPU, both validated against the 
> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I 
> be sure that provided the inputs operands are the same the result would 
> be the same bit wise?

The x87, which as well as I know follows the IEEE standard, holds
intermediate results in extended precision. (64 bit significand).
In that case, the results could easily be different from one that
didn't use extra precision. 

For x86-64 code, it is less usual to use x87, and so less likely
that will be a problem. 
 
> BACKGROUND: our dear customer wanted to verify that the control law 
> specified is correctly implemented by means of comparing output with a 
> golden model. Now the golden model is running on a standard PC, with 
> matlab, a pile of mathematical libraries and a processor that is 
> humongous compared to our little embedded unit. I've already warned 
> the customer that bitwise comparison might only be viable if precision 
> wise the two calculations are equally configured (single precision, 
> rounding, etc.). Are there any other elements to consider?

-- glen

[toc] | [prev] | [next] | [standalone]

#20070

Op Thu, 12 Feb 2015 09:30:32 +0100 schreef alb <al.basili@gmail.com>:
> Hi everyone,
>
> assuming two differently implemented FPU, both validated against the
> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I
> be sure that provided the inputs operands are the same the result would
> be the same bit wise?

Iff the software on both ends *use* the FPU in accordance with the  
standard (i.e. strictfp, no -ffast-math) and in the same mode, then it  
should be the same.

> BACKGROUND: our dear customer wanted to verify that the control law
> specified is correctly implemented by means of comparing output with a
> golden model. Now the golden model is running on a standard PC, with
> matlab, a pile of mathematical libraries and a processor that is
> humongous compared to our little embedded unit. I've already warned
> the customer that bitwise comparison might only be viable if precision
> wise the two calculations are equally configured (single precision,
> rounding, etc.). Are there any other elements to consider?
>
> Moreover, we are driving a PWM with the control law on a 8bit, or max
> 10bit precision, so most of that fine grain precision would not be used
> anyway.
>
> Any comment/pointer/suggestion is appreciated.

It is one thing to have a mathematical model that happens to give accurate  
results when ran on a PC, but it is quite another thing to perform  
numerical analysis and determine the required accuracy (exactness) for  
each step of the algorithm.  Regardless, if your customer can determine  
whether a 'golden' implementation provides accurate results, then I would  
think they can do the same for your implementation.



-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

[toc] | [prev] | [next] | [standalone]

#20071

On 02/12/2015 02:30 AM, alb wrote:
> Hi everyone,
>
> assuming two differently implemented FPU, both validated against the
> IEEE754, and limiting operations to the golden 5 (+,-, *, /, sqr), can I
> be sure that provided the inputs operands are the same the result would
> be the same bit wise?

No, you can't even get the same result on the same FP unit.

Years ago a young colleague of mine came to me with a problem. He was 
using floating point and at one point was getting a mis-compare on equal 
after some floating point computations on identical inputs. The 
computations went down some different paths and were compared at the 
end. (In same situations the inputs would not be identical on the two 
paths.) This was on a server grade PPC (some of you can see where this 
is going) which has a merged multiply-add. Due to the way it was coded 
on one path separate operations were done, on the other they were 
merged. The difference between one rounding and two was enough to give 
different results.

We had a discussion about how fp wasn't as easy as it looks, and why you 
need to be very careful with an equal compare using floating point.
>
> BACKGROUND: our dear customer wanted to verify that the control law
> specified is correctly implemented by means of comparing output with a
> golden model. Now the golden model is running on a standard PC, with
> matlab, a pile of mathematical libraries and a processor that is
> humongous compared to our little embedded unit. I've already warned
> the customer that bitwise comparison might only be viable if precision
> wise the two calculations are equally configured (single precision,
> rounding, etc.). Are there any other elements to consider?
>
> Moreover, we are driving a PWM with the control law on a 8bit, or max
> 10bit precision, so most of that fine grain precision would not be used
> anyway.
>
> Any comment/pointer/suggestion is appreciated.
>
> Al
>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web