Freepascal Floating Point Issue

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Ralf Quint
On 8/24/2017 2:18 AM, Sven Barth via fpc-pascal wrote:

Am 23.08.2017 02:16 schrieb "Paul Nance" <[hidden email]>:
>
> Turbo Pascal also had a BCD unit.

Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and operators as well operator overloads.

And where would such gem be hiding? It's not in neither my Lazarus 1.6/FPC 3.02 nor the Lazarus 1.8RC4/FPC 3.04 installs...

Ralf

Virus-free. www.avast.com

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Tomas Hajny-2
On Thu, August 24, 2017 22:25, Ralf Quint wrote:

> On 8/24/2017 2:18 AM, Sven Barth via fpc-pascal wrote:
>>
>> Am 23.08.2017 02:16 schrieb "Paul Nance" <[hidden email]
>> <mailto:[hidden email]>>:
>> >
>> > Turbo Pascal also had a BCD unit.
>>
>> Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
>> operators as well operator overloads.
>>
> And where would such gem be hiding? It's not in neither my Lazarus
> 1.6/FPC 3.02 nor the Lazarus 1.8RC4/FPC 3.04 installs...

Good point... It's in package rtl-objpas. I can see it included in the
standard FPC 3.0.2 installation, but it's missing in 3.0.4 at the moment,
because it got lost in the transition from fpcmake to fpmake apparently.
Fortunately, that should be rather easy to fix. :-)

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Bernd Oppolzer
In reply to this post by el_es

Am 24.08.2017 um 15:02 schrieb el es:

> On 24/08/17 13:26, Sven Barth via fpc-pascal wrote:
> [...]
>> Note: FPC (and Delphi) has a single fixed point type which is
>> Currency. AFAIK it uses four digits after the comma and 28 in front
>> of it.
>>
>> Regards, Sven
>>
> There was a project I remember, that I was told, for some e.g. tax purposes,
> 4 digits after the decimal point are not enough to round them properly...
> That is because, the calculation of e.g. VAT has to work out both ways (total=net+VAT and
> has to work out in every way, including when a bigger package is split into smaller units)
> and 4 decimal digits are not always enough to ensure this (and the program had to work
> internationally with all the different tax rules too) for arbitrarily large quantities, prices and tax bands.
>
> I don't remember the exact details (it long time ago and couple of workplaces ago), of what they did,
> but the team developing it (in D7) was pretty stressed...

When you do calculations of actual values of
on-board securities, you need 8 digits after the decimal point
and more, because the stock quotation already has 6 digits after
the decimal point, and you have to multiply that with the quantity,
which has decimal parts, too.

With decimal arithmetic, rounded multiplication is pretty simple:
you multiply the two items, giving a result with one decimal digit
more as you need, then you round the result.

In PL/1:

    value = round (multiply (quantity, quotation, 15, 3), 2);

gives the rounded value in Euro, no matter how many digits after
the decimal point quantity and quotation had. The multiply function
will take care of the proper scaling and stop after the third digit
which is sufficient to round at the second position.

Kind regards

Bernd


> -l.
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Bernd Oppolzer
In reply to this post by Zaaphod
Am 24.08.2017 um 14:00 schrieb James Richters:

Thanks everyone for the explanation and solutions.  I can work around it well enough now that I understand what’s happening, but I’m still curious if there is a way to define fixed point variables?  In a C++ Project I was helping with recently, they had a way of defining a variable as having 2 places before the decimal and 30 places after?  Since the decimal could never move (float) It ended up being much better defined.   It’s like always moving the decimal over 30 places to the right, using integer math, then moving it back.  I’m not sure if this was something the compiler did, or if maybe they had their own functions to do this… I had a difficult time following how things worked, but I do remember the fixed point variables.  Anyway I thought I would just ask the question in case there is a way to define this in FreePascal

 

It seems to me that if you know you never need more than a fixed number of places before and after the decimal, then moving the decimal over the maximum number of places, performing integer math, which would round to the nearest integer(and cut off the useless garbage), then moving the decimal back would mean a fixed amount of precision with the benefit that one could do things like exact conditionals and get the expected result

 

James

 



IBM mainframes have decimal data types involving 31 decimal digits
(maximum); the numbers of digits left and right of the decimal point
may be chosen freely. The types are all compatible and promoted to
floating point, when necessary. The mainframe languages, like PL/1
and COBOL, support them natively, and mainframe C, too:

   int x, y;
   decimal (15,2) amt;
   ...

These decimal data types are supported by the hardware (by
machine instructions). This was an optional feature in the 1960s,
but the modern machines of today all support it.

The decimal data is implemented as BCD data; hex digits are
decimal digits, and a sign half byte is added, that makes 16 bytes
for 31 digits. If shorter numbers are needed, less bytes are allocated
(all lengths from 1 to 16 are supported). All decimal fields have
odd numbers of digits.

I am thinking about adding support for decimal data in one of the
next versions of my Stanford Pascal compiler, which targets this
platform, as well as Windows, Linux, macOS etc.; of course, this
decimal format will need to be emulated on the non-mainframe
platforms.

For some years now, the mainframe also supports floating point
data based on a decimal representation. But I don't have experience
with this so far. Some compilers support this (PL/1).

Kind regards

Bernd


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Ched
And under "modern" Windows, the extended type, which is fully supported by the FPU, is *degraded* to
double. So, I can't do high precision computation with fpc even if the native hardware permits such
computations. I'm glued to XP as the full capabilities of the FPU were on the hands of programmers, years
ago.

Cheers, Ched'




Le 24.08.2017 à 21:31, Bernd Oppolzer a écrit :

> Am 24.08.2017 um 14:00 schrieb James Richters:
>>
>> Thanks everyone for the explanation and solutions.  I can work around it well enough now that I
>> understand what’s happening, but I’m still curious if there is a way to define fixed point variables?  
>> In a C++ Project I was helping with recently, they had a way of defining a variable as having 2 places
>> before the decimal and 30 places after? Since the decimal could never move (float) It ended up being
>> much better defined.   It’s like always moving the decimal over 30 places to the right, using integer
>> math, then moving it back.  I’m not sure if this was something the compiler did, or if maybe they had
>> their own functions to do this… I had a difficult time following how things worked, but I do remember
>> the fixed point variables.  Anyway I thought I would just ask the question in case there is a way to
>> define this in FreePascal
>>
>> It seems to me that if you know you never need more than a fixed number of places before and after the
>> decimal, then moving the decimal over the maximum number of places, performing integer math, which
>> would round to the nearest integer(and cut off the useless garbage), then moving the decimal back would
>> mean a fixed amount of precision with the benefit that one could do things like exact conditionals and
>> get the expected result
>>
>> James
>>
>>
>
> IBM mainframes have decimal data types involving 31 decimal digits
> (maximum); the numbers of digits left and right of the decimal point
> may be chosen freely. The types are all compatible and promoted to
> floating point, when necessary. The mainframe languages, like PL/1
> and COBOL, support them natively, and mainframe C, too:
>
>     int x, y;
>     decimal (15,2) amt;
>     ...
>
> These decimal data types are supported by the hardware (by
> machine instructions). This was an optional feature in the 1960s,
> but the modern machines of today all support it.
>
> The decimal data is implemented as BCD data; hex digits are
> decimal digits, and a sign half byte is added, that makes 16 bytes
> for 31 digits. If shorter numbers are needed, less bytes are allocated
> (all lengths from 1 to 16 are supported). All decimal fields have
> odd numbers of digits.
>
> I am thinking about adding support for decimal data in one of the
> next versions of my Stanford Pascal compiler, which targets this
> platform, as well as Windows, Linux, macOS etc.; of course, this
> decimal format will need to be emulated on the non-mainframe
> platforms.
>
> For some years now, the mainframe also supports floating point
> data based on a decimal representation. But I don't have experience
> with this so far. Some compilers support this (PL/1).
>
> Kind regards
>
> Bernd
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Free Pascal - General mailing list

Am 24.08.2017 23:46 schrieb "Ched" <[hidden email]>:
>
> And under "modern" Windows, the extended type, which is fully supported by the FPU, is *degraded* to double. So, I can't do high precision computation with fpc even if the native hardware permits such computations. I'm glued to XP as the full capabilities of the FPU were on the hands of programmers, years ago.

Please note that this is only true for the 64-bit variants of Windows with 64-bit software. 32-bit software on those systems can use the FPU without any problems (in fact even 64-bit software can, but since Microsoft declared it as deprecated for the 64-bit mode it might happen in the future that it is no longer supported).

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Ralf Quint
In reply to this post by Ched
On 8/24/2017 2:45 PM, Ched wrote:
> And under "modern" Windows, the extended type, which is fully
> supported by the FPU, is *degraded* to double. So, I can't do high
> precision computation with fpc even if the native hardware permits
> such computations. I'm glued to XP as the full capabilities of the FPU
> were on the hands of programmers, years ago.
It's not a problem of "modern" Windows, but a problem of any 64bit x86
OS that in that "long" mode the FPU does NOT support the extended data
type (80 bits, 10 bytes). In 32bit mode, the FPU is using the "old" x87
FP unit on the chip, in 64bit mode, it is using the SSE FP unit, which
doesn't have those 80 bit registers, it's 64 bit only (and several times
faster).
So that you can use that with your Windows XP version is likely due to
the fact that this is a 32bit version, not XP Professional 64 (or
Windows Server 2003 64 for that matter).

There are apparently some ways to enable the FP calculation to use the
x87 FPU and therefor the possibility of those 80 bit registers on Inter
chips (so far), but for one, this runs significantly slower that the SSE
FPU, and then this is apparently not supported by (all) AMD CPUs, so you
are limiting yourself also on which systems your code can run...

Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Free Pascal - General mailing list

Am 25.08.2017 01:33 schrieb "Ralf Quint" <[hidden email]>:
>
> On 8/24/2017 2:45 PM, Ched wrote:
> > And under "modern" Windows, the extended type, which is fully
> > supported by the FPU, is *degraded* to double. So, I can't do high
> > precision computation with fpc even if the native hardware permits
> > such computations. I'm glued to XP as the full capabilities of the FPU
> > were on the hands of programmers, years ago.
> It's not a problem of "modern" Windows, but a problem of any 64bit x86
> OS that in that "long" mode the FPU does NOT support the extended data
> type (80 bits, 10 bytes). In 32bit mode, the FPU is using the "old" x87
> FP unit on the chip, in 64bit mode, it is using the SSE FP unit, which
> doesn't have those 80 bit registers, it's 64 bit only (and several times
> faster).
> So that you can use that with your Windows XP version is likely due to
> the fact that this is a 32bit version, not XP Professional 64 (or
> Windows Server 2003 64 for that matter).
>
> There are apparently some ways to enable the FP calculation to use the
> x87 FPU and therefor the possibility of those 80 bit registers on Inter
> chips (so far), but for one, this runs significantly slower that the SSE
> FPU, and then this is apparently not supported by (all) AMD CPUs, so you
> are limiting yourself also on which systems your code can run...

Plase note that all non-Windows 64-bit systems have no problems with enabling the FPU and even Windows needs to handle it due to 32-bit software requiring it.
The only x86_64 OS we support that doesn't have Extended enabled (by default) *is* Win64.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Michael Schnell
In reply to this post by Benito van der Zander
On 23.08.2017 14:11, Benito van der Zander wrote:
>> Btw, anyone know about a BCD math implementation for Free Pascal, like
>> it used to be implemented in DR CBASIC? (those were the days... ;-) )
Why do BCD math if you need a predefined number of correct digits after
the "point"  and a "limited" count of digits before ?

Here you could do Int64 and consider a factor of 1/10^n. Would be a lot
faster.

Seems like a candidate for type helper and overloading "*" and "div".

-Michael



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Michael Schnell
In reply to this post by Ralf Quint
On 25.08.2017 01:32, Ralf Quint wrote:
>
> It's not a problem of "modern" Windows, but a problem of any 64bit x86
> OS
Supposedly of (m)any non-x64 archs as well.

Hence relying on "extended" is not portable.

-Michael


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Free Pascal - General mailing list
In reply to this post by Tomas Hajny-2

Am 24.08.2017 23:26 schrieb "Tomas Hajny" <[hidden email]>:
>
> On Thu, August 24, 2017 22:25, Ralf Quint wrote:
> > On 8/24/2017 2:18 AM, Sven Barth via fpc-pascal wrote:
> >>
> >> Am 23.08.2017 02:16 schrieb "Paul Nance" <[hidden email]
> >> <mailto:[hidden email]>>:
> >> >
> >> > Turbo Pascal also had a BCD unit.
> >>
> >> Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
> >> operators as well operator overloads.
> >>
> > And where would such gem be hiding? It's not in neither my Lazarus
> > 1.6/FPC 3.02 nor the Lazarus 1.8RC4/FPC 3.04 installs...
>
> Good point... It's in package rtl-objpas. I can see it included in the
> standard FPC 3.0.2 installation, but it's missing in 3.0.4 at the moment,
> because it got lost in the transition from fpcmake to fpmake apparently.
> Fortunately, that should be rather easy to fix. :-)

Hmm? It's mentioned in both the trunk and the branches/fixes_3.0.0 rtl-objpas fpmake.pp file and that wasn't changed since the branch if 3.0.0. So when the unit is indeed missing in 3.0.4rc1 then that needs to be looked at.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Tomas Hajny-2
On Fri, August 25, 2017 14:31, Sven Barth via fpc-pascal wrote:
 .
 .

>> Good point... It's in package rtl-objpas. I can see it included in the
>> standard FPC 3.0.2 installation, but it's missing in 3.0.4 at the
>> moment,
>> because it got lost in the transition from fpcmake to fpmake apparently.
>> Fortunately, that should be rather easy to fix. :-)
>
> Hmm? It's mentioned in both the trunk and the branches/fixes_3.0.0
> rtl-objpas fpmake.pp file and that wasn't changed since the branch if
> 3.0.0. So when the unit is indeed missing in 3.0.4rc1 then that needs to
> be looked at.

Oops, sorry, you're right, it's there - I must have typed wrongly when
searching for it. :-( In that case it should be in 3.0.4rc1 too (I'm on
holiday with a limited connection, so I can't check it easily at the
moment).

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Ched
In reply to this post by Michael Schnell
Hello,

I agree that the extended type is not portable and not as fast as double.

But sometimes, we absolutely need numerical precision, so we have to assume the costs in terms of runtime
and possibly nonportability. When the algorithms are nearly optimal, there is no room for software
enhancement. So, the programmers, not the OS makers !, has to do the choices about accuracy, runtime and
hardware configuration. For my numerical problems, I absolutely need "full" extended, not just doubles.

As the 18-19 digits extended type is availables in Freepascal for the common Intel processors, I don't
understand why we will have no more the right to use it under x64 OS...

Cheers, Ched



Le 25.08.2017 à 08:08, Michael Schnell a écrit :

> On 25.08.2017 01:32, Ralf Quint wrote:
>>
>> It's not a problem of "modern" Windows, but a problem of any 64bit x86
>> OS
> Supposedly of (m)any non-x64 archs as well.
>
> Hence relying on "extended" is not portable.
>
> -Michael
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Free Pascal - General mailing list

Am 28.08.2017 00:32 schrieb "Ched" <[hidden email]>:
>
> Hello,
>
> I agree that the extended type is not portable and not as fast as double.
>
> But sometimes, we absolutely need numerical precision, so we have to assume the costs in terms of runtime and possibly nonportability. When the algorithms are nearly optimal, there is no room for software enhancement. So, the programmers, not the OS makers !, has to do the choices about accuracy, runtime and hardware configuration. For my numerical problems, I absolutely need "full" extended, not just doubles.
>
> As the 18-19 digits extended type is availables in Freepascal for the common Intel processors, I don't understand why we will have no more the right to use it under x64 OS...

Because Microsoft declared it as deprecated. That means that should Microsoft ever bring out a 64-bit only OS they can simply disable the FPU handling in their kernel (e.g. saving the FPU state during a context switch) and then you are doomed and they did even warn you about this, cause they declared the x87 as deprecated from the beginning on Win64.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Michael Schnell
In reply to this post by Ched
On 28.08.2017 00:23, Ched wrote:
> But sometimes, we absolutely need numerical precision, so we have to
> assume the costs in terms of runtime and possibly nonportability.
I understand that when compiling to an x32 32 Bit executable, 80 Bit
Extended should be fine.

-Michael

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Michael Schnell
In reply to this post by Free Pascal - General mailing list
On 28.08.2017 08:04, Sven Barth via fpc-pascal wrote:I don't understand
why we will have no more the right to use it under x64 OS...
>
> Because Microsoft declared it as deprecated. That means that should
> Microsoft ever bring out a 64-bit only OS ...
>
In fact this still is a (mere) portability problem. Supposedly in such a
64-bit only OS, 32 bit executables will not lose "extended" but will not
be able to be started at all.

In fact I suppose there will be possibilities to run them in a virtual
machine. E.g. Virtual Box already can build up an invisible "one window"
virtual machine for a single running program.

-Michael


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Florian Klämpfl
In reply to this post by Ched
Am 24.08.2017 um 23:45 schrieb Ched:
> And under "modern" Windows, the extended type, which is fully supported
> by the FPU, is *degraded* to double. So, I can't do high precision
> computation with fpc even if the native hardware permits such
> computations.

FP permits it too, just recompile it with
FPC_SUPPORT_X87_TYPES_ON_WIN64. But be aware: MS might disable extended
support at any time on 64 bit windows as the types are marked as deprecated.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Freepascal Floating Point Issue

Free Pascal - General mailing list
In reply to this post by Michael Schnell

Am 29.08.2017 08:35 schrieb "Michael Schnell" <[hidden email]>:
>
> On 28.08.2017 08:04, Sven Barth via fpc-pascal wrote:I don't understand why we will have no more the right to use it under x64 OS...
>>
>>
>> Because Microsoft declared it as deprecated. That means that should Microsoft ever bring out a 64-bit only OS ...
>>
> In fact this still is a (mere) portability problem. Supposedly in such a 64-bit only OS, 32 bit executables will not lose "extended" but will not be able to be started at all.
>
> In fact I suppose there will be possibilities to run them in a virtual machine. E.g. Virtual Box already can build up an invisible "one window" virtual machine for a single running program.
>

The point here was if the FPU is used in a x64 process, which *is* possible, but disabled by default in the compiler.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12