| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 61:52:01 |
| Calls: | 633 |
| Calls today: | 1 |
| Files: | 1,188 |
| D/L today: |
32 files (20,076K bytes) |
| Messages: | 181,453 |
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
On 8/13/2025 9:21 PM, Woozy Song wrote:
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
I tried it with gfortran version 15, just for fun, and I got the same result.
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
On Thu, 14 Aug 2025 11:21:00 +0800, Woozy Song wrote:
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
Broken as designed, according to the spec.
Why on Earth does FRACTION have this meaning?
On Fri, 15 Aug 2025 22:24:52 +0000, Lawrence DrCOOliveiro wrote:
On Thu, 14 Aug 2025 11:21:00 +0800, Woozy Song wrote:
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
Broken as designed, according to the spec.
Why on Earth does FRACTION have this meaning?
To what spec are you referring?
gfortran is giving the correct answer (although
I suspect OP has a transcription problem with
the second example).
On 8/16/2025 7:02 PM, Steven G. Kargl wrote:
On Fri, 15 Aug 2025 22:24:52 +0000, Lawrence DrCOOliveiro wrote:
On Thu, 14 Aug 2025 11:21:00 +0800, Woozy Song wrote:
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
Broken as designed, according to the spec.
Why on Earth does FRACTION have this meaning?
To what spec are you referring?
gfortran is giving the correct answer (although
I suspect OP has a transcription problem with
the second example).
I think most casual, non-math, non-floating point experts would expect this:
I think most casual, non-math, non-floating point experts would expect
this:
"The fractional part of a real number is the decimal portion of the
number, excluding the integer part. It represents the difference between
the real number and its integer part.
On Sat, 16 Aug 2025 20:40:13 -0500, Gary Scott wrote:
I think most casual, non-math, non-floating point experts would expect
this:
"The fractional part of a real number is the decimal portion of the
number, excluding the integer part. It represents the difference between
the real number and its integer part.
Sure. Except that computers typically do not represent floating-point
numbers in decimal, but in binary. This is the significance of the rCLmodel representationrCY phrase in the language spec.
The way you describe is obviously the most natural interpretation, these days. And most other languages do it that way. But not Fortran.
On Sat, 16 Aug 2025 20:40:13 -0500, Gary Scott wrote:
I think most casual, non-math, non-floating point experts would expect
this:
"The fractional part of a real number is the decimal portion of the
number, excluding the integer part. It represents the difference between
the real number and its integer part.
Sure. Except that computers typically do not represent floating-point numbers in decimal, but in binary. This is the significance of the rCLmodel representationrCY phrase in the language spec.
The way you describe is obviously the most natural interpretation, these days. And most other languages do it that way. But not Fortran.
On Sat, 16 Aug 2025 20:40:13 -0500, Gary Scott wrote:
On 8/16/2025 7:02 PM, Steven G. Kargl wrote:
On Fri, 15 Aug 2025 22:24:52 +0000, Lawrence DrCOOliveiro wrote:
On Thu, 14 Aug 2025 11:21:00 +0800, Woozy Song wrote:
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
Broken as designed, according to the spec.
Why on Earth does FRACTION have this meaning?
To what spec are you referring?
gfortran is giving the correct answer (although
I suspect OP has a transcription problem with
the second example).
I think most casual, non-math, non-floating point experts would expect this:
For someone programming in the Fortran language, I would expect
that they would consult some form of documentation to learn why
their expectation might be wrong. For example, the gfortran
documentation (which comes with the compiler) contains
8.119 rCyFRACTIONrCO -- Fractional part of the model representation ===============================================================
_Synopsis_:
rCyY = FRACTION(X)rCO
_Description_:
rCyFRACTION(X)rCO returns the fractional part of the model
representation of rCyXrCO.
_Class_:
Elemental function
_Arguments_:
X The type of the argument shall be a rCyREALrCO.
_Return value_:
The return value is of the same type and kind as the argument. The
fractional part of the model representation of rCyXrCO is returned; it
is rCyX * RADIX(X)**(-EXPONENT(X))rCO.
_Example_:
program test_fraction
real :: x
x = 178.1387e-4
print *, fraction(x), x * radix(x)**(-exponent(x))
end program test_fraction
Am 8/17/25 um 05:18 schrieb Steven G. Kargl:
On Sat, 16 Aug 2025 20:40:13 -0500, Gary Scott wrote:
On 8/16/2025 7:02 PM, Steven G. Kargl wrote:
On Fri, 15 Aug 2025 22:24:52 +0000, Lawrence DrCOOliveiro wrote:
On Thu, 14 Aug 2025 11:21:00 +0800, Woozy Song wrote:
A program was going wrong, and found
FRACTION(3.75)=0.9375 and FRACTION(2.5)=0.9375
Broken as designed, according to the spec.
Why on Earth does FRACTION have this meaning?
To what spec are you referring?
gfortran is giving the correct answer (although
I suspect OP has a transcription problem with
the second example).
I think most casual, non-math, non-floating point experts would expect this:
For someone programming in the Fortran language, I would expect
that they would consult some form of documentation to learn why
their expectation might be wrong. For example, the gfortran
documentation (which comes with the compiler) contains
8.119 rCyFRACTIONrCO -- Fractional part of the model representation
===============================================================
_Synopsis_:
rCyY = FRACTION(X)rCO
_Description_:
rCyFRACTION(X)rCO returns the fractional part of the model
representation of rCyXrCO.
_Class_:
Elemental function
_Arguments_:
X The type of the argument shall be a rCyREALrCO.
_Return value_:
The return value is of the same type and kind as the argument. The
fractional part of the model representation of rCyXrCO is returned; it >> is rCyX * RADIX(X)**(-EXPONENT(X))rCO.
_Example_:
program test_fraction
real :: x
x = 178.1387e-4
print *, fraction(x), x * radix(x)**(-exponent(x))
end program test_fraction
Thank you, Steve.
The following program, adapted from the Example in the documentation you cite:
program test_fraction
real :: x
x = 3.75
print *, fraction(x), x
print *, x * radix(x)**(-exponent(x))
end program test_fraction
prints:
0.937500000 3.75000000
0.00000000
but I was expecting it to print:
0.937500000 3.75000000
0.937500000
because the documentation says that fraction(x) is the same as x * radix(x)**(-exponent(x)) .
I suggest that the documentation is wrong, and should say
' ... model representation of rCyXrCO is returned; it is rCyX * REAL(RADIX(X))**(-EXPONENT(X))rCO.
Concerning the OP's finding that FRACTION(2.5) is printed as 0.9375:
I cannot reproduce that with gfortran 11.5.0 or 13.3.1 or 14.2.1 which all correctly calculate 0.625 .
So to me this is a documentation bug, and possibly a bug in gfortran 12.2 .
On Tue, 19 Aug 2025 12:15:37 +0200, Kay Diederichs wrote:
So to me this is a documentation bug, and possibly a bug in gfortran
12.2 .
Looks like you've found a documentation bug. The Fortran standard
actually has
On Sat, 16 Aug 2025 20:40:13 -0500, Gary Scott wrote:
I think most casual, non-math, non-floating point experts would expect
this:
"The fractional part of a real number is the decimal portion of the
number, excluding the integer part. It represents the difference between
the real number and its integer part.
Sure. Except that computers typically do not represent floating-point
numbers in decimal, but in binary. This is the significance of the rCLmodel representationrCY phrase in the language spec.
The way you describe is obviously the most natural interpretation, these days. And most other languages do it that way. But not Fortran.
Le 17/08/2025 |a 09:15, Lawrence DrCOOliveiro a |-crit-a:
The way you describe is obviously the most natural interpretation,
these days. And most other languages do it that way. But not
Fortran.
Can you elaborate on what these "most other languages" are ? I
cannot find any intrinsic function that corresponds to the "most
natural interpretation" in most of the popular languages around (C,
C++, Pthon, Java, Rust, Matlab...)
On Mon, 8 Sep 2025 15:25:28 +0200, pehache wrote:
Le 17/08/2025 |a 09:15, Lawrence DrCOOliveiro a |-crit :
The way you describe is obviously the most natural interpretation,
these days. And most other languages do it that way. But not
Fortran.
Can you elaborate on what these "most other languages" are ? I
cannot find any intrinsic function that corresponds to the "most
natural interpretation" in most of the popular languages around (C,
C++, Pthon, Java, Rust, Matlab...)
Python doesnrCOt have a fraction() function as such,
but it does have
modf <https://docs.python.org/3/library/math.html#math.modf>, which is documented as returning rCLthe fractional and integer partsrCY of its argument.
Using the same examples as started this thread:
ldo@theon:~> python3 -ic "import math"
>>> math.modf(3.75)
(0.75, 3.0)
>>> math.modf(2.5)
(0.5, 2.0)
On Mon, 8 Sep 2025 15:25:28 +0200, pehache wrote:
Le 17/08/2025 |a 09:15, Lawrence DrCOOliveiro a |-crit :
The way you describe is obviously the most natural interpretation,
these days. And most other languages do it that way. But not
Fortran.
Can you elaborate on what these "most other languages" are ? I
cannot find any intrinsic function that corresponds to the "most
natural interpretation" in most of the popular languages around (C,
C++, Pthon, Java, Rust, Matlab...)
Python doesnrCOt have a fraction() function as such,
but it does have
modf <https://docs.python.org/3/library/math.html#math.modf>, which is documented as returning rCLthe fractional and integer partsrCY of its argument.
Using the same examples as started this thread:
ldo@theon:~> python3 -ic "import math"
>>> math.modf(3.75)
(0.75, 3.0)
>>> math.modf(2.5)
(0.5, 2.0)
Le 09/09/2025 |a 00:16, Lawrence DrCOOliveiro a |-crit :
Python doesnrCOt have a fraction() function as such,
Neither any of the other languages. In contrast to your initial
assertion.
but it does have modf
<https://docs.python.org/3/library/math.html#math.modf>, which is
documented as returning rCLthe fractional and integer partsrCY of its
argument.
Which is a behavior that you can hardly guess without reading the
doc, same as `FRACTION()` in Fortran.
On Tue, 9 Sep 2025 08:09:12 +0200, pehache wrote:
Le 09/09/2025 |a 00:16, Lawrence DrCOOliveiro a |-crit :
Python doesnrCOt have a fraction() function as such,
Neither any of the other languages. In contrast to your initial
assertion.
WHAT rCLinitial assertionrCY?
but it does have modf
<https://docs.python.org/3/library/math.html#math.modf>, which is
documented as returning rCLthe fractional and integer partsrCY of its
argument.
Which is a behavior that you can hardly guess without reading the
doc, same as `FRACTION()` in Fortran.
Maybe check the actual Fortran docs and behaviour? We *did* discuss
all this in the thread, you know.
Seeing python's modf() does not lends itself to a "most natural interpretation"
On Tue, 9 Sep 2025 15:16:08 -0000 (UTC), Steven G. Kargl wrote:
Seeing python's modf() does not lends itself to a "most natural
interpretation"
ldo@theon:~> python3 -ic "import math"
>>> fraction = lambda x : math.modf(x)[0]
>>> fraction(3.75)
0.75
>>> fraction(2.5)
0.5
On Tue, 9 Sep 2025 08:09:12 +0200, pehache wrote:
Le 09/09/2025 |a 00:16, Lawrence DrCOOliveiro a |-crit :
Python doesnrCOt have a fraction() function as such,
Neither any of the other languages. In contrast to your initial
assertion.
WHAT rCLinitial assertionrCY?
but it does have modf
<https://docs.python.org/3/library/math.html#math.modf>, which is
documented as returning rCLthe fractional and integer partsrCY of its
argument.
Which is a behavior that you can hardly guess without reading the
doc, same as `FRACTION()` in Fortran.
Maybe check the actual Fortran docs and behaviour?
We *did* discuss
all this in the thread, you know.
On Tue, 9 Sep 2025 15:16:08 -0000 (UTC), Steven G. Kargl wrote:
Seeing python's modf() does not lends itself to a "most natural
interpretation"
ldo@theon:~> python3 -ic "import math"
>>> fraction = lambda x : math.modf(x)[0]
>>> fraction(3.75)
0.75
>>> fraction(2.5)
0.5
We are still waiting what are these natural ways to get a fractional
part of these other languages.
This is precisely the advice you have received, instead of complaining
that `FRACTION()` doesn't do what you thought it was doing.
Le 10/09/2025 |a 00:41, Lawrence DrCOOliveiro a |-crit-a:
ldo@theon:~> python3 -ic "import math"
>>> fraction = lambda x : math.modf(x)[0]
>>> fraction(3.75)
0.75
>>> fraction(2.5)
0.5
And how do you know how `modf()` works without reading the
documentation?
Intent to column 7 and the following worked over 66 years ago.
program real_kinds
real x
fraction(x) = mod(x,1.)
x = 3.12345
print *, fraction(x)
end program real_kinds
On Wed, 10 Sep 2025 08:25:04 +0200, pehache wrote:
Le 10/09/2025 |a 00:41, Lawrence DrCOOliveiro a |-crit-a:
ldo@theon:~> python3 -ic "import math"
>>> fraction = lambda x : math.modf(x)[0]
>>> fraction(3.75)
0.75
>>> fraction(2.5)
0.5
And how do you know how `modf()` works without reading the
documentation?
The point being, it gives a more natural (i.e. less-surprising) result
than Fortran. That is the point I was trying to make -- the nub of my
gist, if you will. Or even if you wonrCOt. Do not try to distract from
that.
On Wed, 10 Sep 2025 02:15:55 -0000 (UTC), Steven G. Kargl wrote:
Intent to column 7 and the following worked over 66 years ago.
program real_kinds
real x fraction(x) = mod(x,1.)
x = 3.12345 print *, fraction(x)
end program real_kinds
Ignoring the fact thatrCOs not valid FORTRAN 66 or FORTRAN IV (what other spec was valid 66 years ago?), itrCOs not relevant to the FRACTION()
function we are discussing, is it?
The following program, adapted from the Example in the documentation you cite:
program test_fraction
-a real :: x
-a x = 3.75
-a print *, fraction(x), x
-a print *, x * radix(x)**(-exponent(x))
end program test_fraction
prints:
-a 0.937500000-a-a-a-a-a-a 3.75000000
-a-a 0.00000000
but I was expecting it to print:
-a 0.937500000-a-a-a-a-a-a 3.75000000
-a 0.937500000
because the documentation says that fraction(x) is the same as-a x * radix(x)**(-exponent(x)) .