Numerical calculations: Why not use fixed point types for everything?

Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

Hello,
     I have been thinking that since with floating-point representation the distribution of model numbers gets worse (more and more wider spacing) with large numbers leading to less accurate representation of a number, is it better to just go for fixed-point types e.g. in

type Position is delta 1.0**(-12) range 0.0 to 100_000

and define every variable similarly so that we have an equally spaced distribution of the model numbers between the lower and upper bounds?

Why not just fixed-point types in numerical calculations?

And why not just use decimal fixed point types as in

type Velocity is delta 1E-10 digits 15 

for example if we know what magnitudes of the Velocity are to be expected?

I understand that it is a question of portability as well as the actual delta that would be used would perhaps not be the same for all machines and for all compilers.

Thanks,
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Nasser M. Abbasi]

On 01/17/2013 04:33 AM, Ada novice wrote:

>
> I understand that it is a question of portability as well
>as the actual delta that would be used would perhaps not be
>the same for all machines and for all compilers.
>

There is good article on this here:

http://www.dspguide.com/ch28/4.htm

(this assumes the hardware can run both floating
point and fixed point, not all hardware supports
fixed point. From the above it says

"fixed point DSPs are generally cheaper, while floating
point devices have better precision, higher dynamic range,
and a shorter development cycle"

I suppose if the hardware does not support fixed point,
this is handled by a software library or the run-time, and
will be slower than floating point.

--Nasser

Re: Numerical calculations: Why not use fixed point types for everything?

[Adam Beneschan]

On Thursday, January 17, 2013 6:40:04 AM UTC-8, Nasser M. Abbasi wrote:
> On 01/17/2013 04:33 AM, Ada novice wrote:
> 
> > I understand that it is a question of portability as well
> >as the actual delta that would be used would perhaps not be
> >the same for all machines and for all compilers.
> 
> There is good article on this here:
> 
> http://www.dspguide.com/ch28/4.htm
> 
> 
> 
> (this assumes the hardware can run both floating
> point and fixed point, not all hardware supports
> fixed point. From the above it says
> 
> "fixed point DSPs are generally cheaper, while floating
> point devices have better precision, higher dynamic range,
> and a shorter development cycle"
> 
> I suppose if the hardware does not support fixed point,
> this is handled by a software library or the run-time, and
> will be slower than floating point.

I don't know if there's really such a thing as hardware that doesn't support "fixed-point."  From an Ada standpoint, and probably from other standpoints as well, fixed-point numbers are just integers, where the compiler knows internally that each integer N actually represents the value N * S where S is the scale factor (which is usually 2**(-m) for some positive integer m, or 10**(-m) for decimal fixed-point, but implementations are allowed to support other scale factors), but the hardware doesn't know about the scale factor.  Arithmetic operations on fixed-point values are just implemented as operations on integers, sometimes with some extra multiplication or division (which can sometimes be accomplished with shifting) to make the scale factors match.  

The article you reference uses SHARC as one of its examples of DSP's that support fixed-point.  My copy of ADSP-2106x SHARC(tm) User's Manual describes fixed-point numbers as "They may be treated as fractional or integer numbers and as unsigned or twos-complement".  Throughout the manual, the descriptions use "fixed-point" in this way--the hardware is really treating the numbers as integers, and it's up to the programmer or compiler to know whether they really represent integers or not, but the manual is just using that term instead of "integer".  

So if this is typically how the term is used, then hardware that doesn't support fixed-point is really hardware that doesn't support integers, and AFAIK there has never been any processor in the history of computing that doesn't support integer arithmetic.

                                 -- Adam

Re: Numerical calculations: Why not use fixed point types for everything?

[Adam Beneschan]

On Thursday, January 17, 2013 2:33:28 AM UTC-8, Ada novice wrote:
> Hello,
> 
>      I have been thinking that since with floating-point representation the distribution of model numbers gets worse (more and more wider spacing) with large numbers leading to less accurate representation of a number, is it better to just go for fixed-point types e.g. in
> 
> 
> type Position is delta 1.0**(-12) range 0.0 to 100_000

This must be a typo ... 1.0**(-12) is just 1, isn't it?

> and define every variable similarly so that we have an equally spaced distribution of the model numbers between the lower and upper bounds?
> 
> Why not just fixed-point types in numerical calculations?
> 
> And why not just use decimal fixed point types as in
> 
> type Velocity is delta 1E-10 digits 15 
> 
> for example if we know what magnitudes of the Velocity are to be expected?
> 
> I understand that it is a question of portability as well as the actual delta that would be used would perhaps not be the same for all machines and for all compilers.

I can think of two reasons why using floating-point may be better, but this depends on the application:

(1) Floating-point numbers have a greater range, because the exponent is part of the number.  Thus, an IEEE 64-bit floating-point value can represent positive numbers as large as 1.7*10**308 or as small as 2.2*10**(-308); a fixed-point number that represented all those possible values would have to have a whole lot of bits.  

(2) Many processors have built-in support for mathematical functions on floating-point values (square root, trig functions, log, e**x).  If your program does lots of those, you'll probably want to use floating-point numbers instead of calling library functions to do the computation (slow) or constantly converting back and forth between fixed- and floating-point.

If neither of those is an issue, then it may be better to use fixed point.

                              -- Adam

Re: Numerical calculations: Why not use fixed point types for everything?

[Georg Bauhaus]

On 17.01.13 17:16, Adam Beneschan wrote:
> AFAIK there has never been any processor in the history of computing that doesn't support integer arithmetic.


Except that no processor so far has ever supported the set
of integers. ;-)

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Thursday, January 17, 2013 5:25:30 PM UTC+1, Adam Beneschan wrote:

> (2) Many processors have built-in support for mathematical functions on floating-point values (square root, trig functions, log, e**x).  If your program does lots of those, you'll probably want to use floating-point numbers instead of calling library functions to do the computation (slow) or constantly converting back and forth between fixed- and floating-point.
> 
> 
>                               -- Adam

Thanks to all of you for your inputs. So if I am just writing a program that won't be run on a separate DSP platform but only on my computer, then I can go for fixed-point representation as long as I am not working with excessively large or excessively small values.

I have read (John Mc Cormick: Building parallel...with Ada's book) that fixed point arithmetic is faster than floating-point arithmetic since integer instructions are faster so I would ask about the second point put by Adam that mathematical functions are slow with fixed-point numbers. Can you please elaborate on that?

Thanks
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[J-P. Rosen]

Le 18/01/2013 10:17, Ada novice a �crit :
> I have read (John Mc Cormick: Building parallel...with Ada's book)
> that fixed point arithmetic is faster than floating-point arithmetic
> since integer instructions are faster
General advice: don't assume anything about speed unless you had a
chance to measure it.

I heard a claim that with modern co-processors, floating point
arithmetic was faster than integer arithmetic. Since the claim was by
Robert Dewar, it is worth considering...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Numerical calculations: Why not use fixed point types for everything?

[Jeffrey Carter]

On 01/18/2013 10:24 AM, J-P. Rosen wrote:
> Le 18/01/2013 10:17, Ada novice a �crit :
>> I have read (John Mc Cormick: Building parallel...with Ada's book)
>> that fixed point arithmetic is faster than floating-point arithmetic
>> since integer instructions are faster
> General advice: don't assume anything about speed unless you had a
> chance to measure it.
>
> I heard a claim that with modern co-processors, floating point
> arithmetic was faster than integer arithmetic. Since the claim was by
> Robert Dewar, it is worth considering...

When I started programming FORTRAN-66 on a CDC-6400 in 1975, floating-point 
operations were done in S/W and integer operations were significantly faster. On 
modern processors with FPUs, integer operations are not necessarily faster than 
floating-point. I don't know that floating-point operations are always faster 
than integer with FPUs, though. One advantage is that FPU operations can proceed 
in parallel with CPU operations.

Pretty much everything I learned back in the good old days isn't true any more. 
In Pascal, we had to keep the universe of sets (implemented as packed arrays of 
Boolean) fairly small. But these days, with a 32-bit Integer, even

type Set is array (Integer) of Boolean;
for Set'Component_Size use 1;

will fit into physical memory on many machines!

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

Re: Numerical calculations: Why not use fixed point types for everything?

[Dennis Lee Bieber]

On Fri, 18 Jan 2013 01:17:37 -0800 (PST), Ada novice <shai.lesh@gmx.com>
declaimed the following in comp.lang.ada:

> 
> I have read (John Mc Cormick: Building parallel...with Ada's book) that fixed point arithmetic is faster than floating-point arithmetic since integer instructions are faster so I would ask about the second point put by Adam that mathematical functions are slow with fixed-point numbers. Can you please elaborate on that?
>
	Integer operations may be faster than floating point... But fixed
point with a non-zero decimal place add in the overhead of having to
track where the point is and shifting results to match the declared data
type.

25 * 25 => 725

2.5 * 2.5 => 7.25 -- but if the data type is only one decimal place this
now has to be rounded and shifted to become 7.3.

	All these adjustments and tracking are being done at the high-level
instruction set, not in the processor hardware. In contrast, a floating
point processor does all the mantissa and exponent adjustments in the
hardware, which may be faster than having to do things like --

ld i1, 25
mult i1, 25
add i1, 5
div i1, 10

-- the sequence to treat integer registers as fixed 1-decimal place data
compared to (the add/div would be added by the compiler based upon the
number of decimal places to be kept in the result, based upon the number
of places that were in the source 

ld f1, 2.5E0
mult f1, 2.5E0

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Numerical calculations: Why not use fixed point types for everything?

[Adam Beneschan]

On Friday, January 18, 2013 10:15:06 AM UTC-8, Dennis Lee Bieber wrote:

> 	Integer operations may be faster than floating point... But fixed
> point with a non-zero decimal place add in the overhead of having to
> track where the point is and shifting results to match the declared data
> type.
> 
> 25 * 25 => 725
> 
> 2.5 * 2.5 => 7.25 -- but if the data type is only one decimal place this
> now has to be rounded and shifted to become 7.3.

Perhaps.  But I tend to assume my computer is going to return correct arithmetical results, which none of the above are.  :(

In general, of course you're right that if your values aren't represented with enough precision, or with a scale factor that will require rounding, you're going to run into problems.  But of course that's a problem with floating-point as well as with fixed-point.  If the range of values is small enough, you can actually declare fixed-point types that have greater precision than the available floating-point types.  And how much precision is necessary depends on the problem domain.  And there's no reason to assume that all values in your program have to have the same scale factor--in fact, Ada's definition of fixed-point multiplication and division operations supports cases where an intermediate result may have more precision than the operands, and rounding can wait until the final expression result is computed.

                        -- Adam

Re: Numerical calculations: Why not use fixed point types for everything?

[Adam Beneschan]

On Friday, January 18, 2013 1:17:37 AM UTC-8, Ada novice wrote:
> On Thursday, January 17, 2013 5:25:30 PM UTC+1, Adam Beneschan wrote:
> 
> 
> 
> > (2) Many processors have built-in support for mathematical functions on floating-point values (square root, trig functions, log, e**x).  If your program does lots of those, you'll probably want to use floating-point numbers instead of calling library functions to do the computation (slow) or constantly converting back and forth between fixed- and floating-point.
> 
> > 
> 
> > 
> 
> >                               -- Adam
> 
> 
> 
> Thanks to all of you for your inputs. So if I am just writing a program that won't be run on a separate DSP platform but only on my computer, then I can go for fixed-point representation as long as I am not working with excessively large or excessively small values.
> 
> 
> 
> I have read (John Mc Cormick: Building parallel...with Ada's book) that fixed point arithmetic is faster than floating-point arithmetic since integer instructions are faster so I would ask about the second point put by Adam that mathematical functions are slow with fixed-point numbers. Can you please elaborate on that?

What I mean is that some processors (including the Pentium) have instructions to perform mathematical operations like trig functions, square-root, etc., on floating-point numbers, and special hardware to do the computation.  If you were to figure out just what mathematical operations the hardware is doing to compute the result, you could write code to perform the same operations with fixed-point numbers.  But since the processor would have to go through the instructions and execute them, this takes longer.  (In real life, you wouldn't write algorithm to perform these functions on fixed-point numbers; you'd just convert a fixed-point number to a floating-point number and let the hardware do its work.  But doing these conversions takes a little extra time.  You'd have to determine whether the extra time is made up by the time saved by doing the simpler calculations in fixed-point, and that depends on the application.)

On a machine that doesn't have hardware to do these computations, code to do the computations on fixed-point numbers might be faster than the equivalent code to do it on floating-point numbers, assuming the scale factors of the fixed-point numbers are known ahead of time.  But even then, this might not be correct.  I agree with J-P that you really can't tell which one will be faster, on any particular hardware configuration, until you try it out and measure it.

                             -- Adam

Re: Numerical calculations: Why not use fixed point types for everything?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:7aeff757-a038-45e0-93d6-bd1d6e02093e@googlegroups.com...
...
>What I mean is that some processors (including the Pentium) have 
>instructions
>to perform mathematical operations like trig functions, square-root, etc., 
>on
>floating-point numbers, and special hardware to do the computation.

We're talking Ada here, and in at least some cases (i.e. Intel processors), 
at least, those instructions aren't accurate enough to meet the requirements 
of Annex G for those mathematical operations. So it's unlikely that your 
compiler would use them (unless of course Annex G isn't supported at all, in 
which case you have no idea what the math actually does).

So I find this to be a red herring: most Ada software uses only software 
trig functions and the like. The real problem is that Ada doesn't provide 
any fixed point mathematical functions, so you either have to roll-your-own 
(with all of the dangers of inaccurate results) or just convert to float 
(with the extra cost involved).

But of course if you never use any of those functions (which would describe 
98% of my code; the only one I use with any regularity is Sqrt, to calculate 
standard deviations), then fixed point is likely to be cheaper.

                                              Randy.

Re: Numerical calculations: Why not use fixed point types for everything?

[Robin Vowels]

On Jan 19, 5:15 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> On Fri, 18 Jan 2013 01:17:37 -0800 (PST), Ada novice <shai.l...@gmx.com>
> declaimed the following in comp.lang.ada:
>
>
>
> > I have read (John Mc Cormick: Building parallel...with Ada's book) that fixed point arithmetic is faster than floating-point arithmetic since integer instructions are faster so I would ask about the second point put by Adam that mathematical functions are slow with fixed-point numbers. Can you please elaborate on that?
>
>         Integer operations may be faster than floating point... But fixed
> point with a non-zero decimal place add in the overhead of having to
> track where the point is and shifting results to match the declared data
> type.
>
> 25 * 25 => 725
>
> 2.5 * 2.5 => 7.25 -- but if the data type is only one decimal place this
> now has to be rounded and shifted to become 7.3.
>
>         All these adjustments and tracking are being done at the high-level
> instruction set, not in the processor hardware. In contrast, a floating
> point processor does all the mantissa and exponent adjustments in the
> hardware, which may be faster than having to do things like --
>
> ld i1, 25
> mult i1, 25
> add i1, 5
> div i1, 10

It may not be like that at all.
In the first place, 25 is a constant.
In the second place, adjusting the value (scaling) is achieved
with a shift, not an actual division by 10.
Thus, multiplication is simply
multiply a,b
shift.rounded a

> -- the sequence to treat integer registers as fixed 1-decimal place data
> compared to (the add/div would be added by the compiler based upon the
> number of decimal places to be kept in the result, based upon the number
> of places that were in the source
>
> ld f1, 2.5E0
> mult f1, 2.5E0

Re: Numerical calculations: Why not use fixed point types for everything?

[Dennis Lee Bieber]

On Fri, 18 Jan 2013 10:59:43 -0800 (PST), Adam Beneschan
<adam@irvine.com> declaimed the following in comp.lang.ada:

> On Friday, January 18, 2013 10:15:06 AM UTC-8, Dennis Lee Bieber wrote:
> 
> > 	Integer operations may be faster than floating point... But fixed
> > point with a non-zero decimal place add in the overhead of having to
> > track where the point is and shifting results to match the declared data
> > type.
> > 
> > 25 * 25 => 725
> > 
> > 2.5 * 2.5 => 7.25 -- but if the data type is only one decimal place this
> > now has to be rounded and shifted to become 7.3.
> 
> Perhaps.  But I tend to assume my computer is going to return correct arithmetical results, which none of the above are.  :(
> 
	Okay... I carried one extra for the leading digit... <G>

> In general, of course you're right that if your values aren't represented with enough precision, or with a scale factor that will require rounding, you're going to run into problems.  But of course that's a problem with floating-point as well as with fixed-point.  If the range of values is small enough, you can actually declare fixed-point types that have greater precision than the available floating-point types.  And how much precision is necessary depends on the problem domain.  And there's no reason to assume that all values in your program have to have the same scale factor--in fact, Ada's definition of fixed-point multiplication and division operations supports cases where an intermediate result may have more precision than the operands, and rounding can wait until the final expression result is computed.

	My emphasis was that, lacking true hardware fixed point operations,
the compiler has to track the position of the implied point and insert
operations to (for lack of better term) normalize the results back into
the declared type. Those the negative impact of those normalization
instructions may cancel out any expected gain from using integer
arithmetic operations. 
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Numerical calculations: Why not use fixed point types for everything?

[Jeffrey Carter]

On 01/18/2013 09:41 PM, Dennis Lee Bieber wrote:
>
> 	My emphasis was that, lacking true hardware fixed point operations,
> the compiler has to track the position of the implied point and insert
> operations to (for lack of better term) normalize the results back into
> the declared type. Those the negative impact of those normalization
> instructions may cancel out any expected gain from using integer
> arithmetic operations.

I decided to run a test. My results:

jrcarter@jrcarter-gateway-1:~/Code$ ./sum
Float took 0.007979000
Fixed took 0.008180000
jrcarter@jrcarter-gateway-1:~/Code$ ./sum
Float took 0.007971000
Fixed took 0.008278000
jrcarter@jrcarter-gateway-1:~/Code$ ./sum
Float took 0.007979000
Fixed took 0.008403000

It seems that floating-point operations are slightly faster than fixed point on 
a (sort of) modern processor (AMD Athlon II M300).

The code:

with Ada.Real_Time;
with Ada.Text_IO;

with PragmARC.Universal_Random;

procedure Sum is
    package Random is new PragmARC.Universal_Random (Supplied_Real => Float);

    procedure Process is
       Max : constant := 5_000.0;

       subtype Index_Value is Integer range 1 .. 1_024;

       subtype Value is Float range -Max .. Max;

       type Value_List is array (Index_Value range <>) of Value;

       type Fixed is delta 2.0 ** (-20) range -Max .. Max;

       type Fixed_List is array (Index_Value range <>) of Fixed;

       Value_Length : constant Value := Value (Index_Value'Last);

       function Sum (List : in Value_List) return Value is
          Result : Value := 0.0;
       begin -- Sum
          Add_All : for I in List'Range loop
             Result := Result + List (I) / Value_Length;
          end loop Add_All;

          return Result;
       end Sum;

       Length : constant Index_Value := Index_Value'Last;

       function Sum (List : in Fixed_List) return Fixed is
          Result : Fixed := 0.0;
       begin -- Sum
          Add_All : for I in List'Range loop
             Result := Result + List (I) / Length;
          end loop Add_All;

          return Result;
       end Sum;

       Value_Set : Value_List (Index_Value) := (Index_Value => 
Random.Random_Range (-Max, Max) );
       Fixed_Set : Fixed_List (Index_Value);

       Target_Index : constant Index_Value := Random.Random_Int 
(Index_Value'First, Index_Value'Last);

       Value_Result : Value;
       Fixed_Result : Fixed;
       Start        : Ada.Real_Time.Time;

       use type Ada.Real_Time.Time;
    begin -- Process
       Copy : for I in Value_Set'Range loop
          Fixed_Set (I) := Fixed (Value_Set (I) );
       end loop Copy;

       Start := Ada.Real_Time.Clock;

       Float_Test : for I in Index_Value loop
          Value_Result := Sum (Value_Set);
       end loop Float_Test;

       Ada.Text_IO.Put_Line (Item => "Float took" & Duration'Image 
(Ada.Real_Time.To_Duration (Ada.Real_Time.Clock - Start) ) );

       Start := Ada.Real_Time.Clock;

       Fixed_Test : for I in Index_Value loop
          Fixed_Result := Sum (Fixed_Set);
       end loop Fixed_Test;

       Ada.Text_IO.Put_Line (Item => "Fixed took" & Duration'Image 
(Ada.Real_Time.To_Duration (Ada.Real_Time.Clock - Start) ) );
    end Process;
begin -- Sum
    Random.Randomize;
    Process;
end Sum;

(I realize this actually calculates averages, but it started out doing sums 
until I realized the sum might not fit into the ranges I was using, and I'm too 
lazy to change the names.)

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail
13

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

Thanks to all for the interesting discussions. Since my codes tend to use lots of mathematical functions, it is better then that I stick to floating point number representation.

Thanks
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> I decided to run a test. My results:

Thanks -- it's good to have actual numbers.

But the choice between floating- and fixed-point should not
be made primarily on the basis of speed.  It should be based
on the needs of the problem, such as whether you want relative
or absolute errors.

Unless you're running on a machine with no hardware support
for floating point.

- Bob

Re: Numerical calculations: Why not use fixed point types for everything?

[Robin Vowels]

On Jan 19, 3:41 pm, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> On Fri, 18 Jan 2013 10:59:43 -0800 (PST), Adam Beneschan
> <a...@irvine.com> declaimed the following in comp.lang.ada:
>
> > On Friday, January 18, 2013 10:15:06 AM UTC-8, Dennis Lee Bieber wrote:
>
> > >       Integer operations may be faster than floating point... But fixed
> > > point with a non-zero decimal place add in the overhead of having to
> > > track where the point is and shifting results to match the declared data
> > > type.
>
> > > 25 * 25 => 725
>
> > > 2.5 * 2.5 => 7.25 -- but if the data type is only one decimal place this
> > > now has to be rounded and shifted to become 7.3.
>
> > Perhaps.  But I tend to assume my computer is going to return correct arithmetical results, which none of the above are.  :(
>
>         Okay... I carried one extra for the leading digit... <G>
>
> > In general, of course you're right that if your values aren't represented with enough precision, or with a scale factor that will require rounding, you're going to run into problems.  But of course that's a problem with floating-point as well as with fixed-point.  If the range of values is small enough, you can actually declare fixed-point types that have greater precision than the available floating-point types.  And how much precision is necessary depends on the problem domain.  And there's no reason to assume that all values in your program have to have the same scale factor--in fact, Ada's definition of fixed-point multiplication and division operations supports cases where an intermediate result may have more precision than the operands, and rounding can wait until the final expression result is computed.
>
>         My emphasis was that, lacking true hardware fixed point operations,

Virtually every computer has true hardware fixed-point operations.
I refer to the set of integer instructions, which are, of course,
fixed-point instructions.

> the compiler has to track the position of the implied point and insert
> operations to (for lack of better term) normalize the results back into
> the declared type. Those the negative impact of those normalization
> instructions may cancel out any expected gain from using integer
> arithmetic operations.

You are referring to multiplication and division.
What you say doesn't usually apply to addition and subtraction,
unless for some reason there is a change of scale factor.

Adjusting the scale factor for multiplication doesn't usually
involve much work.  It's a shift operation. That operation is
typically short compared to the time taken for multiplication.

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Saturday, January 19, 2013 7:26:25 AM UTC+1, Jeffrey Carter wrote
> 
> 
> jrcarter@jrcarter-gateway-1:~/Code$ ./sum
> 
> Float took 0.007979000
> 
> Fixed took 0.008180000
> 
> jrcarter@jrcarter-gateway-1:~/Code$ ./sum
> 
> Float took 0.007971000
> 
> Fixed took 0.008278000
> 
> jrcarter@jrcarter-gateway-1:~/Code$ ./sum
> 
> Float took 0.007979000
> 
> Fixed took 0.008403000
> 
> 
> 
> It seems that floating-point operations are slightly faster than fixed point on 
> 
> a (sort of) modern processor (AMD Athlon II M300).
> 
> 
> 
> The code:
> 
> 
> 
> with Ada.Real_Time;
> 
> with Ada.Text_IO;
> 
> 
> 
> with PragmARC.Universal_Random;
> 
> 

Hi, When I run your code with GNAT GPL 2011, I get the error message: "file pragmARC.ads" not found. 

Thanks.

YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Simon Wright]

Ada novice <shai.lesh@gmx.com> writes:

> On Saturday, January 19, 2013 7:26:25 AM UTC+1, Jeffrey Carter wrote
>> with PragmARC.Universal_Random;
>
> Hi, When I run your code with GNAT GPL 2011, I get the error message:
> "file pragmARC.ads" not found.

The PragmAda Reusable Components aren't part of the Ada or GNAT standard
libraries, so you would need to find them on the web (hint: google
"pragmarc", look at the second hit), download/unpack (I would create a
new directory to unpack into), put the unpack directory on your source
path (gnatmake -aI<dir>).

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

Hi simon, 
               Thanks for pointing me in the right direction.

YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Paul Colin Gloster]

On 2013-01-18, Randy Brukardt <randy@rrsoftware.com> sent:
|-----------------------------------------------------------------------------|
|""Adam Beneschan" <adam@irvine.com> wrote in message                         |
|news:7aeff757-a038-45e0-93d6-bd1d6e02093e@googlegroups.com...                |
|...                                                                          |
|>What I mean is that some processors (including the Pentium) have            |
|>instructions                                                                |
|>to perform mathematical operations like trig functions, square-root, etc.,  |
|>on                                                                          |
|>floating-point numbers, and special hardware to do the computation.         |
|                                                                             |
|We're talking Ada here, and in at least some cases (i.e. Intel processors),  |
|at least, those instructions aren't accurate enough to meet the requirements |
|of Annex G for those mathematical operations. So it's unlikely that your     |
|compiler would use them (unless of course Annex G isn't supported at all, in |
|which case you have no idea what the math actually does)."                   |
|-----------------------------------------------------------------------------|

During a VHDL-standardization meeting, David Bishop mentioned that a
widespread, non-VHDL supposed implementation of a mathematical
function was very wrong even within the supposedly supported bitwidth.

|-----------------------------------------------------------------------------|
|"So I find this to be a red herring: most Ada software uses only software    |
|trig functions and the like. [. . .]                                         |
|                                                                             |
|[. . .]"                                                                     |
|-----------------------------------------------------------------------------|

Recent hardware lacks 128-bit floating-point support regardless of
language. For example, from
HTTP://software.Intel.com/en-us/forums/topic/304052?wapkw=quadruple
:
#####################################################################
#"[. . .]                                                           #
#                                                                   #
# TimP (Intel)                                                      #
#Tue, 11/27/2007 - 05:51                                            #
#                                                                   #
#ifort real*16 (113 bits precision) is implemented on Xeon CPUs by  #
#functions which combine x87 operations, so the performance is quite#
#low [. . .]                                                        #
#                                                                   #
#[. . .]"                                                           #
#####################################################################

Similarly from
WWW.PGroup.com/userforum/viewtopic.php?t=127&highlight=double+emulation
:
!-----------------------------------------------------------------------!
!"[. . .]                                                               !
!                                                                       !
!mkcolg                                                                 !
!                                                                       !
!                                                                       !
!                                                                       !
!Joined: 30 Jun 2004                                                    !
!Posts: 4616                                                            !
!Location: The Portland Group Inc.                                      !
!PostPosted: Tue Dec 14, 2004 2:03 pm    Post subject: 	Reply with quote!
!Hello,                                                                 !
!                                                                       !
!                                                                       !
!At this time we don't plan on supporting REAL*16. This is due to the   !
!lack of hardware support and the extreme performance penalty of        !
!software emulation. Of course, if we see more demand then we'll        !
!reconsider.                                                            !
!                                                                       !
!Thanks,                                                                !
!Mat                                                                    !
!                                                                       !
![. . .]"                                                               !
!-----------------------------------------------------------------------!

Similarly from
HTTP://StackOverflow.com/questions/2799684/x86-64-long-double-precision
:
|__________________________________________________________________|
|"[. . .]                                                          |
|                                                                  |
|x86-64 precision is the same as regular x86. Extended double is 80|
|bits, using the x87 ISA, with 6 padding bytes added. There is no  |
|128-bit FP hardware.                                              |
|                                                                  |
|[. . .]                                                           |
|                                                                  |
|answered May 10 '10 at 0:16                                       |
|Potatoswatter                                                     |
|[. . .]                                                           |
|                                                                  |
|[. . .]"                                                          |
|__________________________________________________________________|

Re: Numerical calculations: Why not use fixed point types for everything?

[Paul Colin Gloster]

On 2013-01-19, Robert A Duff <bobduff@shell01.TheWorld.com> sent:
|--------------------------------------------------------------|
|"Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:  |
|                                                              |
|> I decided to run a test. My results:                        |
|                                                              |
|Thanks -- it's good to have actual numbers.                   |
|                                                              |
|But the choice between floating- and fixed-point should not   |
|be made primarily on the basis of speed.  It should be based  |
|on the needs of the problem, such as whether you want relative|
|or absolute errors.                                           |
|                                                              |
|Unless you're running on a machine with no hardware support   |
|for floating point.                                           |
|                                                              |
|- Bob"                                                        |
|--------------------------------------------------------------|

We "should" not need these different datatypes. Everything "should"
just be perfect. Therefore there "should" be neither relative nor
absoulte errors.

Unfortunately we live in the real World, so how long we need to wait
for some inaccurate estimations instead of many inaccurate estimations
is often an important factor. For example, from
HTTP://Permalink.Gmane.org/gmane.comp.lib.gmp.general/4212
:
########################################################################
#"[. . .]                                                              #
#                                                                      #
#I am seeing a piece of code that takes about two minutes to execute in#
#double precision taking about two                                     #
#_hours_ in 30-digit precision. Does that sound about right? FWIW, I am#
#using MPFR through the Ada binding.                                   #
#                                                                      #
#[. . .]"                                                              #
########################################################################

Re: Numerical calculations: Why not use fixed point types for everything?

[Paul Colin Gloster]

On 2013-01-18, Ada novice <shai.lesh@gmx.com> sent:
|---------------------------------------------------------------------|
|"[. . .]                                                             |
|                                                                     |
|I have read (John Mc Cormick: Building parallel...with Ada's book)   |
|that fixed point arithmetic is faster than floating-point arithmetic |
|since integer instructions are faster so I would ask about the second|
|point put by Adam that mathematical functions are slow with          |
|fixed-point numbers. Can you please elaborate on that?               |
|                                                                     |
|Thanks                                                               |
|YC"                                                                  |
|---------------------------------------------------------------------|

That ceased to be true for (then) new mainstream desktops during the
1990's when Intel Pentiums became popular. Unfortunately people who
create books do not always bother to check if claims they make in them
became out of date during a previous decade. For example, Colin Paul
Gloster, "Book Review: "Optimization Algorithms in Physics"",
"International Journal of Nonlinear Sciences and Numerical
Simulation", June 2010, Vol. 11, No. 6, Pages 387-388.

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Friday, January 25, 2013 1:23:38 PM UTC+1, Paul Colin Gloster wrote:

> That ceased to be true for (then) new mainstream desktops during the
> 
> 1990's when Intel Pentiums became popular. Unfortunately people who
> 
> create books do not always bother to check if claims they make in them
> 
> became out of date during a previous decade. For example, Colin Paul
> 
> Gloster, "Book Review: "Optimization Algorithms in Physics"",
> 
> "International Journal of Nonlinear Sciences and Numerical
> 
> Simulation", June 2010, Vol. 11, No. 6, Pages 387-388.

Thanks for this additional information and for the Book Review example. Good to know!

YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

What about using fixed point number representation for loop counters? It is common for example we have a time index in a program that is increasing with a value say t:= t + 0.01 seconds for each index in a loop. After a while, the floating-point representation will start failing in accuracy and at time t = 0.68 seconds, the number might actually be 0.67999992 for example.

But a fixed point number representation can avoid this. 

YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Shark8]

On Friday, February 1, 2013 4:53:56 AM UTC-6, Ada novice wrote:
> What about using fixed point number representation for loop counters? It is common for example we have a time index in a program that is increasing with a value say t:= t + 0.01 seconds for each index in a loop. After a while, the floating-point representation will start failing in accuracy and at time t = 0.68 seconds, the number might actually be 0.67999992 for example.
> 
> 
> 
> But a fixed point number representation can avoid this. 

Something like this:
For Index in Some_Range with Delta X loop
 ...
End loop;

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

Hi,
    Does the syntax which you gave work?

Thanks
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Nasser M. Abbasi]

On 2/1/2013 4:53 AM, Ada novice wrote:
> What about using fixed point number representation for loop counters?
> It is common for example we have a time index in a program that
>is increasing with a value say t:= t + 0.01 seconds for each index in a loop

Well, it is common only in sloppy programming.

loop counters should always be discrete. as in integers,
enumeration set, etc...

In Matlab, they do anything and it runs since there is
no error checking, but it will be code full of bugs. I am sure
in Ada the loop counter must belong to a discrete type. One
good thing in Ada about Ada.

For your example, one will find the length, say number of samples,
and use a natural for an index, and inside the loop, then
access the data using this index.

The data itself can be float ofcourse. Much safer than using
the index itself for the time steps update.

--Nasser

Re: Numerical calculations: Why not use fixed point types for everything?

[Shark8]

On Saturday, February 2, 2013 12:55:43 PM UTC-6, Ada novice wrote:
> Hi,
> 
>     Does the syntax which you gave work?

Nope, I was just asking if that's what you had in mind.

The question, however, does allow for me to say that the following works:

    Type P is delta 0.1 digits 3 range 0.0..10.0;
    
    declare
	Index : P := P'First;
    begin
	loop
	    Ada.Text_IO.Put_Line( Index'Img );
	    Exit when Index = P'Last;
	    Index:= P'Succ(Index);
	End loop;
    end;

And you could use that in, say, your generic bodies to iterate over the fixed-point range.

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Saturday, February 2, 2013 10:08:50 PM UTC+1, Nasser M. Abbasi wrote:

> 
> Well, it is common only in sloppy programming.
> 
> 
> 
> loop counters should always be discrete. as in integers,
> 

I do not think we should judge things too quickly. By having a "delta" that we can explicitly specify, this can make the code simpler to understand. Look at this code:

with Ada.Text_IO;             use Ada.Text_IO;
with Ada.Long_Float_Text_IO;  use Ada.Long_Float_Text_IO;

procedure Step_Freq is
   Count : Integer;
   Frequency : Long_Float;
   Frequency_Start : constant := -44.88;
   Frequency_Step  : constant := (67.32 - Frequency_Start) / 299.0;
   Delta_Frequency : Long_Float;

 begin
   Count := 0;
   Frequency := Frequency_Start;
   for I in 1..300 loop
       Frequency := Frequency_Start + Frequency_Step * Long_Float (I - 1);
       if I = 2 then
          Delta_Frequency := abs(Frequency - Frequency_Start);
          Put (Item => Delta_Frequency, Fore => 3, Aft => 5, Exp => 0); Put("  ");
          Put (Item => Frequency_Step, Fore => 3, Aft => 5, Exp => 0);
          New_Line;
       end if;
       Count := Count + 1;
   end loop;
    Put_Line ("Count after loop is" & Integer'Image (Count));
    New_Line;
    Put (Item => Frequency, Fore => 3, Aft => 3, Exp => 0);
end Step_Freq;

Well, I am using a discrete loop counter. But is this the best way to go about for such a simple example? What if I want the Frequency_Step to take a specific value? Then I will have perhaps to play with the range and the amount of discrete points I need in order to arrive at a desired Frequency_Step in the code. So why not use fixed-point for the frequency as we know exactly what step we want?

Thanks.
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Sunday, February 3, 2013 5:05:22 AM UTC+1, Shark8 wrote:
> 
> 
>     Type P is delta 0.1 digits 3 range 0.0..10.0;
> 
>     
> 
>     declare
> 
> 	Index : P := P'First;
> 
>     begin
> 
> 	loop
> 
> 	    Ada.Text_IO.Put_Line( Index'Img );
> 
> 	    Exit when Index = P'Last;
> 
> 	    Index:= P'Succ(Index);
> 
> 	End loop;
> 
>     end;
> 

I was working an example based on the working code you gave:

with Ada.Text_IO;
with Ada.Long_Float_Text_IO;

procedure Test is

type P is delta 0.1 digits 3 range 0.0..10.0;

        Index: P := P'First;
        Number   : Long_Float := 100.0;


   begin
      loop
         Ada.Text_IO.Put(Index'Img);Ada.Text_IO.Put("  ");

         Ada.Long_Float_Text_IO.Put (Item => Long_Float(Index)*Number, Fore => 3, Aft  => 3, Exp  => 0);Ada.Text_IO.Put("  ");

         --Number := Long_Float(Index)*Number;
         Ada.Long_Float_Text_IO.Put (Item => Number, Fore => 3, Aft  => 3, Exp  => 0);

         Ada.Text_IO.New_Line;

         exit when Index = P'Last;

         Index := P'Succ(Index);


      end loop;

end Test;


On running I get:

 0.0    0.000  100.000
 0.1   10.000  100.000
 0.2   20.000  100.000
 0.3   30.000  100.000
 0.4   40.000  100.000
 0.5   50.000  100.000
... and so on

which is expected.

Now, when I un-comment the line 

--Number := Long_Float(Index)*Number;

and run the code again, I get:

 0.0    0.000    0.000
 0.1    0.000    0.000
 0.2    0.000    0.000
 0.3    0.000    0.000
 0.4    0.000    0.000
 0.5    0.000    0.000

... and so on.

This is a weird behaviour. Why are the second and third columns all zeros now?

Thanks.
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Niklas Holsti]

On 13-02-04 08:23 , Ada novice wrote:
> On Sunday, February 3, 2013 5:05:22 AM UTC+1, Shark8 wrote:
>>
>>
>>     Type P is delta 0.1 digits 3 range 0.0..10.0;
>>
>>     
>>
>>     declare
>>
>> 	Index : P := P'First;
>>
>>     begin
>>
>> 	loop
>>
>> 	    Ada.Text_IO.Put_Line( Index'Img );
>>
>> 	    Exit when Index = P'Last;
>>
>> 	    Index:= P'Succ(Index);
>>
>> 	End loop;
>>
>>     end;
>>
> 
> I was working an example based on the working code you gave:
> 
> with Ada.Text_IO;
> with Ada.Long_Float_Text_IO;
> 
> procedure Test is
> 
> type P is delta 0.1 digits 3 range 0.0..10.0;
> 
>         Index: P := P'First;
>         Number   : Long_Float := 100.0;
> 
> 
>    begin
>       loop
>          Ada.Text_IO.Put(Index'Img);Ada.Text_IO.Put("  ");
> 
>          Ada.Long_Float_Text_IO.Put (Item => Long_Float(Index)*Number, Fore => 3, Aft  => 3, Exp  => 0);Ada.Text_IO.Put("  ");
> 
>          --Number := Long_Float(Index)*Number;
>          Ada.Long_Float_Text_IO.Put (Item => Number, Fore => 3, Aft  => 3, Exp  => 0);
> 
>          Ada.Text_IO.New_Line;
> 
>          exit when Index = P'Last;
> 
>          Index := P'Succ(Index);
> 
> 
>       end loop;
> 
> end Test;
> 
> 
> On running I get:
> 
>  0.0    0.000  100.000
>  0.1   10.000  100.000
>  0.2   20.000  100.000
>  0.3   30.000  100.000
>  0.4   40.000  100.000
>  0.5   50.000  100.000
> ... and so on
> 
> which is expected.
> 
> Now, when I un-comment the line 
> 
> --Number := Long_Float(Index)*Number;
> 
> and run the code again, I get:
> 
>  0.0    0.000    0.000
>  0.1    0.000    0.000
>  0.2    0.000    0.000
>  0.3    0.000    0.000
>  0.4    0.000    0.000
>  0.5    0.000    0.000
> 
> ... and so on.
> 
> This is a weird behaviour.

No, it is expected.

> Why are the second and third columns all zeros now?

On the first iteration of the loop, Index = 0.0. Therefore the
uncommented statemement assigns the value Long_Float (0.0) * Number,
which is zero, to Number. In the next iteration the same statement
assigns Long_Float (0.1) * Number, which is again zero, to Number. So
Number stays at zero throughout the loop.

Perhaps you intended to assign a different variable? As in

   Number2 := Long_Float (Index) * Number;


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Monday, February 4, 2013 7:43:14 AM UTC+1, Niklas Holsti wrote:
> 
>    Number2 := Long_Float (Index) * Number;


Beginner's mistake! Thanks.

YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Niklas Holsti]

On 13-02-04 09:27 , Ada novice wrote:
> On Monday, February 4, 2013 7:43:14 AM UTC+1, Niklas Holsti wrote:
>>
>>    Number2 := Long_Float (Index) * Number;
> 
> 
> Beginner's mistake! Thanks.

Perhaps Ada could have helped to avoid this mistake? You could have
thought about how you intended to use the Number variable, when you
declared it. If you did not intend to change it, you could have declared
it constant:

   Number : constant Long_Float := 100.0;

and then the compiler would have complained about the assignment
statement which changes Number.

In experimental programs like this, one often forgets to think about
constant vs variable, or about proper names for variables. But on the
average, I think it saves time, even when one is experimenting.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Monday, February 4, 2013 10:37:49 AM UTC+1, Niklas Holsti wrote:
> 
>    Number : constant Long_Float := 100.0;
 
When assigning constants, I always use

     Number : constant := 100.0

and then lets the compiler decides how it wants to treat the constant when say multiplying with a type such as integer, float etc. Is this good practice?

 
> In experimental programs like this, one often forgets to think about
> 
> constant vs variable, or about proper names for variables. But on the
> 
> average, I think it saves time, even when one is experimenting.
> 

Definitely well said. When the focus is on something else, one can get sloppy on other important aspects.


Thanks.
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Niklas Holsti]

On 13-02-04 12:09 , Ada novice wrote:
> On Monday, February 4, 2013 10:37:49 AM UTC+1, Niklas Holsti wrote:
>> 
>>    Number : constant Long_Float := 100.0;
> 
> When assigning constants, I always use
> 
>    Number : constant := 100.0
> 
> and then lets the compiler decides how it wants to treat the constant
> when say multiplying with a type such as integer,

(You can't multiply 100.0 with an integer, unless you do a type
conversion or define your own multiplication operator.)

> float etc. Is this good practice?

Depends. Such type-less "named numbers" (in Ada-speak) have different
properties than typed constant objects: if you combine them in an
expression, the compiler uses unbounded-precision and unbounded-range
arithmetic, which may or may not be what you want; and they match any
integer or floating-point type, respectively, which again may or may not
be what you want. In other words, if you declare:

   Max_Number_Of_Apples : constant := 42;

you may mistakenly use Max_Number_Of_Apples in a place where you are
counting oranges. But if you define different types, Apple_Count_Type
and Orange_Count_Type, and then declare

   Max_Number_Of_Apples : constant Apple_Count_Type := 42;

then the compiler should detect if this constant is used in an
orange-counting context.

I use named numbers (usually integers) when I want to be absolutely sure
that all computation with them is done statically, at compile-time, or
when I want to give other parts of the program the ability to use the
same numbers with various types (which is not often sensible). Nowadays
I mostly use typed constant objects.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Numerical calculations: Why not use fixed point types for everything?

[Jeffrey Carter]

On 02/04/2013 07:24 AM, Niklas Holsti wrote:
> On 13-02-04 12:09 , Ada novice wrote:
>>
>> When assigning constants, I always use
>>
>>     Number : constant := 100.0
>>
>> and then lets the compiler decides how it wants to treat the constant
>> when say multiplying with a type such as integer,
>
> (You can't multiply 100.0 with an integer, unless you do a type
> conversion or define your own multiplication operator.)

Sure you can.

    Twice : constant := 2 * Number;
    Half  : constant := Number / 2;

are both legal (ARM 4.5.5).

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Numerical calculations: Why not use fixed point types for everything?

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Depends. Such type-less "named numbers" (in Ada-speak) have different
> properties than typed constant objects: if you combine them in an
> expression, the compiler uses unbounded-precision and unbounded-range
> arithmetic, ...

That's true for all static expressions, not just ones involving
named numbers.

>... which may or may not be what you want; and they match any
> integer or floating-point type, respectively, which again may or may not
> be what you want.

Right.

- Bob

Re: Numerical calculations: Why not use fixed point types for everything?

[Niklas Holsti]

On 13-02-04 18:44 , Jeffrey Carter wrote:
> On 02/04/2013 07:24 AM, Niklas Holsti wrote:
>> On 13-02-04 12:09 , Ada novice wrote:
>>>
>>> When assigning constants, I always use
>>>
>>>     Number : constant := 100.0
>>>
>>> and then lets the compiler decides how it wants to treat the constant
>>> when say multiplying with a type such as integer,
>>
>> (You can't multiply 100.0 with an integer, unless you do a type
>> conversion or define your own multiplication operator.)
> 
> Sure you can.
> 
>    Twice : constant := 2 * Number;
>    Half  : constant := Number / 2;
> 
> are both legal (ARM 4.5.5).

You are right, and I stand corrected: you can compute with mixtures of
integral named numbers and real named numbers to provide values for new
real named numbers, if I've understood that ARM point correctly.

But I also forgot about another thing: you can compute I * Number, where
I is an Integer variable, since Number can be considered to be
universal_fixed, and fixed-point types can be multiplied by Integer.

So what YC said about multiplication of integers and named real numbers
is correct.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Numerical calculations: Why not use fixed point types for everything?

[Niklas Holsti]

On 13-02-04 19:31 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> Depends. Such type-less "named numbers" (in Ada-speak) have different
>> properties than typed constant objects: if you combine them in an
>> expression, the compiler uses unbounded-precision and unbounded-range
>> arithmetic, ...
> 
> That's true for all static expressions, not just ones involving
> named numbers.

Yes. But the rules for what expression are static are a bit complex (or
at least longish), while using only named numbers is a simple rule of
thumb for me.

Moreover, the compiler will complain if the expression for a named
number is not static for some reason, but will accept a non-static
expression for a constant object.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Numerical calculations: Why not use fixed point types for everything?

[Randy Brukardt]

"Ada novice" <shai.lesh@gmx.com> wrote in message 
news:c81e7d23-8757-4a81-9ca2-d540afe0d819@googlegroups.com...
On Saturday, February 2, 2013 10:08:50 PM UTC+1, Nasser M. Abbasi wrote:

>>
>> Well, it is common only in sloppy programming.
>>
>>
>>
>> loop counters should always be discrete. as in integers,

>I do not think we should judge things too quickly.

I tend to agree with you in general, but your example seems to demostrate 
the OPs point...

>By having a "delta" that we can explicitly specify, this can make the code 
>simpler to understand. Look at this code:
>
>with Ada.Text_IO;             use Ada.Text_IO;
>with Ada.Long_Float_Text_IO;  use Ada.Long_Float_Text_IO;
>
>procedure Step_Freq is
>   Count : Integer;
>   Frequency : Long_Float;
>   Frequency_Start : constant := -44.88;
>   Frequency_Step  : constant := (67.32 - Frequency_Start) / 299.0;

This 299 seems related to the one in the loop below. As such, I think it 
should have a named constant:
    Steps : constant := 300;
   Frequency_Step  : constant := (67.32 - Frequency_Start) / (Steps-1);
[Aside: This is legal even though the denominator is integer because of the 
extra operators defined in 4.5.5(17). And examples like this is why.]

>   Delta_Frequency : Long_Float;
>
> begin
>   Count := 0;
>   Frequency := Frequency_Start;
>   for I in 1..300 loop
     for I in 0 .. Step-1 loop
         -- This avoids the odd "-1" in the loop below. If you had directly 
used I somewhere
         -- else, this might not work, but it does in this example.
>       Frequency := Frequency_Start + Frequency_Step * Long_Float (I - 1);
       Frequency := Frequency_Start + Frequency_Step * Long_Float (I);
>       if I = 2 then
      if I = 1 then
>          Delta_Frequency := abs(Frequency - Frequency_Start);
>          Put (Item => Delta_Frequency, Fore => 3, Aft => 5, Exp => 0); 
> Put("  ");
>          Put (Item => Frequency_Step, Fore => 3, Aft => 5, Exp => 0);
>          New_Line;
>       end if;
>       Count := Count + 1;
    --?? Besides the fact that this isn't even used in the loop, it has the 
same value as I
    -- (or I-1 in the original code). Why duplicate the value? One the huge 
benefits of
    -- Ada is that you don't have to start every range at 0 or 1 - do 
whatever your
    -- program needs.
>   end loop;
>    Put_Line ("Count after loop is" & Integer'Image (Count));
    -- Unless your program is *really* buggy, this is just the constant 
Step.
>    New_Line;
>    Put (Item => Frequency, Fore => 3, Aft => 3, Exp => 0);
>end Step_Freq;
>
>Well, I am using a discrete loop counter. But is this the best way to go 
>about for such
>a simple example? What if I want the Frequency_Step to take a specific 
>value? Then
>I will have perhaps to play with the range and the amount of discrete 
>points I need in
>order to arrive at a desired Frequency_Step in the code.

Nah, all you need to do is make the Step value calculated from the 
Frequency_Step, rather than the reverse.

>So why not use fixed-point for the frequency as we know exactly what step 
>we want?

The main reason is that you almost always need to get your data from an 
array somewhere, and you use the for loop parameter ("I" in this case) to 
get the values from the array, and then use the float version of the step 
for the calculation. With the exception of benchmarks, I don't think I've 
ever written a loop that does exactly the same thing 300 times without 
changing the input data. (When such things appear to happen, usually you can 
refactor the expression to avoid the loop altogether, which is usually 300 
times faster.)

                                                             Randy.

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Tuesday, February 5, 2013 3:27:58 AM UTC+1, Randy Brukardt wrote:
> 
> >with Ada.Text_IO;             use Ada.Text_IO;
> 
> >with Ada.Long_Float_Text_IO;  use Ada.Long_Float_Text_IO;
> 
> >
> 
> >procedure Step_Freq is
> 
> >   Count : Integer;
> 
> >   Frequency : Long_Float;
> 
> >   Frequency_Start : constant := -44.88;
> 
> >   Frequency_Step  : constant := (67.32 - Frequency_Start) / 299.0;
> 
> 
> 
> This 299 seems related to the one in the loop below. As such, I think it 
> 
> should have a named constant:
> 
>     Steps : constant := 300;
> 
>    Frequency_Step  : constant := (67.32 - Frequency_Start) / (Steps-1);
> 
> [Aside: This is legal even though the denominator is integer because of the 
> 
> extra operators defined in 4.5.5(17). And examples like this is why.]
> 
> 
> 
> >   Delta_Frequency : Long_Float;
> 
> >
> 
> > begin
> 
> >   Count := 0;
> 
> >   Frequency := Frequency_Start;
> 
> >   for I in 1..300 loop
> 
>      for I in 0 .. Step-1 loop
> 
>          -- This avoids the odd "-1" in the loop below. If you had directly 
> 
> used I somewhere
> 


Yes this is correct. Your code is a good alternative of mine.

> 
>       if I = 1 then
> 
> >          Delta_Frequency := abs(Frequency - Frequency_Start);
> 
> >          Put (Item => Delta_Frequency, Fore => 3, Aft => 5, Exp => 0); 
> 
> > Put("  ");
> 
> >          Put (Item => Frequency_Step, Fore => 3, Aft => 5, Exp => 0);
> 
> >          New_Line;
> 
> >       end if;
> 
> >       Count := Count + 1;
> 
>     --?? Besides the fact that this isn't even used in the loop, it has the 
> 
> same value as I
> 
>     -- (or I-1 in the original code). Why duplicate the value? 


Well I am just outputting the index counter I at the end which is 300. How do you get to output of the end value of the index counter otherwise?




> >    Put_Line ("Count after loop is" & Integer'Image (Count));
> 
>     -- Unless your program is *really* buggy, this is just the constant 


Yes I know. See my answer above.



> 
> Step.
> 
> >    New_Line;
> 
> >    Put (Item => Frequency, Fore => 3, Aft => 3, Exp => 0);
> 
> >end Step_Freq;
> 
> >
> 
> >Well, I am using a discrete loop counter. But is this the best way to go 
> 
> >about for such
> 
> >a simple example? What if I want the Frequency_Step to take a specific 
> 
> >value? Then
> 
> >I will have perhaps to play with the range and the amount of discrete 
> 
> >points I need in
> 
> >order to arrive at a desired Frequency_Step in the code.
> 
> 
> 
> Nah, all you need to do is make the Step value calculated from the 
> 
> Frequency_Step, rather than the reverse.
> 
> 
> 
> >So why not use fixed-point for the frequency as we know exactly what step 
> 
> >we want?
> 
> 
> 
> The main reason is that you almost always need to get your data from an 
> 
> array somewhere, and you use the for loop parameter ("I" in this case) to 
> 
> get the values from the array, and then use the float version of the step 
> 
> for the calculation. With the exception of benchmarks, I don't think I've 
> 
> ever written a loop that does exactly the same thing 300 times without 
> 
> changing the input data. (When such things appear to happen, usually you can 
> 
> refactor the expression to avoid the loop altogether, which is usually 300 
> 
> times faster.)
> 

In this example, Frequency is changing at every index in the loop. Its first value is -44.88 and its final value is 67.32. This Frequency can be used further in a calculation. 

If you would have read the code well, you would have seen that the loop is not doing 300 times exactly the same thing.

Thanks
YC

Re: Numerical calculations: Why not use fixed point types for everything?

[Randy Brukardt]

"Ada novice" <shai.lesh@gmx.com> wrote in message 
news:4b654b06-f2d2-4ced-8508-c10e5c84e29d@googlegroups.com...
> On Tuesday, February 5, 2013 3:27:58 AM UTC+1, Randy Brukardt wrote:
...
>> The main reason is that you almost always need to get your data from an
>> array somewhere, and you use the for loop parameter ("I" in this case) to
>> get the values from the array, and then use the float version of the step
>> for the calculation. With the exception of benchmarks, I don't think I've
>> ever written a loop that does exactly the same thing 300 times without
>> changing the input data. (When such things appear to happen, usually you 
>> can
>> refactor the expression to avoid the loop altogether, which is usually 
>> 300
>> times faster.)
>
> In this example, Frequency is changing at every index in the loop. Its 
> first value is -44.88 and its
> final value is 67.32. This Frequency can be used further in a calculation.
>
> If you would have read the code well, you would have seen that the loop is 
> not doing 300 times
> exactly the same thing.

I'm not talking about doing *exactly* the same thing (that is using the same 
values over and over). You clearly missed my point: unless there is some 
varying data in the loop, you can almost always use a reorganization of the 
loop in order to eliminate it completely, because you are executing the same 
*formula* each time thru the loop. And usually, you can apply various 
loop-hoisting transformations to pull the useful parts of the loop out. 
Consider this following version of your code using the frequency in a 
calculation:

    Total := 0.0;
    for I in 0 .. Step-1 loop
       Frequency := Frequency_Start + Frequency_Step * Long_Float (I);
       Total := Total + Frequency*Some_Constant;
    end loop;

Here, I've used the frequency in a calculation. "Some_Constant" is just that 
(or it could have been a variable not modified by the loop [a parameter, for 
instance], that wouldn't change anything). [Quick aside: The sorts of 
refactoring that I'm about to do might change the accuracy of the result --  
I didn't try to figure out whether that is a danger or not.]

Anyway, let's see if we can simplify this loop (this is the sort of thing a 
compiler would try to do, but it can't know if you can tolerate different 
accuracy, so it probably could not do everything you can do). First, let's 
get rid of the extra variable:

    Total := 0.0;
    for I in 0 .. Step-1 loop
        Total := Total + (Frequency_Start + Frequency_Step * Long_Float 
(I))*Some_Constant;
    end loop;

Now we can distribute Some_Constant and remove a set of parens:

    Total := 0.0;
    for I in 0 .. Step-1 loop
        Total := Total + Frequency_Start*Some_Constant + Frequency_Step* 
Long_Float (I)*Some_Constant;
    end loop;

Now, Frequency_Start*Some_Constant does not depend on the loop index, and it 
is going to be executed Step times. So there is no reason to execute it 
inside the loop. So let's pull that out of the loop:

    Total := Frequency_Start*Some_Constant*Long_Float(Step);
    for I in 0 .. Step-1 loop
        Total := Total + Frequency_Step* Long_Float (I)*Some_Constant;
    end loop;

What's left here can be refactored further by noting that 
Frequency_Step*Some_Constant don't depend on the loop index, either. So 
let's pull that out of the loop, too:

    Total := Frequency_Start*Some_Constant*Long_Float(Step);
    Sum := 0;
    for I in 0 .. Step-1 loop
         Sum := Sum + I;
    end loop;
    Total := Total + Frequency_Step* Some_Constant*Long_Float(Sum);

But, since Step is a constant, the value of Sum can be figured out once, 
declared as a constant and plugged in. (I know there is a formula for that 
which I forget at the moment, but that formula could be used in the constant 
declaration to avoid the magic number.)

    Total := Frequency_Start*Some_Constant*Long_Float(Step);
    Total := Total + Frequency_Step* Some_Constant*Long_Float(Sum_Constant);

And voila! No loop!

My point was that most loops can be refactored this way unless there is some 
varying data in them. (And the best loop execution-wise is no loop.) And 
indeed, most of the loops like this that I've written involve processing 
(summarizing, often) an array of data. In which case you need an array 
index; and usually you can convert that index into the factor by some 
technique. So iteration by fixed point values or the like makes for 
interesting examples, but won't happen that often in practice.

                                                      Randy.

Re: Numerical calculations: Why not use fixed point types for everything?

[Shark8]

Nicely explained, Randy.

The sum formula is either n*(n-1)/2 or n*(n+1)/2, I forget which.

Re: Numerical calculations: Why not use fixed point types for everything?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:2414e19f-1d1c-4fb4-b727-76437ef099f7@googlegroups.com...
> Nicely explained, Randy.
>
> The sum formula is either n*(n-1)/2 or n*(n+1)/2, I forget which.

Yup. I think which one is right depends on whether you start counting at 0 
(in that case, it's the right-hand one) or at 1.

It stuck me this morning that you can't do a transformation like this in the 
case of power series (like a Taylor series); I don't want to appear to be 
claiming that this can ALWAYS be done, but in most cases it can be done. And 
executing a handful of operations rather than hundreds is going to be faster 
and probably more accurate.

                                 Randy.

Re: Numerical calculations: Why not use fixed point types for everything?

[Ada novice]

On Thursday, February 7, 2013 7:03:33 AM UTC+1, Randy Brukardt wrote:

> 
> 
> My point was that most loops can be refactored this way unless there is some 
> 
> varying data in them. (And the best loop execution-wise is no loop.) And 
> 
> indeed, most of the loops like this that I've written involve processing 
> 
> (summarizing, often) an array of data. In which case you need an array 
> 
> index; and usually you can convert that index into the factor by some 
> 
> technique. So iteration by fixed point values or the like makes for 
> 
> interesting examples, but won't happen that often in practice.
> 
> 
> 
>                                                       Randy.

Thanks for your interesting message. I agree with you that one needs to simplify the code as far as possible. In most situations where I use loops, it is because at each index, I am computing some new variables that need to be stored (for example in a time integration routine). In this case, I can't get rid of the loop construct because of the "varying data".