minimal-width E or ES format
jfh
numbers it would sometimes help to have the E omitted. The standard
says this will happen with something like
print '(ES8.1)', 2d200
which will give 2.0+200 instead of 2.0E+200, but is there a way to
make this happen with exponents that need only 2 digits, like 2.0+20
instead of 2.0E+20? Of course it can be done by writing the number to
a character variable and manipulating and printing it, but I had hoped
there might be a value of e in ES8.1Ee, or some other format, that
would do the job. Am I right in thinking there is none?
-- John Harper
robin
| If one wants to minimize the size of one's output with large or small
| numbers it would sometimes help to have the E omitted. The standard
| says this will happen with something like
|
| print '(ES8.1)', 2d200
|
| which will give 2.0+200 instead of 2.0E+200, but is there a way to
| make this happen with exponents that need only 2 digits, like 2.0+20
| instead of 2.0E+20?
It might be useful to drop the '+' sign, so that the number still
looks like a normal float, viz., 2.0E200.
| Of course it can be done by writing the number to
| a character variable and manipulating and printing it, but I had hoped
| there might be a value of e in ES8.1Ee, or some other format, that
| would do the job. Am I right in thinking there is none?
Such a facility is available with PL/I with a picture specification.
In a picture format specification, it's possible to specify that the
letter 'E' is omitted. It's also posible to specify the number of digits in the exponent.
The sign can be omitted if the value is known to be positive.
Thus: 9.V9E999 would give 2.0E200
9.V9KS999 would give 2.0+200
Ron Shepard
<4b0738a0-1462-416c...@x20g2000pro.googlegroups.com>,
jfh <john....@vuw.ac.nz> wrote:
I'm not certain, but I think you are right. There are some new
formatting options in f2003 that I have not examined in detail.
This issue gets back to a recurring complaint I've had about formatting
in fortran (which goes back even before f77). There are two fairly
common things that need to be done with floating point numbers. One is
to write the number to a fixed-width field in such a way that the
maximum number of significant digits is output, and the other is to
specify the number of significant digits that need to be output and have
the minimum field width adjust as necessary. Neither of these tasks are
straightforward to do with fortran format fields. My solutions to do
these things have been to write the values into a character string in
either an F or E (or ES since f90) format, and then operate on the
string as necessary (remove leading spaces and optional + signs, remove
leading zeros in the exponent field, remove the E for negative
exponents, etc.). At least the ES format eliminates the leading zero in
the mantissa (in f77 you needed 1PEw.d for this, but you had to be
careful), so I guess things are going in the right direction, just very
very slowly.
$.02 -Ron Shepard
robin
news:ron-shepard-77F9...@news60.forteinc.com...
| In article
| <4b0738a0-1462-416c...@x20g2000pro.googlegroups.com>,
| jfh <john....@vuw.ac.nz> wrote:
|
| > If one wants to minimize the size of one's output with large or small
| > numbers it would sometimes help to have the E omitted. The standard
| > says this will happen with something like
| >
| > print '(ES8.1)', 2d200
| >
| > which will give 2.0+200 instead of 2.0E+200, but is there a way to
| > make this happen with exponents that need only 2 digits, like 2.0+20
| > instead of 2.0E+20? Of course it can be done by writing the number to
| > a character variable and manipulating and printing it, but I had hoped
| > there might be a value of e in ES8.1Ee, or some other format, that
| > would do the job. Am I right in thinking there is none?
|
| I'm not certain, but I think you are right. There are some new
| formatting options in f2003 that I have not examined in detail.
|
| This issue gets back to a recurring complaint I've had about formatting
| in fortran (which goes back even before f77). There are two fairly
| common things that need to be done with floating point numbers. One is
| to write the number to a fixed-width field in such a way that the
| maximum number of significant digits is output, and the other is to
| specify the number of significant digits that need to be output and have
| the minimum field width adjust as necessary. Neither of these tasks are
| straightforward to do with fortran format fields.
The G-format directly permits the first of these.
As for the second, that would require processing in a string.
A G-format again helps.
You could select one of four formats that provides 1, 2, 3, or 4
exponent digits. TRIM can remove any leading and trailing blanks.
An exponent '+' can be easily removed.
Ron Shepard
"robin" <rob...@dodo.com.au> wrote:
No, it can't possibly accomplish that because it is defined to use F
and E formatting, which, as discussed above, does not accomplish the
goal. Specifically, I don't think there is a G format which will
print the string 1234E9. That is a six-character field that prints
four significant digits for that value. There are many of these
situations, just do a few by hand to see the range of possibilities.
> As for the second, that would require processing in a string.
> A G-format again helps.
> You could select one of four formats that provides 1, 2, 3, or 4
> exponent digits. TRIM can remove any leading and trailing blanks.
> An exponent '+' can be easily removed.
Yes, I described in my previous post how to do such character
processing. However, to accomplish the goal you must also test when
to switch between F and E type output formats because G switches at
the wrong places. All this can be done, and I have done it for some
special cases, but it would be much simpler for the user of the
language if there were a standard fortran format that would
accomplish these commonly needed tasks.
$.02 -Ron Shepard
Richard Maine
> In article <4cb6ffe1$0$55987$c30e...@exi-reader.telstra.net>,
> "robin" <rob...@dodo.com.au> wrote:
>
> > "Ron Shepard" <ron-s...@NOSPAM.comcast.net> wrote in message
> > news:ron-shepard-77F9...@news60.forteinc.com...
> > | This issue gets back to a recurring complaint I've had about formatting
> > | in fortran (which goes back even before f77). There are two fairly
> > | common things that need to be done with floating point numbers. One is
> > | to write the number to a fixed-width field in such a way that the
> > | maximum number of significant digits is output, and the other is to
> > | specify the number of significant digits that need to be output and have
> > | the minimum field width adjust as necessary. Neither of these tasks are
> > | straightforward to do with fortran format fields.
> >
> > The G-format directly permits the first of these.
>
> No, it can't possibly accomplish that because it is defined to use F
> and E formatting, which, as discussed above, does not accomplish the
> goal.
In fact, G format is spectacularly bad about that. I have fairly
specific memories of it. In days of yore when most of my group's data
was on punched cards, we used to format arrays with 10-column fields so
that we could fit 8 of them on a card. Getting an acceptable number of
significant digits in 10 columns was tricky.
Different array elements sometimes varied widely in magnitude even
within the same array, but were still significant. I preferred to use G
format because I found the F formatting more readable when the magnitude
was such as to allow it, but I couldn't just use F because some fields
were way too large or small for that.
I also liked to use 1P with my E formats, just because I was more
accustomed to it as scientific notation.
Unfortunately, 1PG format could not guarantee more than *3* significant
digits in a 10-character field, and that just wasn't enough. I could
barely accept 4, but 3 was beyond the pale. Yes, I'm very confident of
that number. If you think it should be 4, then you missed a quirk. I
don't feel like digging out the details at the moment. I think it
happened only with the 1P, and that you could get 4 significant digits
with the default 0P - not that 4 was great either. That quirk was even
the subject of my first communication with the standard's committee
(long before I was a member or had even met a member). I am convinced it
was an off-by-one error in a formula in the standard, as I could see no
sensible rationale for it. The reply I got from X3J3 said that vendors
had already implemented and released compilers to the standard as it was
written, so they weren't going to change it.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Ron Shepard
nos...@see.signature (Richard Maine) wrote:
>
> I also liked to use 1P with my E formats, just because I was more
> accustomed to it as scientific notation.
Yes, also because it eliminates the leading 0 which is a waste of space.
But you have to be careful with 1P (even now in modern fortran) because
it works as a mode toggle for the rest of the format, it does not apply
to just that one E field. And if you print a number with an F field
later in that format, it will then be off by a factor of 10.
$.02 -Ron Shepard
Richard Maine
Yes, I know. but it wasn't just the "wasted space" of the leading 0. I
think (not bothering to check, but it is what I recall) that the
compiler has to drop the 0 if that's what it takes to fit into the
field, so that was ok.
It also wasn't the "sticky" nature of 1P and its strange behavior with
F. I've seen that one before. A close co-worker was tearing his hair
out (and to look at him now, it appears to have worked :-)) trying to
figure out why a program of his was giving results off by a factor of
10. Turns out the results were fine - just printed "oddly".
Instead, it was a quirk specific to 1P and G. If I recall correctly,
G10.4 (without the 1P) means 4 significant digits, regardless of whether
it prints in an E or F format. But 1PG10.4 means 3 significant digits
when it uses F, but 4 significant digits when it uses E. (Or maybe I
have that backwards). You'd have to go to G10.5 to get 4 significant
digits with F, but then it is too wide for the field (giving *'s) with
E. Something like that. It made no sense at all. I swear the only
explanation was that someone got the arithmetic off by 1 when writing
the formulae in the standard.
robin
Your stated goal is to write out the maximum number of digits,
which G does.
| Specifically, I don't think there is a G format which will
| print the string 1234E9. That is a six-character field that prints
| four significant digits for that value. There are many of these
| situations, just do a few by hand to see the range of possibilities.
|
| > As for the second, that would require processing in a string.
| > A G-format again helps.
| > You could select one of four formats that provides 1, 2, 3, or 4
| > exponent digits. TRIM can remove any leading and trailing blanks.
| > An exponent '+' can be easily removed.
|
| Yes, I described in my previous post how to do such character
| processing. However, to accomplish the goal you must also test when
| to switch between F and E type output formats because G switches at
| the wrong places.
You didn't say that before, so how do you expect
appropriate advice when you don't specify what you want?
glen herrmannsfeldt
(snip)
> It also wasn't the "sticky" nature of 1P and its strange behavior with
> F. I've seen that one before. A close co-worker was tearing his hair
> out (and to look at him now, it appears to have worked :-)) trying to
> figure out why a program of his was giving results off by a factor of
> 10. Turns out the results were fine - just printed "oddly".
> Instead, it was a quirk specific to 1P and G. If I recall correctly,
> G10.4 (without the 1P) means 4 significant digits, regardless of whether
> it prints in an E or F format. But 1PG10.4 means 3 significant digits
> when it uses F, but 4 significant digits when it uses E. (Or maybe I
> have that backwards). You'd have to go to G10.5 to get 4 significant
> digits with F, but then it is too wide for the field (giving *'s) with
> E. Something like that. It made no sense at all. I swear the only
> explanation was that someone got the arithmetic off by 1 when writing
> the formulae in the standard.
Well, G10.4 gives the results of either E10.4 or F10.4, which
seems obvious enough to me. 1PG10.4 gives either 1PE10.4 or F10.4
(without the 1P for the reason given above). (Or I10 or L10 or A10.)
The d in Fw.d, Ew.d, or Gw.d gives the number of digits after
the decimal point. So, yes, that does mean a different number
of significant digits.
The definition of Fw.d and Ew.d go back to Fortran I, Gw.d came
sometime later.
-- glen
Ron Shepard
"robin" <rob...@dodo.com.au> wrote:
> | > | This issue gets back to a recurring complaint I've had about formatting
> | > | in fortran (which goes back even before f77). There are two fairly
> | > | common things that need to be done with floating point numbers. One is
> | > | to write the number to a fixed-width field in such a way that the
> | > | maximum number of significant digits is output, and the other is to
> | > | specify the number of significant digits that need to be output and have
> | > | the minimum field width adjust as necessary. Neither of these tasks are
> | > | straightforward to do with fortran format fields.
> | >
> | > The G-format directly permits the first of these.
> |
> | No, it can't possibly accomplish that because it is defined to use F
> | and E formatting, which, as discussed above, does not accomplish the
> | goal.
>
> Your stated goal is to write out the maximum number of digits,
> which G does.
>
> | Specifically, I don't think there is a G format which will
> | print the string 1234E9. That is a six-character field that prints
> | four significant digits for that value. There are many of these
> | situations, just do a few by hand to see the range of possibilities.
Well, I thought I had explained this before, but ok, let's see if a
G field works.
program format
write(*,'(g6.4)') 1234e9
end program format
$ gfortran format.f90
$ a.out
******
Oops. That G format does *NOT* write out the maximum number of
digits (4 in this example) in that six-character field. If there is
such a G format that prints four significant digits in a
six-character field, please show it. I don't think there is one.
Of course, I knew it did not work when I made my previous posts, and
I even gave that value as an example of a number where a G format
does not work.
> | Yes, I described in my previous post how to do such character
> | processing. However, to accomplish the goal you must also test when
> | to switch between F and E type output formats because G switches at
> | the wrong places.
>
> You didn't say that before, so how do you expect
> appropriate advice when you don't specify what you want?
If you read the above post, you will see what I specified.
"One is to write the number to a fixed-width field in such a way
that the maximum number of significant digits is output, and the
other is to specify the number of significant digits that need to be
output and have the minimum field width adjust as necessary.
Neither of these tasks are straightforward to do with fortran format
fields."
So for the second task, I would want the value 1234e9 to be written
out with four significant digits, and I would want the field width
to be adjusted to its minimum value (which is 6 for this value). It
is fairly easy to see how to do this for this value with character
editing. You might first write the value using, say, a 4pe11.4
field. This would result in the string " 1234.0E+09". You would
then remove the ".0", the "+0", and the leading space to get the
desired result. However, this is somewhat difficult to do in
general, which is why it should be included as one of the standard
formatting fields.
BTW, there is not always a unique way of writing the value in the
minimum field width, so there should be some kind of ranking method
to choose which of the equivalent strings to write.
$.02 -Ron Shepard
Colin Watters
> "One is to write the number to a fixed-width field in such a way
> that the maximum number of significant digits is output, and the
> other is to specify the number of significant digits that need to be
> output and have the minimum field width adjust as necessary.
> Neither of these tasks are straightforward to do with fortran format
> fields."
>
> So for the second task, I would want the value 1234e9 to be written
> out with four significant digits, and I would want the field width
> to be adjusted to its minimum value (which is 6 for this value). It
> is fairly easy to see how to do this for this value with character
> editing. You might first write the value using, say, a 4pe11.4
> field. This would result in the string " 1234.0E+09". You would
> then remove the ".0", the "+0", and the leading space to get the
> desired result. However, this is somewhat difficult to do in
> general, which is why it should be included as one of the standard
> formatting fields.
>
> BTW, there is not always a unique way of writing the value in the
> minimum field width, so there should be some kind of ranking method
> to choose which of the equivalent strings to write.
>
> $.02 -Ron Shepard
I too would dearly love the language to do this for me. Absent this featute
I do it myself, using lots of code and CPU cycles. I posted the code nearly
4 years ago, see
http://groups.google.com/group/comp.lang.fortran/msg/e54cc49eed61b1bd?&q=rcompact
...Smart it isn't, compact it isn't, but work, ... yes it does. As I said
at the time, there *HAS* to be a better way.
--
Qolin
Email: my qname at domain dot com
Domain: qomputing
robin
| In article <4cb7ab21$0$55986$c30e...@exi-reader.telstra.net>,
| "robin" <rob...@dodo.com.au> wrote:
|
| > | > | This issue gets back to a recurring complaint I've had about formatting
| > | > | in fortran (which goes back even before f77). There are two fairly
| > | > | common things that need to be done with floating point numbers. One is
| > | > | to write the number to a fixed-width field in such a way that the
| > | > | maximum number of significant digits is output, and the other is to
| > | > | specify the number of significant digits that need to be output and have
| > | > | the minimum field width adjust as necessary. Neither of these tasks are
| > | > | straightforward to do with fortran format fields.
| > | >
| > | > The G-format directly permits the first of these.
| > |
| > | No, it can't possibly accomplish that because it is defined to use F
| > | and E formatting, which, as discussed above, does not accomplish the
| > | goal.
| >
| > Your stated goal is to write out the maximum number of digits,
| > which G does.
| >
| > | Specifically, I don't think there is a G format which will
| > | print the string 1234E9. That is a six-character field that prints
| > | four significant digits for that value. There are many of these
| > | situations, just do a few by hand to see the range of possibilities.
|
| Well, I thought I had explained this before, but ok, let's see if a
| G field works.
As I said, your stated goal is to write out the maximum number of digits"
You wrote:--"One is to write the number to a fixed-width field in such a way that the
" maximum number of significant digits is output"
G-format obviously does that.
| program format
| write(*,'(g6.4)') 1234e9
| end program format
You are obviously being deliberately abstruse with that stupid
example, which could never possibly work.
You need to go and read the manual to find out what G-format actually
will do for you.
| $ gfortran format.f90
| $ a.out
| ******
|
| Oops. That G format does *NOT* write out the maximum number of
| digits (4 in this example) in that six-character field.
Obviously not; the field width is grossly too small.
| If there is
| such a G format that prints four significant digits in a
| six-character field, please show it. I don't think there is one.
| Of course, I knew it did not work when I made my previous posts, and
| I even gave that value as an example of a number where a G format
| does not work.
You need to read the manual to find out how G-fornmat works.
robin
| I too would dearly love the language to do this for me. Absent this featute
| I do it myself, using lots of code and CPU cycles. I posted the code nearly
| 4 years ago, see
|
| http://groups.google.com/group/comp.lang.fortran/msg/e54cc49eed61b1bd?&q=rcompact
|
| ...Smart it isn't, compact it isn't, but work, ... yes it does. As I said
| at the time, there *HAS* to be a better way.
Yes there is, and that's to use a language, such as PL/I,
that supports the feature.
In PL/I a simple picture format is all that's required:--
'DDDDvED'
dpb
...
> Yes there is, and that's to use a language, such as PL/I,
> that supports the feature.
...
So, every time one finds some peculiar little subfeature a particular
language supports, that's reason to convert a full codebase? Not...
--
Ron Shepard
"robin" <rob...@dodo.com.au> wrote:
[...]
> As I said, your stated goal is to write out the maximum number of digits"
> You wrote:--"One is to write the number to a fixed-width field in such a way
> that the
> " maximum number of significant digits is output"
>
> G-format obviously does that.
No, it obviously does not, and I gave an example. Here it is again.
> | program format
> | write(*,'(g6.4)') 1234e9
> | end program format
I asked if you could show a G format that does print out that number
with the desired format.
Your failure to do that is duly noted.
> You are obviously being deliberately abstruse with that stupid
> example,
Sorry, but my irony meter just blew its fuse with that statement.
You are being so obtuse that your point cannot even been seen.
> which could never possibly work.
Just in case you are really confused about this (although I don't
know how) instead of just pretending to be confused, let me break it
down.
1) the maximum number of significant digits that can be printed for
that value in a six character field is 4. I specified that number
in the program in a six character field with 4 significant digits,
so it obviously can be done.
2) There is no G format that will write that value to a 6 character
field that displays those four significant digits.
3) Therefore, a G format does not accomplish the goal.
QED
$.02 -Ron Shepard
Harold Stevens
[Snip...]
> You are being so obtuse that your point cannot even been seen.
<DRUMROLL>
And the 2010 Wolfgang Pauli Not Even Wrong Award goes too ... robin.
</DRUMROLL>
--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at airmail, dotted with net. DO NOT SPAM IT.
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).
robin
| In article <4cb7ab21$0$55986$c30e...@exi-reader.telstra.net>,
| "robin" <rob...@dodo.com.au> wrote:
|
| > | > | This issue gets back to a recurring complaint I've had about formatting
| > | > | in fortran (which goes back even before f77). There are two fairly
| > | > | common things that need to be done with floating point numbers. One is
| > | > | to write the number to a fixed-width field in such a way that the
| > | > | maximum number of significant digits is output, and the other is to
| > | > | specify the number of significant digits that need to be output and have
| > | > | the minimum field width adjust as necessary. Neither of these tasks are
| > | > | straightforward to do with fortran format fields.
| > | >
| > | > The G-format directly permits the first of these.
| > |
| > | No, it can't possibly accomplish that because it is defined to use F
| > | and E formatting, which, as discussed above, does not accomplish the
| > | goal.
| >
| > Your stated goal is to write out the maximum number of digits,
| > which G does.
| Well, I thought I had explained this before, but ok, let's see if a
| G field works.
G-format works just fine. Here's a sample.
0.123456E-04
0.123456E-03
0.123456E-02
0.123456E-01
0.123456
1.23456
12.3456
123.456
1234.56
12345.6
123456.
0.123456E+07
0.123456E+08
0.123456E+09
0.123456E+10
0.123456E+11
0.123456E+12
0.123456E+13
0.123456E+14
0.123456E+15
0.123456E+16
Ron Shepard
"robin" <rob...@dodo.com.au> wrote:
> G-format works just fine. Here's a sample.
>
> 0.123456E-04
> 0.123456E-03
> 0.123456E-02
> 0.123456E-01
> 0.123456
> 1.23456
> 12.3456
> 123.456
> 1234.56
> 12345.6
> 123456.
> 0.123456E+07
> 0.123456E+08
> 0.123456E+09
> 0.123456E+10
> 0.123456E+11
> 0.123456E+12
> 0.123456E+13
> 0.123456E+14
> 0.123456E+15
> 0.123456E+16
It is clear that none of these display the value 1234e9 in a field
that is 6 characters wide and that shows four significant digits.
So none of these are "just fine". In fact, all of these have
different values, so I'm not sure exactly what it is that you think
you are demonstrating?
If I take one of these, say 0.123456E-04, then by my count that is 6
significant digits in a field width of 12. The first task I
described was to display the maximum number of digits in a given
field width. In a field width of 12, one can write 123456xxx-13.
If I've counted correctly, that is 9 significant digits that can be
printed. 9 is greater than 6, so your format does not satisfy the
criteria for the first task.
The other task I described was to specify the number of significant
digits to be printed, and the minimum output field width is
determined accordingly. If you specify 6 digits for that value, then
it can be printed as 123456-10, which is a field width of 9. 9 is
less than 12, so your format also does not satisfy the criteria for
the second task.
As an aside, that value could also be printed in a field width of 9
as 12345.6-9, 1234.56-8, and so on, including .123456-4. That is,
you can use a 1-digit exponent field rather than a 2-digit field,
but the decimal point becomes necessary. This is an example of how
particular values can be written in various ways. If this
capability were added to the fortran standard, some kind of
additional specifications should be included to select a specific
one of these possible output formats.
Your list of values all have leading zeros, unnecessary decimal
points, unnecessary "+" signs in the exponents, spaces within the
field, or unnecessary leading zeros in the exponent range. I don't
think a single one of your printed numbers satisfy the criteria of
either of the two tasks that were described.
$.02 -Ron Shepard
glen herrmannsfeldt
(snip)
> The other task I described was to specify the number of significant
> digits to be printed, and the minimum output field width is
> determined accordingly. If you specify 6 digits for that value, then
> it can be printed as 123456-10, which is a field width of 9. 9 is
> less than 12, so your format also does not satisfy the criteria for
> the second task.
One of the first things I learned about Fortran was that the d in
an Fw.d or Ew.d specifier indicates the digits after the decimal point.
This goes all the way back to Fortran I. When G was added (not in
Fortran I), a nice simple rule was used: the equivalent of
either Fw.d or Ew.d is used, depending on the value. Note that d
always specifies digits after the decimal point, and not the
number of significant digits to print.
> As an aside, that value could also be printed in a field width of 9
> as 12345.6-9, 1234.56-8, and so on, including .123456-4. That is,
> you can use a 1-digit exponent field rather than a 2-digit field,
> but the decimal point becomes necessary. This is an example of how
> particular values can be written in various ways. If this
> capability were added to the fortran standard, some kind of
> additional specifications should be included to select a specific
> one of these possible output formats.
How many letters are still available for new descriptors?
I wouldn't complain about some new ones for nicer formatting
of floating point values, specifying the significant digits.
> Your list of values all have leading zeros, unnecessary decimal
> points, unnecessary "+" signs in the exponents, spaces within the
> field, or unnecessary leading zeros in the exponent range. I don't
> think a single one of your printed numbers satisfy the criteria of
> either of the two tasks that were described.
Well, part of it is that the rules make nice printed columns,
with the decimals lining up (F format). It isn't so easy to
describe E, but I believe it still looks nice in a printed column.
Now that terminals and video displays are more common, lining up
the printed output isn't so important.
-- glen
-- glen
dpb
...
> The other task I described was to specify the number of significant
> digits to be printed, and the minimum output field width is
> determined accordingly. If you specify 6 digits for that value, then
> it can be printed as 123456-10, which is a field width of 9....
Years ago (like 40+ now), the nuclear design codes that were developed
at Bettis Laboratories had an input/output library associated with them
that used similar notation although it presumed a leading decimal point.
It was, however, very useful for such things particularly in getting
most precision on input when everything was still restricted to 80 col
card limit (which is prime reason for the development).
I've no idea whether one might be able to find the routines on the
internet by now or not. Of course, code of that vintage is now
considered pretty ugly as a general rule... :)
--
Richard Maine
> One of the first things I learned about Fortran was that the d in
> an Fw.d or Ew.d specifier indicates the digits after the decimal point.
> ... Note that d
> always specifies digits after the decimal point, and not the
> number of significant digits to print.
Sometimes the things we learn are wrong. Other times, they were right
when we learned them, but things change later.
For F format, the above description is correct.
For E format, one could have viewed the d either way... until the
introduction of P scaling. I would take "always" to mean what it says,
which would include cases with P scaling. For k (the scaling factor)
greater than 0, the number of digits left of the decimal point is k, and
the number of digits right of the decimal point is d-k+1. That is a
constant number of significant digits rather than a constant number of
digits after the decimal point. Unfortunately and oddly, the number of
significant digits is d+1 instead of d. This is the off-by-one error
that I mentioned in some previous posts. I just now looked it up to
check.
I suppose that if one looks only at the k=1 case (by far the most common
other than k=0), one could describe d as being the number of digits
after the decimal point. But looking at the formula given in the
standard (d-k+1), that cannot accurately be described as equalling d in
general.
For k=0, the number of significant digits is d, as is the number of
digits to the right of the decimal point.
For k<0, the formula does show a constant number of digits after the
decimal point, but that's the rarest case. I've never actually seen
negative k values used in real code. Yes, I could probably imagine cases
where it might make sense, but I've never seen it done.
robin
| robin wrote:
| ...
|
| > Yes there is, and that's to use a language, such as PL/I,
| > that supports the feature.
| So, every time one finds some peculiar little subfeature
Both Sheperd and Watters made a big issue of it.
| a particular
| language supports, that's reason to convert a full codebase? Not...
But I might add that PL/I offers many more features that
Fortran doesn't, besides better formatting.
With all the extra features, one may want to make the switch.
robin
| In article <4cbecfbd$0$78208$c30e...@exi-reader.telstra.net>,
| "robin" <rob...@dodo.com.au> wrote:
|
| [...]
| > As I said, your stated goal is to write out the maximum number of digits"
| > You wrote:--"One is to write the number to a fixed-width field in such a way
| > that the
| > " maximum number of significant digits is output"
| >
| > G-format obviously does that.
|
| No, it obviously does not, and I gave an example.
No, you gave an example of something completely different.
You wanted the maximum number of digits. G-format delivers that.
robin
| Richard Maine <nos...@see.signature> wrote:
| (snip)
|
| > It also wasn't the "sticky" nature of 1P and its strange behavior with
| > F. I've seen that one before. A close co-worker was tearing his hair
| > out (and to look at him now, it appears to have worked :-)) trying to
| > figure out why a program of his was giving results off by a factor of
| > 10. Turns out the results were fine - just printed "oddly".
|
| > Instead, it was a quirk specific to 1P and G. If I recall correctly,
| > G10.4 (without the 1P) means 4 significant digits, regardless of whether
| > it prints in an E or F format. But 1PG10.4 means 3 significant digits
| > when it uses F, but 4 significant digits when it uses E. (Or maybe I
| > have that backwards). You'd have to go to G10.5 to get 4 significant
| > digits with F, but then it is too wide for the field (giving *'s) with
| > E. Something like that. It made no sense at all. I swear the only
| > explanation was that someone got the arithmetic off by 1 when writing
| > the formulae in the standard.
|
| Well, G10.4 gives the results of either E10.4 or F10.4,
No it doesn't. For fixed-point format, it uses F10.0, F10.1, F10.2, etc,
depending on the value being printed.
| which
| seems obvious enough to me. 1PG10.4 gives either 1PE10.4 or F10.4
| (without the 1P for the reason given above). (Or I10 or L10 or A10.)
|
| The d in Fw.d, Ew.d, or Gw.d gives the number of digits after
| the decimal point.
In the case of Gw.d, d gives the number of digits after the decimal
point only when it uses float format.
When it reverts to fixed-point form, the position of the decimal point
depends on the value, and the "d" means nothing except that
it is the number of digits printed.
robin
|
| One of the first things I learned about Fortran was that the d in
| an Fw.d or Ew.d specifier indicates the digits after the decimal point.
| This goes all the way back to Fortran I. When G was added (not in
| Fortran I), a nice simple rule was used: the equivalent of
| either Fw.d or Ew.d is used, depending on the value. Note that d
| always specifies digits after the decimal point, and not the
| number of significant digits to print.
That's not correct for G.
When fixed-point output is used, the "d" does not specify the
number of digits after the decimal point.
It specifies the total number of digits.
robin
Of course not. They display the maximum number of digits, which
is what you asked for.
The max. number of digits is typically 6 and 15 for
single and double precision, resp.
Your number 1234e9 would display as 6 digits plus exponent,
so it's scarcely likelt to fit in a field of 6 positions, now, is it?
Colin Watters
news:4cc0fce4$0$78207$c30e...@exi-reader.telstra.net...
"1234e6" evidently occupies a field of 6 positions. Count 'em.
We're not looking for 6 significant figures. We want the maximum
significance that will fit in a fixed number of characters, 6 in this
example.
dpb
Does the feature to convert a large codebase come free w/ the compiler
(and how many PL/I compilers are there these days, anyway?)
--
robin
This is another example where it wan't necessary (even back then)
to write anything special to do that in PL/I, because
those facilities were already available in PL/I.
These facilities included overpunched signs (saves one column),
implied decimal point (saves another column),
and minimise the number of exponent digits
(again, saving another column for overpunched sign of exponent).
dpb
...
> This is another example where it wan't necessary (even back then)
> to write anything special to do that in PL/I, ...
Anything more special than writing a PL/I compiler for the Philco 2000,
anyway...
If there was one for the CDC, I certainly never saw it...
--
Ron Shepard
dpb <no...@non.net> wrote:
No, I am not interested in switching from fortran to PL/I. I am
interested in adding this feature (or these two features, if you
count them that way) to fortran. The current F, E, and G format
fields do not satisfy the requirements (robin's claims
notwithstanding), so something new would need to be added.
My preference would be for a new format field specifier. If there
aren't any 1-letter field symbols that could be used, then there is
nothing wrong with a 2-letter field. Maybe "GS" when the number of
significant digits is specified, or GW when the field width is
specified. Or, maybe a "0" could be used in one of the existing
field widths in a clear and nonambiguous way, as it is now done for
I and F fields where the actual width is determined automatically.
In any case, I'm not so concerned about the final syntax, it is more
the functionality that is important.
The other option of adding picture fields (as in some other
languages) might also work. It is sort of a round about way of
accomplishing the two tasks that I described, but with relatively
little effort, compared to the current situation, it could be used
to solve the problem when combined with the use of internal writes
and character strings.
$.02 -Ron Shepard
glen herrmannsfeldt
(snip)
> Does the feature to convert a large codebase come free w/ the compiler
> (and how many PL/I compilers are there these days, anyway?)
It did in the beginning. Rumors are that IBM planned not to
write a Fortran compiler for S/360, and instead supply the
conversion program to convert everyone over to PL/I.
As you know, that didn't happen.
The early compilers were slow, especially on smaller machines.
PL/I (F) is designed to run in 44K of core (a 64K machine, with
20K for OS/360 PCP). The generated code is completely reentrant,
with a fair amount of overhead, again especially on smaller S/360s.
At the request of the users, they contracted out for Fortran G.
(Though the G indicates that it is designed for 128K, and likely
won't run on the smaller machines.)
I never tried the conversion program, and don't know at all
what the converted code looked like. There is one difference
in formatted I/O that would complicate the conversion, and
that is that it stops at the last list item, not processing
following format descriptors that don't need a list item.
Since it is always non-advancing (until a new record is
specifically requested), it isn't hard to put multiple I/O
statements together. Automated conversion of FORMAT doesn't
seem easy, though.
EQUIVALENCE will be hard, but many uses of it aren't standard
conforming. There are no assumed size arrays, either, so
programs that pass parts of arrays, or arrays of a different
rank, will be hard to convert.
Other than those, automated conversion of Fortran 66 to PL/I
shouldn't be so hard to do.
-- glen
glen herrmannsfeldt
(snip)
> No, I am not interested in switching from fortran to PL/I. I am
> interested in adding this feature (or these two features, if you
> count them that way) to fortran. The current F, E, and G format
> fields do not satisfy the requirements (robin's claims
> notwithstanding), so something new would need to be added.
(snip)
> The other option of adding picture fields (as in some other
> languages) might also work. It is sort of a round about way of
> accomplishing the two tasks that I described, but with relatively
> little effort, compared to the current situation, it could be used
> to solve the problem when combined with the use of internal writes
> and character strings.
PL/I has PICTURE variables, I believe adopted from COBOL. I believe
in that case, the data is stored as described, usually in decimal form.
In addition, as Robin mentioned, there is the P (picture) format
descriptor. I believe the form is similar to the declaration of
PICTURE variables, but it works with other types of variables,
including floating point. For most format descriptors, you can
use variables, such as for the w and d for E and F. P is different,
though, and it might be that you can't use variables. You can
specify the digits for the exponent more precisely than in Fortran.
P format also allows for a CR or DB on negative values (like bank
statements). Originally there was also P format for British
Pound/Shilling/Pence, but I believe that has been removed.
-- glen
dpb
> dpb <no...@non.net> wrote:
> (snip)
>
>> Does the feature to convert a large codebase come free w/ the compiler
>> (and how many PL/I compilers are there these days, anyway?)
>
> It did in the beginning. Rumors are that IBM planned not to
> write a Fortran compiler for S/360, and instead supply the
> conversion program to convert everyone over to PL/I.
>
> As you know, that didn't happen.
>
> Other than those, automated conversion of Fortran 66 to PL/I
> shouldn't be so hard to do.
:)
Yes, but the question was more rhetorical and in the view of a current
application of some 100sK or maybe even into the 1M LOC range.
I worked on pieces of the nuclear codes and don't really have a
realistic line count. I do know the code listing for the parts on which
I did work was three stacks of greenbar each desktop high. I don't have
an estimate for how many pages it took to equal a foot but knowing that
one could at least make an approximate guess. That part included the
neutron diffusion and thermal feedback sections but excluded all the
isotope depletion portions which was (guessing) at least approaching the
same size on its own.
And, of course, the subsections written in Philco assembly wouldn't be
at all amenable to automated translation. All in all, I think Robin's
suggestion wouldn't have flown simply for the wish to have picture
formatting to replace the Bettis library routines... :)
When translated to CDC Cyber FTN/COMPASS, not sure where that left PL/I,
either...
:)
--
dpb
...
> No, I am not interested in switching from fortran to PL/I. I am
> interested in adding this feature (or these two features, if you
> count them that way) to fortran. The current F, E, and G format
> fields do not satisfy the requirements (robin's claims
> notwithstanding), so something new would need to be added.
...
Indeed, that's a patently absurd suggestion for anything other than a
toy app even if there were a veritable plethora of PL/I compilers (and a
quick google didn't find much other than IBM and while a top-level link
claims one for various systems including Winders, I could find no hint
of where such an animal might be in links under that reference)...
Would seem the current choice is to write a routine that does process
values and produce output as desired. Certainly not as handy as a
native feature, granted.
I did a search at the RSICC site to see if could, by any chance, find
one of the old Bettis codes that might happen to have the facilities.
Unfortunately, didn't have any success in a quick look--the various
reactor vendors took the AEC/USN versions available from Bettis and
modified them extensively for their own purposes and these proprietary
versions were never disseminated. In the years since, w/ the advent of
the PC, newer codes have evolved such that there isn't any demand for
the old ones. I never thought to save the source files at the time we
did the last translation I did; at that time seemed so obvious it would
always be around whenever one might happen to want it. 30+ years and
multiple career shifts later and what one once't upon a time did seems
far, far away...
--
dpb
...
> But I might add that PL/I offers many more features that
> Fortran doesn't, besides better formatting.
>
> With all the extra features, one may want to make the switch.
...
Actually, I wonce't upon a time thought mayhaps that might be the case
and obtained the IBM VisualAge PL/I compiler for OS/2. In particularly,
I was enamored w/ the promise of array operations but discovered they
were so severely limited in their abilities that never did anything with
it. Then F90/95 arrived and the rest is, as they say, history...
At least for my purposes I don't see any features PL/I has that Fortran
doesn't have that make up for features Fortran has that PL/I doesn't
have (including a dearth of compilers). In that regard I guess I'm
Terence humming a different tune... :)
--
glen herrmannsfeldt
(snip)
(Note that all posts in which I describe other compiled languages
are for comparison purposes only. Understanding features of
other languages may help in adding (or not adding) such features
to Fortran.)
> Actually, I wonce't upon a time thought mayhaps that might be the case
> and obtained the IBM VisualAge PL/I compiler for OS/2.
Some years ago I joined the OS/2 Developers Connection, which allowed
for trial versions of some software, and complicated rules on what
you could do later. Two that I was most interested in were PL/I
and TCP/IP. (About the time of Windows 3.0.) I never did much with
the PL/I compiler, but networking was much better than DOS/Windows.
> In particularly,
> I was enamored w/ the promise of array operations but discovered they
> were so severely limited in their abilities that never did anything with
> it. Then F90/95 arrived and the rest is, as they say, history...
PL/I has always had array operations. Array cross sections only
allow * for all values of that subscript. More complicated
subscripting is done through the DEFINED attribute, which has some
similarity to EQUIVALENCE (which PL/I doesn't have). With DEFINED,
the new array elements map onto an existing array in whatever way
you need, not just in memory order (as EQUIVALENCE). One disadvantage
is that you can't use a DEFINED array as a subprogram argument,
even if it could be described by the appropriate array descriptor.
(PL/I only has assumed shape which, as I have noted previously
includes both lower bound and upper bound.)
> At least for my purposes I don't see any features PL/I has that Fortran
> doesn't have that make up for features Fortran has that PL/I doesn't
> have (including a dearth of compilers). In that regard I guess I'm
> Terence humming a different tune... :)
It does seem that many useful PL/I features have now been added
to Fortran. Some have even been added and removed! (Floating
point in DO loops, for one.)
Neither Fortran nor C89 have structure expressions. It doesn't
seem that much of a generalization over array expressions.
(I don't know about C99.)
-- glen
robin
Four PL/I compilers were available for CDC equipment.
One from Courant Institite, two optimising compilers from a university,
and one from CDC.
robin
| dpb <no...@non.net> wrote:
|
| (Note that all posts in which I describe other compiled languages
| are for comparison purposes only. Understanding features of
| other languages may help in adding (or not adding) such features
| to Fortran.)
|
| > Actually, I wonce't upon a time thought mayhaps that might be the case
| > and obtained the IBM VisualAge PL/I compiler for OS/2.
|
| Some years ago I joined the OS/2 Developers Connection, which allowed
| for trial versions of some software, and complicated rules on what
| you could do later. Two that I was most interested in were PL/I
| and TCP/IP. (About the time of Windows 3.0.) I never did much with
| the PL/I compiler, but networking was much better than DOS/Windows.
|
| > In particularly,
| > I was enamored w/ the promise of array operations but discovered they
| > were so severely limited in their abilities that never did anything with
| > it.
PL/I for OS/2 had array operations including DEFINED [aka EQUIVALENCE].
Initially, it didn't have iSUB [see below for more info];
however, that facility was subsequently added to the Windows verion
[and might have been added to the OS/2 version but I'm not sure OTOMH].
| Then F90/95 arrived and the rest is, as they say, history...
|
| PL/I has always had array operations.
Indeed.
| Array cross sections only
| allow * for all values of that subscript. More complicated
| subscripting is done through the DEFINED attribute, which has some
| similarity to EQUIVALENCE (which PL/I doesn't have).
PL/I has EQUIVALENCE through the DEFINED facility.
| With DEFINED,
| the new array elements map onto an existing array in whatever way
| you need, not just in memory order (as EQUIVALENCE). One disadvantage
| is that you can't use a DEFINED array as a subprogram argument,
| even if it could be described by the appropriate array descriptor.
| (PL/I only has assumed shape which, as I have noted previously
| includes both lower bound and upper bound.)
PL/I also has iSUB, which permits many more array overlaying operations,
such as handling symmetric matrices stored in triangular form ;
boundary-value problems where all elements in the array participate
except those at the edges ; representing unit matrices as a vector of
the diagonal elements only ; etc etc.
robin
| dpb <no...@non.net> wrote:
| (snip)
|
| > Does the feature to convert a large codebase come free w/ the compiler
| > (and how many PL/I compilers are there these days, anyway?)
|
| It did in the beginning. Rumors are that IBM planned not to
| write a Fortran compiler for S/360,
IBM wanted a language that would embrace the best features of
FORTRAN, COBOL, and ALGOL, and then some,
so that one language could be used for most applications.
As for IBM not planning on producing a FORTRAN compiler,
I think that that is fanciful, because IBM produced
at least 3 FORTRAN compilers that were ready at the time of
the release of the S/360. These were the E, F, and H compilers.
As well, they also produced a COBOL compiler (perhaps more than one).
| and instead supply the
| conversion program to convert everyone over to PL/I.
It was provided for any customer who wanted to use it.
IBM did not force anyone to change languages.
In point of fact, they couldn't force anyone to do anything.
| As you know, that didn't happen.
|
| The early compilers were slow, especially on smaller machines.
The PL/I-F compiler was about the same speed as FORTRAN (F)
in compilation.
PL/I-F was faster than FORTRAN (H).
Where significant slowness occurred was in the linker,
which was poorly written.
robin
Let me acquait you with the OP's spec:
"to write the number to a fixed-width field in such a way that the
maximum number of significant digits is output,"
The G-format satisfies it.
1234e6 is irrelevant.
nm...@cam.ac.uk
robin <rob...@dodo.com.au> wrote:
>"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message news:i9sjmn$dul$1...@news.eternal-september.org...
>| dpb <no...@non.net> wrote:
>| (snip)
>|
>| > Does the feature to convert a large codebase come free w/ the compiler
>| > (and how many PL/I compilers are there these days, anyway?)
>|
>| It did in the beginning. Rumors are that IBM planned not to
>| write a Fortran compiler for S/360,
>
>IBM wanted a language that would embrace the best features of
>FORTRAN, COBOL, and ALGOL, and then some,
>so that one language could be used for most applications.
>
>As for IBM not planning on producing a FORTRAN compiler,
>I think that that is fanciful, because IBM produced
>at least 3 FORTRAN compilers that were ready at the time of
>the release of the S/360. These were the E, F, and H compilers.
Glen is correct, and IBM took that decision several times over
the life of the series, backing off (almost) every time. Initially,
the E, F, and H compilers were intended purely for legacy code,
and not to be upgraded, but they were pressured into producing
G1 and H Extended (and later H Extended Enhanced). Initially,
there was a decision NOT to produce a Fortran 77 compiler, but
they first had to write a joke compiler (VS Fortran) to meet the
requirements of a particular contract (it's hush-hush, so don't
ask), and then it proved so popular that they had to turn it into
a real one (which was harder than starting from scratch).
I lost track of that series after about 1994, so can't say what
happened thereafter. I know some of the (mainly political)
developments, though.
Regards,
Nick Maclaren.
Peter Flass
> In article <4cc2c800$0$78212$c30e...@exi-reader.telstra.net>,
> robin <rob...@dodo.com.au> wrote:
>> As for IBM not planning on producing a FORTRAN compiler,
>> I think that that is fanciful, because IBM produced
>> at least 3 FORTRAN compilers that were ready at the time of
>> the release of the S/360. These were the E, F, and H compilers.
From my recollection, "H" came along significantly later, around the
1966-67 timeframe.
dpb
...
>> In particularly,
>> I was enamored w/ the promise of array operations but discovered they
>> were so severely limited in their abilities that never did anything with
>> it. Then F90/95 arrived and the rest is, as they say, history...
>
> PL/I has always had array operations. Array cross sections only
> allow * for all values of that subscript. More complicated
> subscripting is done through the DEFINED attribute, which has some
> similarity to EQUIVALENCE (which PL/I doesn't have). With DEFINED,
> the new array elements map onto an existing array in whatever way
> you need, not just in memory order (as EQUIVALENCE). One disadvantage
> is that you can't use a DEFINED array as a subprogram argument,
> even if it could be described by the appropriate array descriptor.
> (PL/I only has assumed shape which, as I have noted previously
> includes both lower bound and upper bound.)
...
The "severely limited" was poorly chosen as the personal reference point
is unobservable by others--at the time I was looking at mostly matrix
operations and hoping PL/I syntax would allow something more like a
compilable Matlab. (In some ways I was hoping for something much like
our recent visitor w/ his wishes for syntax changes... :) )
--
dpb
Perhaps, but I never saw one...and as noted before given the code base
size the chances of anybody even thinking of trying to convert would
have been nil...
And, even if did there would have then been the question of
recertification to the NRC which would have taken years of effort to
reproduce all the design basis computations that were the filings before
the Advisory Committee on Reactor Safety (ACRS) of acceptance of the
codes for licensing.
Just not a feasible tack back then and can't think it would be any more
feasible for anybody now...
--
dpb
...
> "to write the number to a fixed-width field in such a way that the
> maximum number of significant digits is output,"
>
> The G-format satisfies it.
...
No, each of those previously displayed values could have at least one
more digit in the field width (assuming an implied decimal as well,
otherwise the F format fields are nearly optimal).
If there's a leading 0 or an unneeded 0 in an exponent, the E in an
exponent, then there's room in that field width for an additional digit
so it the maximum number in the field width have _not_ been output by
OPs criterion.
You have modified the requirement to a different one than OP.
--
Colin Watters
It only satisfies it if the width of the field is big enough. In your
example above the field width is 13 (the leading "+" is omitted). Now try
it with a field width of 6.
...or do you consider that a "fixed width field" must be at least 13
characters wide, and so a 6-character one is irrelevant?
robin
| Indeed, that's a patently absurd suggestion for anything other than a
| toy app even if there were a veritable plethora of PL/I compilers (and a
| quick google didn't find much other than IBM and while a top-level link
| claims one for various systems including Winders, I could find no hint
| of where such an animal might be in links under that reference)...
You'll find that PL/I is available on :--
Windows, from IBM
AS400, from IBM
z/os from, IBM (several compilers)
RS/6000, from IBM
Windows XP and Vista, from Micro Focus
Redhat Linux, from Micro Focus
Data General Aviion, from Micro Focus
HP-UX, from Micro Focus
Sun Sparc Solaris 2.x, from Micro Focus
Intel SuSE Linux, from Micro Focus
Compaq Open VMS, from Kednos
Alpha AXP (Tru64 Unix), from Kednos
Stratus
Wang/Gentronics
Fujitsu-Siemens BS2000
Ron Shepard
"robin" <rob...@dodo.com.au> wrote:
Either you are again being obtuse, or you did not read my previous post
which explained how the first value could be written with 9 digits in
that field width of 13. Your G format only prints 6 digits. Since 6 is
less than 9, 6 is not the maximum number of digits that can be printed
in that field width.
> 1234e6 is irrelevant.
That was an example I gave demonstrating how the G format fails to meet
the requirements. To disprove your conjecture (that a G format
satisfies the requirements), only one counterexample needs to be given.
That is one example. The entire list above are all examples of the
failure of the G format to satisfy the requirement.
How could you keep stating that the G format satisfies the original
requirement when it clearly does not? I know that my previous post which
explained all this was in the thread history of your current post
because part of it is quoted above. But for some reason you seem to
have not read it, or if you read it, you did not understand it, or if
you understood it, you decided to be obtuse and pretend that you did not
understand it. I wonder which of those situations has occurred?
$.02 -Ron Shepard
dpb
> "dpb" <no...@non.net> wrote in message news:i9snhd$tcl$1...@news.eternal-september.org...
>
> | Indeed, that's a patently absurd suggestion for anything other than a
> | toy app even if there were a veritable plethora of PL/I compilers (and a
> | quick google didn't find much other than IBM and while a top-level link
> | claims one for various systems including Winders, I could find no hint
> | of where such an animal might be in links under that reference)...
>
> You'll find that PL/I is available on :--
>
> Windows, from IBM
As said, I saw a heading that said so but no indications of how one
would obtain such beastie (presuming one were inclined)...
--
John Smith
> In <ron-shepard-345B...@news60.forteinc.com> Ron Shepard:
>
> [Snip...]
>
>> You are being so obtuse that your point cannot even been seen.
>
> <DRUMROLL>
> And the 2010 Wolfgang Pauli Not Even Wrong Award goes too ... robin.
> </DRUMROLL>
>
The auto-jeer section is set on: Harold. You're not a careful enough
thinker to invoke Pauli.
--
John Smith
robin
| I never tried the conversion program*, and don't know at all
| what the converted code looked like. There is one difference
| in formatted I/O that would complicate the conversion, and
| that is that it stops at the last list item, not processing
| following format descriptors that don't need a list item.
|
| Since it** is always non-advancing (until a new record is
| specifically requested), it isn't hard to put multiple I/O
| statements together. Automated conversion of FORMAT doesn't
| seem easy, though.
|
| EQUIVALENCE will be hard, but many uses of it aren't standard
| conforming. There are no assumed size arrays, either, so
| programs that pass parts of arrays, or arrays of a different
| rank, will be hard to convert.
|
| Other than those, automated conversion of Fortran 66 to PL/I
| shouldn't be so hard to do.
There are/were at least 5 converters to my knowledge,
including one I used for converting (perhaps) 50 programs.
While Glenn mentions one difficulty with I/O,
a more pressing one is the fact that FORTRAN
output formats may include character string constants.
I agree with Glenn about passing parts of arrays,
however, it isn't anything common, and the few cases that I have
encountered are trivially converted by hand.
Changing rank, now an obsolete practice, is likewise
dealt with by manual means. However, changes in rank
may be dealt with by iSUB.
Another thing that has to be watched is integer division.
While most of these can be handled by a mechanical translator
(by appropriate declarations), there could be an odd one
involving operands in which one or both operands is a constant.
Of course, let's not forget that PL/I can readily call FORTRAN
procedures.
_____________
* IBM's FORTRAN to PL/I converter
** PL/I's I/O. Actually, it isn't always "non-advancing" --
a new line is automatically commenced when a print line fills.
robin
news:4cc4c9f3$4$fuzhry+tra$mr2...@news.patriot.net...
| In <4cc2144a$0$78206$c30e...@exi-reader.telstra.net>, on 10/23/2010
| at 09:46 AM, "robin" <rob...@dodo.com.au> said:
|
| >Four PL/I compilers were available for CDC equipment.
|
| 6600 and its descendants; IAC, I know that there were PL/I compilers
| on that line.
CDC 6000, 70, 170, 7600.
I don't know whether there was one for the later equipment
under NOS/VE.
Terence
wrote:
(snipped)
Just catching up on this thread.
I met this problem of getting sugnificant digits into a particular
available width, mentioned by Richard, Ron, Robin, and John, when I
was writing routines a general-purpose output-writing program.
I found that I needed only two routines: one of fixed (obvious) and
one for floating point. In the latter, the trick was to write
formatted with parameter-selected E or F formats to a long work area,
then, eliminating trailing blanks and optional leading zero, pick up a
string length of the size required up to the maximum number of after-
point trailing decimal digits. ( I also had options for floating
symbol, zero, blank and utterly small results and for dot or comma
digit seperator and triple digit counting (e.g. $1,123,456.78 ). But
you get the idea: you can almost always write a routine to solve the
problem of what the particular language does not include in its
formatting syntax. I think I published those routines here, way back
when.
Colin Watters
news:cba58c4c-1d00-4d67...@x42g2000yqx.googlegroups.com...
Theres no doubt it can be done, see my posting of 4 years ago, referred to
upthread:
http://groups.google.com/group/comp.lang.fortran/msg/e54cc49eed61b1bd?&q=rcompact
Problem is however its very CPU intensive, verbose, and altogether
unsatisfying. In addition the code makes extensive use of Fortran internal
file I/O, hence the function itself cannot be referenced on a write
statement, as would be natural for any normal Formatted write (F2003
aside). That's why I (we) want the language to do it "native". Failing
that, could someone come up with a better implimentation than the code I
have shown.
Terence
> "Terence" <tbwri...@cantv.net> wrote in message
>
> news:cba58c4c-1d00-4d67...@x42g2000yqx.googlegroups.com...
>
>
>
>
>
> > On Oct 15, 2:11 am, Ron Shepard <ron-shep...@NOSPAM.comcast.net>
> > wrote:
> > (snipped)
>
> > Just catching up on this thread.
> > I met this problem of getting sugnificant digits into a particular
> > available width, mentioned by Richard, Ron, Robin, and John, when I
> > was writing routines a general-purpose output-writing program.
>
> > I found that I needed only two routines: one of fixed (obvious) and
> > one for floating point. In the latter, the trick was to write
> > formatted with parameter-selected E or F formats to a long work area,
> > then, eliminating trailing blanks and optional leading zero, pick up a
> > string length of the size required up to the maximum number of after-
> > point trailing decimal digits. ( I also had options for floating
> > symbol, zero, blank and utterly small results and for dot or comma
> > digit seperator and triple digit counting (e.g. $1,123,456.78 ). But
> > you get the idea: you can almost always write a routine to solve the
> > problem of what the particular language does not include in its
> > formatting syntax. I think I published those routines here, way back
> > when
>
> Theres no doubt it can be done, see my posting of 4 years ago, referred to
> upthread:
>
>
> Problem is however its very CPU intensive, verbose, and altogether
> unsatisfying. In addition the code makes extensive use of Fortran internal
> file I/O, hence the function itself cannot be referenced on a write
> statement, as would be natural for any normal Formatted write (F2003
> aside). That's why I (we) want the language to do it "native". Failing
> that, could someone come up with a better implimentation than the code I
> have shown.
>
> --
> Qolin
>
> Email: my qname at domain dot com
> Domain: qomputing
As a quick reply, a less verbose programmed solution is to calculate
and generate the exact format needed to achieve the desired result by
writing the format itself to a character string and them using the
remote format option to execute the write statment the way you want it
by referring to this generated format.
You don't have to have matrices of text lines to pick form: you write
just the one needed.
The solution is then only a few lines of code which use the passed
parmaters defining the maximum width and minimum decimal positions.
This cuts down the coding and CPU time enormously.
Colin Watters
Hah! I wish it were that easy! How, exactly, would you suggest the "exact
format necessarry" is calculated? I didn't come to this verbose solution
easily or quickly, it took a lot of fiddling around, and my first attempts
were along the lines you suggest. But the quirks of rounding and
leading/trailing zero requirements led to bugs, so I eventually settled for
the brute-force approach I posted.
I would be VERY interested if you could do any better.
Note, the spec has NO minimum decimal positions: the only requirement is
the number of character positions available, and typically this is about 6,
and 8 as an general maximum. Within this field the value must have the
maximum possible number of significant digits.
Terence
> > "Terence" <tbwri...@cantv.net> wrote
>
> > and generate the exact format needed to achieve the desired result by
> > writing the format itself to a character string and them using the
> > remote format option to execute the write statment the way you want it
> > by referring to this generated format.
>
> > You don't have to have matrices of text lines to pick form: you write
> > just the one needed.
>
> > The solution is then only a few lines of code which use the passed
> > parmaters defining the maximum width and minimum decimal positions.
>
> > This cuts down the coding and CPU time enormously.
>
> Hah! I wish it were that easy! How, exactly, would you suggest the "exact
> format necessarry" is calculated? I didn't come to this verbose solution
> easily or quickly, it took a lot of fiddling around, and my first attempts
> were along the lines you suggest. But the quirks of rounding and
> leading/trailing zero requirements led to bugs, so I eventually settled for
> the brute-force approach I posted.
>
> I would be VERY interested if you could do any better.
>
> Note, the spec has NO minimum decimal positions: the only requirement is
> the number of character positions available, and typically this is about 6,
> and 8 as an general maximum. Within this field the value must have the
> maximum possible number of significant digits.
>
If I'm clear about the target I can give it a try.
I will assume John and Robin defined the intention in the first two
posts.
I think John offered a solution method I agree with.
Object: to write any valid floating point number into a field of W
characters, with the maximum number of significant digits possible
within W characters (W>=6), rounded up and allowing the plus sign of
mantissa and any exponents to be omitted, but not any negative signs,
I would have liked to haved added, "up to a maximum number of
significant digits S", because in most cases, a computation result has
a known expected accuracy of precision.
Examples of expected results of a routine (using an extended G-table
of Robin):-
width= six seven eight nine
ten ....
0.123456789E-04 123e-7 1235e-8 12346e-9 12346e-10
123457e-11
0.123456789E-03 123e-6 1235e-7 12346e-8 123457e-9
123457e-10
0.123456789E-02 123e-5 1235e-6 12346e-7 123457e-8
1234568e-9
0.123456789E-01 123e-4 1235e-5 12346e-6 123457e-7
1234568e-8
0.123456789 .12346 .123457 .1234568 .12345679 .
123456789
etc
This suggests John's approach: write value to an internal to find the
exponent and sign of mantissa (also tells which signs can be omitted),
calculate working width based on W and the extra information (e.g.
whether an exponent is needed), which could reduce the effective W and
then rewrite the value with the modified working width to incur
appropriate rounding, and finally apply positive sign elimination
before passing the result string back.
Terence
I should have addedd the premise, that you generate at most one of the
two internal formats needed, because of the choice of with or without
exponent, and of possible signs. I don't see the gain in suppressing
the "E" exponent, since either a sign or an E (or equivalent) is
needed for the two possible exponent separators "e" and "-".
Richard Maine
[most elided]
> > width= six seven eight nine
> > ten ....
> > 0.123456789E-04 123e-7 1235e-8 12346e-9 12346e-10
...
> I should have addedd the premise, that you generate at most one of the
> two internal formats needed, because of the choice of with or without
> exponent, and of possible signs. I don't see the gain in suppressing
> the "E" exponent, since either a sign or an E (or equivalent) is
> needed for the two possible exponent separators "e" and "-".
But the above table uses both the "e" and the "-". The first example in
the table could have an extra significant digit with 1235-7 instead of
123e-7. Thus it would seem to not meet the requirements.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Colin Watters
news:1jqzisq.1xwrel41d4pwnoN%nos...@see.signature...
> Terence <tbwr...@cantv.net> wrote:
> [most elided]
>
>> > width= six seven eight nine
>> > ten ....
>> > 0.123456789E-04 123e-7 1235e-8 12346e-9 12346e-10
> ...
>> I should have addedd the premise, that you generate at most one of the
>> two internal formats needed, because of the choice of with or without
>> exponent, and of possible signs. I don't see the gain in suppressing
>> the "E" exponent, since either a sign or an E (or equivalent) is
>> needed for the two possible exponent separators "e" and "-".
>
> But the above table uses both the "e" and the "-". The first example in
> the table could have an extra significant digit with 1235-7 instead of
> 123e-7. Thus it would seem to not meet the requirements.
>
>
Interesting: my first incarnation formatted numbers thus, and it caused the
plotting post processor to barf. This was written in C, and the programmer
concerned had to make a special reader routine to process them. Is it legal
in C these days to omit the "e" in this way?
Another problem I had was people complaining when they eyeballed the
results. So eventually I relented and put it back in (my code has a section
to do just this).
Colin Watters
...Aah, but this is one of the quirks: is there sufficient room for the
value without the exponent, or not? eg. 0.001234491 in 7 characters: this
could be written as ".001234" or "1234e-6", so it doesn't matter. But
0.01234491 would be ".012345" or "1234e-5", so it does. What is the
algorithm that makes these decisions correctly and cleanly?
Another point is the rounding. If the number is rendered to characters and
then excess digits truncated, the number is likley to be rounded down. So
you need to be a bit more clever, and it gets complicated and long-winded.
robin
| In <4cc596b2$1$496$c30e...@exi-reader.telstra.net>, on 10/26/2010
| at 01:37 AM, "robin" <rob...@dodo.com.au> said:
|
| > I agree with Glenn about passing parts of arrays,
|
Glenn was referring to arrays passed as a subscripted element,
e.g., call sub(x(5))
where the caller intends that elements x(5) thru x(ubound(x)) are sent.
Some simple cases could be translated automatically,
others might need hand translation via DEFINED or iSUB.
glen herrmannsfeldt
> "Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
> news:4cc6c0e3$3$fuzhry+tra$mr2...@news.patriot.net...
> | In <4cc596b2$1$496$c30e...@exi-reader.telstra.net>, on 10/26/2010
> | at 01:37 AM, "robin" <rob...@dodo.com.au> said:
> | > I agree with Glenn about passing parts of arrays,
> | Isn't that only an issue for CONNECTED?
> Glenn was referring to arrays passed as a subscripted element,
> e.g., call sub(x(5))
> where the caller intends that elements x(5) thru x(ubound(x)) are sent.
Or any of the other tricks that you can do with assumed size arrays.
> Some simple cases could be translated automatically,
> others might need hand translation via DEFINED or iSUB.
But you can't, last I knew, pass DEFINED with iSUB arrays to
a called procedure.
-- glen
Richard Maine
> "Richard Maine" <nos...@see.signature> wrote in message
> news:1jqzisq.1xwrel41d4pwnoN%nos...@see.signature...
> > The first example in
> > the table could have an extra significant digit with 1235-7 instead of
> > 123e-7. Thus it would seem to not meet the requirements.
> >
> Interesting: my first incarnation formatted numbers thus, and it caused the
> plotting post processor to barf. This was written in C, and the programmer
> concerned had to make a special reader routine to process them. Is it legal
> in C these days to omit the "e" in this way?
I don't believe so. It is in Fortran, but I think not in C. Guess I
didn't read the requirements carefully enough. That and/or, this being
just a usenet thread instead of a formal system development process,
they probably weren't stated quite that precisely (which is fine for the
context).
robin
Of course such an array can be passed!
Ron Shepard
nos...@see.signature (Richard Maine) wrote:
> Colin Watters <bo...@qomputing.com> wrote:
>
> > "Richard Maine" <nos...@see.signature> wrote in message
> > news:1jqzisq.1xwrel41d4pwnoN%nos...@see.signature...
>
> > > The first example in
> > > the table could have an extra significant digit with 1235-7 instead of
> > > 123e-7. Thus it would seem to not meet the requirements.
> > >
> > Interesting: my first incarnation formatted numbers thus, and it caused the
> > plotting post processor to barf. This was written in C, and the programmer
> > concerned had to make a special reader routine to process them. Is it legal
> > in C these days to omit the "e" in this way?
>
> I don't believe so. It is in Fortran, but I think not in C. Guess I
> didn't read the requirements carefully enough. That and/or, this being
> just a usenet thread instead of a formal system development process,
> they probably weren't stated quite that precisely (which is fine for the
> context).
I don't think perl, excel, and many of the other standard utility
programs work without the "e" either. For this reason, I would
prefer to have these minimum-width formats have the option to
include it or not. If it is only going to be processed by fortran,
then one might want to drop the "e" when it costs a digit or an
extra character, but if it is to be used by some other utility or
programming language that does not support that format easily, then
one might want to force it for those numbers that need exponents.
Unfortunately, this is an important issue for this feature. One of
the main reasons for writing formatted files in fortran rather than
unformatted files is to transfer data between different programs,
between programs and utilities written in different languages,
between different file systems, between computers with different
endian conventions, and so on.
$.02 -Ron Shepard
robin
| In <4cc8b663$0$497$c30e...@exi-reader.telstra.net>, on 10/28/2010| Not as CONNECTED.
As anything. Of course, a dummy is created.
robin
| In <4cc804cf$0$496$c30e...@exi-reader.telstra.net>, on 10/27/2010
| at 09:51 PM, "robin" <rob...@dodo.com.au> said:
|
| >Glenn was referring to arrays passed as a subscripted element, e.g.,
| >call sub(x(5))
| >where the caller intends that elements x(5) thru x(ubound(x)) are
| >sent.
|
That was not uncommon in FORTRAN in older times.
It can still be done.
Terence
(snipped)
> ...Aah, but this is one of the quirks: is there sufficient room for the
> value without the exponent, or not? eg. 0.001234491 in 7 characters: this
> could be written as ".001234" or "1234e-6", so it doesn't matter. But
> 0.01234491 would be ".012345" or "1234e-5", so it does. What is the
> algorithm that makes these decisions correctly and cleanly?
>
> Another point is the rounding. If the number is rendered to characters and
> then excess digits truncated, the number is likley to be rounded down. So
> you need to be a bit more clever, and it gets complicated and long-winded.
>
I did spot that and the possiblity of two different equal-length
solutions. I also noted and showed the rounding in the table (which
an internal write achieves).
I agree I didn't show the alternative of dropping the "e" before a "-"
sign but did write about it. I would prefer all solutions to contain
the "e" since it is required for a positive exponent and makes
representation symmetrical exeptt for when a negative mantissa robs a
space.
Had a work load. Going back to the problem.
Terence
> (snipped)
Here is the set of rules I have, to find the format treatment needed
to get maximum precision in represnting a floating point number in a
given width from 6 up.
Note that a value with a negative mantissa is treated as a positive
mantissa in a requested field of one less position in order to hold
the sign.
There is a small modification rule if the 'e' symbol is to be removed.
If the exponent is positive, either the 'e' or the '+' has to stay;
if the exponent is negative, the 'e' can be eliminated.
So a simple rule is "remove e" and leave the sign.
I have routine and testing program under test and optimization.
The method uses an internal write of the value in Ew.d format in
order to find the exponent and its sign as a character string.
Then either a modified e-format is used or else and F format directly.
WHEN MANTISSA NEGATIVE, EFFECTIVE REQUESTED FIELD WIDTH
IS REDUCED BY 1 FOR THE LEADING SIGN
VALUES six seven eight nine ten etc...
LEAD ZERO EXPONENT ELIMINATED E FORMAT WHILE EXPONENT <-01
.123456789E-04 123e-7 1235e-8 12346e-9 12346e-10 123457e-11
.123456789E-03 123e-6 1235e-7 12346e-8 123457e-9 123457e-10
.123456789E-02 123e-5 1235e-6 12346e-7 123457e-8 1234568e-9
F FORMAT USED
.123456789E-01 .01235 .012346 .0123457 .01234567 .012345678
.123456789 .12346 .123457 .1234568 .12345679 .123456789
1.23456789 1.2346 1.23457 1.234568 1.2345679 1.23456789
12.3456789 12.346 12.3457 12.34568 12.345679 12.3456789
123.456789 123.46 123.457 123.4568 123.45679 123.456789
1234.56789 1234.6 1234.57 1234.568 1234.5679 1234.56789
12345.6789 12346. 12345.7 12345.68 12345.679 12345.6789
123456.789 123457 123457. 123456.8 123456.79 123456.789
PLUS-0 ELIMINATED E FORMAT AT WIDTH <MAXWIDTH ELSE F FORMAT
1234567.89 1235E1 1234568 1234568. 1234567.9 1234567.89
12345678.9 1235E2 12346E2 12345679 12345679. 12345678.9
123456789. 1235E3 12345E3 123457E3 123456789 123456789.
.123456789E+10 1235E4 12345E4 123457E4 1234568E4 12345679E4
.123456789E+11 1235E5 12345E5 123457E5 1234568E5 12345679E5
.123456789E+12 1235E6 12345E6 123457E6 1234568E6 12345679E6
.123456789E+13 1235E7 12345E7 123457E7 1234568E7 12345679E7
.123456789E+14 1235E8 12345E8 123457E8 1234568E8 12345679E8
.123456789E+15 1235E9 12345E9 123457E9 1234568E9 12345679E9
PLUS-ELIMINATED NORMAL E FORMAT FOR EXPONENT >9
.123456789E+16 124E10 1235E10 12346E10 123457E10 1234568E10
ETC
Colin Watters
OK, this looks promising. When your test harness is working you will be
able to spot some more quirks. Here are the ones I can see.
Line 1:
.123456789E-04 123e-7 1235e-8 12346e-9 12346e-10 123457e-11
12346e-9 and 12346e-10 differ by a factor of 10. Whoops! When choosing to
omit the decimal, it is vital to get the number of digits correct.
This is an interesting quirk of this magnitude and space combination. If
you want to display 12346e-9, it clearly needs 8 characters. So, if you
actually have 9 characters available, how do you add the extra digit to
allow additional precision to be displayed? ... Turns out it can't be done,
you have to "waste" the available extra space. You can't use a mantissa of
123456 coz that needs an exponent of -10, so the whole thing needs 11
characters now. And adding an explicit decimal point anywhere will use up
the single additional space.
Next, a minor quibble on line 3:
.123456789E-02 123e-5 1235e-6 12346e-7 123457e-8 1234568e-9
An alternative form would be:
.123456789E-02 .00123 .001235 .0012346 .00123457 .001234568
Which has the same significant digits all through, but ... what about if we
extend it to 11 character spaces being available? The exponent form will be
12345679e-10, needing a 2-digit exponent, so it won't fit. But the the
fractional form is .0012345679, which will.
Next we have the line for 1234567.89:
1234567.89 1235E1 1234568 1234568. 1234567.9 1234567.89
the E1 should be E3. Same problem exists for all exponents on all
subsequent lines, they all need 2 added to them.
Despite these minor issues, its clear you are getting to grips with this
challenge, and I am greatly looking forward to seeing the finished
algorithm. Then we can have a shoot-out to compare CPU time and overall
accuracy.
robin
| In <4ccae9a4$0$500$c30e...@exi-reader.telstra.net>, on 10/30/2010| That only works for read-only parameters.
That's what "a dummy is created" means.
Clive Page
<bo...@qomputing.com> writes
>Theres no doubt it can be done, see my posting of 4 years ago, referred to
>upthread:
>
>http://groups.google.com/group/comp.lang.fortran/msg/e54cc49eed61b1bd?&q
>=rcompact
>
>Problem is however its very CPU intensive, verbose, and altogether
>unsatisfying. In addition the code makes extensive use of Fortran internal
>file I/O, hence the function itself cannot be referenced on a write
>statement, as would be natural for any normal Formatted write (F2003
>aside). That's why I (we) want the language to do it "native". Failing
>that, could someone come up with a better implimentation than the code I
>have shown.
I agree there's a problem, with no elegant solution.
I just thought I should point out that Fortran 2008 includes the DT
format descriptor to handle derived types (see section 10.7.6). It's a
pity that it doesn't seem to allow handling of intrinsic types as well,
as that would seem to make it a bit easier to use user-written code,
such as Colin's posted above.
--
Clive Page
robin
| In <4cce13e3$0$22689$c30e...@exi-reader.telstra.net>, on 11/01/2010
| at 12:11 PM, "robin" <rob...@dodo.com.au> said:
|In <4cc8b663$0$497$c30e...@exi-reader.telstra.net>, on 10/28/2010
at 10:31 AM, "robin" <rob...@dodo.com.au> said:
at 01:37 AM, "robin" <rob...@dodo.com.au> said:
> I agree with Glenn about passing parts of arrays,
Isn't that only an issue for CONNECTED?
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
news:4cc6c0e3$3$fuzhry+tra$mr2...@news.patriot.net...
| In <4cc596b2$1$496$c30e...@exi-reader.telstra.net>, on 10/26/2010
| at 01:37 AM, "robin" <rob...@dodo.com.au> said:
|
| > I agree with Glenn about passing parts of arrays,
|
| Isn't that only an issue for CONNECTED?
Glenn was referring to arrays passed as a subscripted element,
e.g., call sub(x(5))
where the caller intends that elements x(5) thru x(ubound(x)) are sent.
Some simple cases could be translated automatically,
others might need hand translation via DEFINED or iSUB.
>>Of course such an array can be passed!
>Not as CONNECTED.
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
| Which is why it was irrelevant.
It isn't irrelevant, because a DEFINED/iSUB array can be
passed.
In each of two previous posts, you claimed/inferred that it could not be ;
and I corrected your mistake.
Richard Maine
> I just thought I should point out that Fortran 2008 includes the DT
> format descriptor to handle derived types (see section 10.7.6). It's a
> pity that it doesn't seem to allow handling of intrinsic types as well,
> as that would seem to make it a bit easier to use user-written code,
> such as Colin's posted above.
Yes, I've noted before that there is no obvious reason to restrict the
DT edit descriptor to derived types. It is far from my favorite f2003
feature anyway, but as long as it is in the language, it might as well
be slightly more general. I think people were just too narrowly focused
on a particular request (namely whatever it took to get a "yes" vote
from the German representative, which didn't end up happening anyway)
and failed to sit back and generalize well when crafting it. It isn't as
though it would take much in the way of additional work at the level of
standard writing (of course, it would be some extra work for compiler
writers, though). I think about all that would be needed would be to
drop the restrictions that say it applies only to derived types and it
would be pretty much done.
It would end up being able to address several requests that sometimes
come up here.
I almost think that the biggest problem would just be the possible
confusion caused by the misleading choice of name for the feature,
"derived type" being what the DT stands for. I have taken to calling it
just defined I/O in a way parallel to defined operations and defined
assignment. It seems to me that the parallels are strong; neither of
those other features is restricted to derived types.
glen herrmannsfeldt
>> I agree with Glenn about passing parts of arrays,
(snip)
> Some simple cases could be translated automatically,
> others might need hand translation via DEFINED or iSUB.
>>>Of course such an array can be passed!
(snip)
> It isn't irrelevant, because a DEFINED/iSUB array can be
> passed.
> In each of two previous posts, you claimed/inferred that
> it could not be ; and I corrected your mistake.
OK, somewhere in between. If you want to get values back
it is, obviously, not useful.
A large fraction of the cases of DEFINED could be done using
the usual descriptor format, but, last I knew, weren't done.
One applicable form is a column-major array, convenient for
calls between Fortran and PL/I. (To get at least slightly
on-topic for this post.)
-- glen
robin
| In comp.lang.fortran robin <rob...@nospam.com.au> wrote:
| > "Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in message
| OK, somewhere in between. If you want to get values back
| it is, obviously, not useful.
If you want to get values back, you pass the original array,
and also do a DEFINED/iSUB in the called procedure.
| A large fraction of the cases of DEFINED could be done using
| the usual descriptor format, but, last I knew, weren't done.
Certainly some can.
| One applicable form is a column-major array, convenient for
| calls between Fortran and PL/I. (To get at least slightly
| on-topic for this post.)
Depends on what is done in the called procedure.
They can be passed directly when the order is unimportant,
without the need to transpose (which is what was done
with PL/I-F when calling FORTRAN procedures).
Terence
> "Terence" <tbwri...@cantv.net> wrote in message
The comments are correct, but the table was done manually to indicate
the problem.
My program doesn't do that.
I had a working version which did not appear to be the best way,
(economically) and yes, I found the circular condition problem of how
to make decisions, when one situation raises the exponent to two
digits and so blocks that possibility of improvng precision. The same
happens at three digit exponents which then lose the "E" when executed
by F77.
I am on my third method.
Interesting to read the Fortran manual of Compaq for my F90/95
compiler and see the incorrect definition of the results of using E,
ESs and G formats. The descriptive text has been copied and pasted
among four related formatting services (F,E,ES and G) but without
changing the behaviours to match actuality.
I tried generating tables of results of simple E,F and G formats to
see exactly what the implementation is in execution in printing
123456789 * 10^^n for a large range of n. (Strange things result here
and there).
So I went back to the limitations of F77 as a common denominator.
My current method now uses a generated format (when not able to use F
as in low positive exponents if the width allows) to get the correct
rounded digit string for the final exponent (in a field length of 0,1
or 2 more than the final length) and then eliminate the decimal point,
the possible exponent zero and the optional "E", to leave an intger
string with the correct sign and followed by the exponent indicator,
which may have E when positive with n and nn and nnn..., else -n or -
nn or -nnn....
Colin Watters
<snip>
I'm actually rather glad you are finding this more tricky than you first
imagined it would be. It means the result is likley to be good. Roll on the
F77 solution!
Terence
>
>
> I'm actually rather glad you are finding this more tricky than you first
> imagined it would be. It means the result is likley to be good. Roll on the
> F77 solution!
>
Here is yhe F77 version I mentioned (CMAXD) to show real V in shortest
text form, and test program.
It's good for field lengths of 6 to 19, after which you just have to
increase the work area C22.
Test output is all widths with only E+ to + extra reduction and then
with optional E removal leaving just exponent signs.
PROGRAM EFORMAT
IMPLICIT INTEGER (I-N)
C TEST PROGRAM FOR CMAXD SUBROUTINE
REAL*8 TEN
REAL*8 V
C IW, IESW MUST MATCH SUBROUTINE USAGE
INTEGER IW,IESW
INTEGER KP,IE,IW,IL,KP,INEG
C I4 MUST BE INTEGER*4 TYPE
INTEGER I4
CHARACTER*20 CIW
TEN=10.0D0
C
OPEN(2,FILE='LIST',ACCESS='SEQUENTIAL',STATUS='NEW',
1 FORM='FORMATTED')
I4=123456789
IESW=0
DO 3 IE=1,2
C MAX PRECISION EXPECTED TO BE 15, PLUS E-NN
DO 2 IW=6,19
WRITE(2,900) IW,IESW
KP=-14
INEG=0
DO 1 I=1L,20
KP=KP+1
V=I4*(TEN**KP)
INEG=INEG+1
IF (INEG.GT.1) THEN
INEG=0
ELSE
V=-V
ENDIF
CIW=' '
CALL CMAXD(V,IESW,IW,CIW)
C OUTPUT
WRITE(2,901) V,CIW
1 CONTINUE
2 CONTINUE
C NOW CHECK WITH E+NN CHANGE TO +NN
IESW=1
3 CONTINUE
CLOSE(2)
900 FORMAT(/,' WIDTH=',I2,' IESW=',I1)
901 FORMAT(' V=',0PE16.9,' R=',A20)
END
C-------------------------------------
SUBROUTINE CMAXD(V,IESW,IW,CIW)
IMPLICIT INTEGER (I-N)
C SUBROUTINE TO REDUCE REAL NUMBER TO MINIMUM CHARACTER PRESENTATION
C AUTHOR T.B.WRIGHT, TAU Systems
C IW IS REQUESTED FIELD WIDTH TO SHOW V AS TEXT, RETURNED IN FIELD CIW
C MAXIMUM FIELD LENGTH 19, MAXIMUM PRECISION 15
C IESW=0 TO ALWAYS REMOVE 'E', ELSE IESW=1, TO CHANGE ONLY 'E+' TO '+'
REAL*8 V
C REQUIRED FIELD LENGTH, 'E' SWITCH
INTEGER IW,IESW
CHARACTER*20 CIW
C WORK AREA, REMOTE FORMAT, TEST EXPONENT, FINAL UNREDUCED EXPONENT
CHARACTER*22 C22
CHARACTER*12 CFRM
CHARACTER*8 C8
CHARACTER*4 C4
C WORK LENGTH, ABS(EXPONENT), MANTISSA LENGTH
INTEGER KW,K,ND
C EXPONENT VALUES: GIVEN AND MODIFIED
INTEGER IEA,IEF
C SWITCHES FOR NEGATIVE, ABS(FINAL EXPONENT)<10, +/E REMOVAL
INTEGER ISN,ISO,ISE
C CHARACTER STRING INDEXES TO 'E' '+' '0' IN EXPONENT
INTEGER K3,K2,K1
$DEBUG
C BLANK THE WORK AREA
C22=' '
C IF NEGATIVE SIGN IN VALUE ISN=1 ELSE ZERO?
ISN=0
IF (V.LE.0.0D0) ISN=1
C GET SIGN AND MAGNITUDE OF EXPONENT IEA, USING WIDTH 8 STRING C8
WRITE(C8,901,ERR=11) V
C WILL FAIL IF MAGNITUDE EXPONENT IS >999
901 FORMAT(E8.2)
C HAVE s.vvesdd OR s.vvsddd
IF (C8(5:5).EQ.'E') THEN
C HAVE s.vvesdd
READ(C8,902) IEA
902 FORMAT(5X,I3)
ELSE
C HAVE s.vvsddd
READ(C8,903) IEA
903 FORMAT(4X,I4)
ENDIF
C
C IF ORIGINAL EXPONENT BELOW -01 PERHAPS CAN USE E FORMAT
IF (IEA.GE.-01) THEN
C PAUSE 'IEA>-01'
C K IS EFFECTIVE WIDTH WITHOUT - SIGN
K=IW-ISN
IF (IEA.LE.K) THEN
C
C**** F FORMAT POSSIBLE
C CAN USE Fw.d FORMAT WITH POINT AND ND DECIMALS (IEA IS +VE OR ZERO)
C NEED IW -DOT -#SIGNIFICANTS) DECIMALS
ND=IW-ISN-1
IF (IEA.GE.0) ND=ND-IEA
KW=IW
IF (ND.LT.0) THEN
K=IW+2
WRITE(CFRM,904) K
WRITE(C22,CFRM,ERR=11) V
904 FORMAT('(F',I3.3,'.0 ) ')
ELSE
K=IW+1
WRITE(CFRM,905) K,ND
WRITE(C22,CFRM,ERR=11) V
905 FORMAT('(F',I3.3,'.',I2.2,') ')
ENDIF
GO TO 10
ENDIF
ENDIF
C
C**** E FORMAT NEEDED:
C EXPONENT FOR s.ddEsee OR s.ddseee FORM IS IEA
C ORIGINAL EXPONENT IS IEA, MODIFIED EXPONENT WILL BE IEW
C IEW=IEA-2+ISN-(IW-6)
IEW=IEA+4+ISN-IW
C
C CAN REMOVE 'E'. IESW=1 SAYS TAKE E, ELSE ONLY TAKE + FROM E+
ISE=IESW
IF (IEW.GT.0) ISE=1
C BUT NOT IF EXPONENT OVER TWO DIGITS
C TAKES >100 TO >99?
IF (IEW.GT.100) ISE=0
C TAKES <-99 TO <-100?
IF (IEW.LT.-99) ISE=0
C INCLUDE AFFECTS OF ISE (EXPONENT MORE NEGATIVE IF MORE LEAD DIGITS)
IEW=IEW-ISE
C DOES, OR CAN, EXPONENT CONTAIN LEADING ZERO?
IS0=1
IF (IEW.GT.10) IS0=0
IF (IEW.LE.-9) IS0=0
C CAN GET MORE PRECISION IF ISE OR IS0 OR, BOTH AND DOT REMOVED
IEW=IEW-IS0
KW=IW+ISE+IS0+1
C GET ABSOLUTE VALUE OF IEW
K=IEW
IF (K.LT.0) K=-K
C ERROR IF FINAL EXPONENT >999
IF (K.GT.999) GO TO 11
C 100<IEA<100; WRITE SIGNED VALUE TO C4
IF (K.GT.99) THEN
WRITE(C4,906,ERR=11) IEW
906 FORMAT(I4.3)
ELSE
WRITE(C4,907,ERR=11) IEW
907 FORMAT('E',I3.2)
IF (C4(2:2).EQ.' ') C4(2:2)='+'
ENDIF
C WORK WITH WANTED LENGTH PLUS UP TO 3 EXTRA
KW=IW+ISE+IS0+1
C DOT AND EXPONENT TAKE 5 OF WORK LENGTH
ND=KW-5-ISN
WRITE(CFRM,908) KW,ND
908 FORMAT('(0PE',I3.2,'.',I2.2,') ')
C
WRITE(C22,CFRM) V
K1=KW-3
C22(K1:KW)=C4
C NEG. CASES ARE S.dddEs0e OR S.dddEsee OR s.dddseee...
C POS. CASES ARE .ddddEs0e OR .ddddEsee OR .ddddseee...
C OUTPUT IS 1,2 OR 3 LONGER THAN REQUESTED (FOR DOT,IS0,ISE)
K1=KW-1
IF (IS0.EQ.1) THEN
C REMOVE KNOWN 0 FROM Es0d
C22(K1:K1)=C22(KW:KW)
C22(KW:KW)=' '
ENDIF
K2=K1-1
C TAKE E OR ONLY TAKE +?
IF (IESW.EQ.0) THEN
C REMOVE '+'
IF (C22(K2:K2).EQ.'+') THEN
C22(K2:K1)=C22(K1:KW)
ENDIF
ELSE
C REMOVE 'E'
K3=K2-1
IF (C22(K3:K3).EQ.'E') THEN
C22(K3:K1)=C22(K2:KW)
ENDIF
ENDIF
C REMOVE DOT
IF (C22(1:1).EQ.'-') C22(2:2)='-'
10 K1=IW+1
CIW(1:IW)=C22(2:K1)
RETURN
C NOT POSSIBLE
11 CIW(1:IW)='********************'
RETURN
END
Colin Watters
> On Nov 4, 7:00 am, "Colin Watters" <b...@qomputing.com> wrote:
> >
> >
> > I'm actually rather glad you are finding this more tricky than you
> > first
> > imagined it would be. It means the result is likley to be good. Roll on
> > the
> > F77 solution!
> >
> Just saw this new post.
>
> Here is yhe F77 version I mentioned (CMAXD) to show real V in shortest
> text form, and test program.
> It's good for field lengths of 6 to 19, after which you just have to
> increase the work area C22.
> Test output is all widths with only E+ to + extra reduction and then
> with optional E removal leaving just exponent signs.
<code elided>
OK this is looking very promising. Your subroutine CMAXD has no loops so it
should be *A LOT* faster than mine. I'm impressed.
...Alas at present it has problems. I have re-written the test program to
exercise over a much wider range of values, in more detail, and locate the
value with the maximum error when compared to the original. At present
there are errors of around 1000%... that is rather a lot, we shouldn't
really be getting anything over 1%! Looks like an exponent foible.
Here is the screen output from the test program:
error orig char
1 0 6 2372 9.00084613 0.996915648058324E+66 997E64
1 0 7 2372 9.00029206 0.998970823845922E-38 999E-40
1 0 8 2372 9.00029206 0.998970823845922E-38 9990E-41
1 0 9 2372 9.00003083 0.995046932608276E-09 99505E-13
1 0 10 2372 9.00000176 0.998970823845922E-38 998971E-43
1 0 11 2372 9.00000034 0.996072066226579E-61 9960721E-67
1 0 12 2372 9.00000004 0.996072066226579E-61 99607207E-68
1 0 13 2372 9.00000000 0.995046932608276E-09 995046933E-17
1 0 14 2372 9.00000000 0.996915648058324E+66 99691564806E56
1 0 15 2372 9.00000000 0.998970823845922E-38 99897082385E-48
1 0 16 2372 9.00000000 0.996072066226579E-61 996072066227E-72
1 0 17 2372 9.00000000 0.995046932608276E-09 9950469326083E-21
1 0 18 2372 9.00000000 0.995046932608276E-09 99504693260828E-22
1 0 19 2372 9.00000000 0.998970823845922E-38 998970823845922E-52
1 1 6 2372 9.00084613 0.996915648058324E+66 997+64
1 1 7 2372 9.00029206 0.998970823845922E-38 9990-41
1 1 8 2372 9.00004365 0.996915648058324E+66 99692+62
1 1 9 2372 9.00000353 0.996915648058324E+66 996916+61
1 1 10 2372 9.00000039 0.999816860659935E+89 9998169+83
1 1 11 2372 9.00000004 0.996072066226579E-61 99607207-68
1 1 12 2372 9.00000000 0.995046932608276E-09 995046933-17
1 1 13 2372 9.00000000 0.996915648058324E+66 9969156481+57
1 1 14 2372 0.100000000E+91 0.141848096365356E-89 14184809637-10
1 1 15 2372 0.100000000E+91 0.163903449840702E-88 163903449841-10
1 1 16 2372 0.100000000E+91 0.189388095843664E-87 1893880958437-10
1 1 17 2372 0.100000000E+91 0.108760259903906E-86 10876025990391-10
1 1 18 2372 0.100000000E+91 0.105517152724508E-85 105517152724508-10
1 1 19 2372 0.100000000E+91 0.145210961968844E-84 1452109619688445-10
-1 0 6 2372 2.33235936 0.150109652265210E-62 -2E-63
-1 0 7 2372 11.0008461 0.996915648058324E+66 -997E64
-1 0 8 2372 11.0002921 0.998970823845922E-38 -999E-40
-1 0 9 2372 11.0002921 0.998970823845922E-38 -9990E-41
-1 0 10 2372 11.0000308 0.995046932608276E-09 -99505E-13
-1 0 11 2372 11.0000018 0.998970823845922E-38 -998971E-43
-1 0 12 2372 11.0000003 0.996072066226579E-61 -9960721E-67
-1 0 13 2372 11.0000000 0.996072066226579E-61 -99607207E-68
-1 0 14 2372 11.0000000 0.995046932608276E-09 -995046933E-17
-1 0 15 2372 11.0000000 0.996915648058324E+66 -99691564806E56
-1 0 16 2372 11.0000000 0.998970823845922E-38 -99897082385E-48
-1 0 17 2372 11.0000000 0.996072066226579E-61 -996072066227E-72
-1 0 18 2372 11.0000000 0.995046932608276E-09 -9950469326083E-21
-1 0 19 2372 11.0000000 0.995046932608276E-09 -99504693260828E-22
-1 1 6 2372 2.04659549 0.105102688336646E-56 -11-58
-1 1 7 2372 11.0008461 0.996915648058324E+66 -997+64
-1 1 8 2372 11.0002921 0.998970823845922E-38 -9990-41
-1 1 9 2372 11.0000437 0.996915648058324E+66 -99692+62
-1 1 10 2372 11.0000035 0.996915648058324E+66 -996916+61
-1 1 11 2372 11.0000004 0.999816860659935E+89 -9998169+83
-1 1 12 2372 11.0000000 0.996072066226579E-61 -99607207-68
-1 1 13 2372 11.0000000 0.995046932608276E-09 -995046933-17
-1 1 14 2372 11.0000000 0.996915648058324E+66 -9969156481+57
-1 1 15 2372 0.100000000E+91 0.141848096365356E-89 -14184809637-10
-1 1 16 2372 0.100000000E+91 0.163903449840702E-88 -163903449841-10
-1 1 17 2372 0.100000000E+91 0.189388095843664E-87 -1893880958437-10
-1 1 18 2372 0.100000000E+91 0.108760259903906E-86 -10876025990391-10
-1 1 19 2372 0.100000000E+91 0.105517152724508E-85 -105517152724508-10
Fortran Pause - Enter command<CR> or <CR> to continue.
I have re-formatted CMAXD somewhat to make it easier to read (well, *I*
find it easier, but then again I do have a colourizing editor) but there
are no actual code changes therein.
Below is the new test program and the reformatted CMAXD. I don't have time
right now to figure out what is going wrong, maybe tomorrow.
PROGRAM EFORMAT
implicit none
REAL*8 V, v_new, err, max_err, v_max
INTEGER IW,IESW , ip
INTEGER IE,IL,INEG
CHARACTER*20 CIW , ciw_max
write(*,229)
229 format(10x,' error orig char')
C
!-----loop for positive or negative
do ineg = +1, -1, -2
!-------loop for with/without an E in the exponent
DO IEsw = 0, 1
!---------loop through character widths
DO IW = 6, 19
max_err = 0.
!-----------loop through values of v
v = 1d-90
DO Ip=1, 200000
!-------------increase v, exit when it gets big enough
v = v * 1.191
if(v.gt.1d90) exit
!-------------convert to character
CIW=' '
CALL CMAXD(V*ineg,IESW,IW,CIW)
!-------------convert back to real, compare with original
read(ciw,'(f22.0)') v_new
err = (v-v_new)/v
if(abs(err).gt.max_err) then
max_err = abs(err)
!! print *,v,trim(ciw),v_new, err
ciw_max = ciw
v_max = v
continue
endif
enddo
write(*,'(3i3,i5,1x,g16.9,1x,g22.15,1x,a)') ineg,iesw,iw,ip,
& max_err, v_max, ciw_max
CALL CMAXD(V_max*ineg,IESW,IW,CIW)
enddo
enddo
enddo
pause
END
C-------------------------------------
C-------------------------------------
C-------------------------------------
REAL*8 V
C BLANK THE WORK AREA
C22=' '
C IF NEGATIVE SIGN IN VALUE ISN=1 ELSE ZERO?
ISN=0
IF (V.LE.0.0D0) ISN=1
C GET SIGN AND MAGNITUDE OF EXPONENT IEA, USING WIDTH 8 STRING C8
C WILL FAIL IF MAGNITUDE EXPONENT IS >999
WRITE(C8,901,ERR=11) V
901 FORMAT(E8.2)
GO TO 10 ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
ENDIF
ENDIF
C
C **** E FORMAT NEEDED:
IF (K.GT.999) GO TO 11 ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
Colin Watters
subject to error caused by rounding-up when the first 2 significant digits
of the mantissa are '95'. Changing it to use E22.15 fixes the first 22 or
so errors. The first line still has a rather high error but its much better
than it was..
After that there is another issue, caused by the removal of the decimal
point resulting in a need for a 3-digit exponent when the original needed
just 2. I will try to nail that as well, but its getting late here...
Here is the latest output:
error orig char
1 0 6 2372 0.899981683 0.999816860659935E+89 100E86
1 0 7 2372 0.457600744E-02 0.105517152724508E-85 106E-88
1 0 8 2372 0.462501027E-03 0.106550720182526E-68 1066E-72
1 0 9 2372 0.450418804E-04 0.102265393774367E-32 10227E-37
1 0 10 2372 0.482679925E-05 0.103373498963127E-67 103373E-73
1 0 11 2372 0.475619340E-06 0.102370751310491E-84 1023708E-91
1 0 12 2372 0.493025063E-07 0.101273395006968E-49 10127340E-57
1 0 13 2372 0.478429645E-08 0.102668669508803E-61 102668670E-70
1 0 14 2372 0.490341351E-09 0.100582884649320E-43 1005828846E-53
1 0 15 2372 0.474784660E-10 0.100291018864762E-66 10029101886E-77
1 0 16 2372 0.479474500E-11 0.102370751310491E-84 102370751310E-96
1 0 17 2372 0.465163751E-12 0.104689851937451E-27 1046898519375E-40
1 0 18 2372 0.488480916E-13 0.100979525538105E-72 10097952553810E-86
1 0 19 2372 0.467909290E-14 0.104994519156081E-04 104994519156081E-19
1 1 6 2372 0.899981683 0.999816860659935E+89 100+86
1 1 7 2372 0.462501027E-03 0.106550720182526E-68 1066-72
1 1 8 2372 0.490184338E-04 0.101065045949740E+55 10107+50
1 1 9 2372 0.482679925E-05 0.103373498963127E-67 103373-73
1 1 10 2372 0.487645980E-06 0.102457449962964E+43 1024574+36
1 1 11 2372 0.493025063E-07 0.101273395006968E-49 10127340-57
1 1 12 2372 0.478429645E-08 0.102668669508803E-61 102668670-70
1 1 13 2372 0.492161579E-09 0.101065045949740E+55 1010650459+45
1 1 14 2372 0.100000000E+91 0.141848096365356E-89 14184809637-10
1 1 15 2372 0.100000000E+91 0.163903449840702E-88 163903449841-10
1 1 16 2372 0.100000000E+91 0.189388095843664E-87 1893880958437-10
1 1 17 2372 0.100000000E+91 0.108760259903906E-86 10876025990391-10
1 1 18 2372 0.100000000E+91 0.105517152724508E-85 105517152724508-10
1 1 19 2372 0.100000000E+91 0.145210961968844E-84 1452109619688445-10
-1 0 6 2372 2.33235936 0.150109652265210E-62 -2E-63
-1 0 7 2372 2.04659549 0.105102688336646E-56 -11E-58
-1 0 8 2372 2.00457601 0.105517152724508E-85 -106E-88
-1 0 9 2372 2.00046250 0.106550720182526E-68 -1066E-72
-1 0 10 2372 2.00004504 0.102265393774367E-32 -10227E-37
-1 0 11 2372 2.00000470 0.100979525538105E-72 -100980E-78
-1 0 12 2372 2.00000048 0.102370751310491E-84 -1023708E-91
-1 0 13 2372 2.00000005 0.101273395006968E-49 -10127340E-57
-1 0 14 2372 2.00000000 0.102668669508803E-61 -102668670E-70
-1 0 15 2372 2.00000000 0.104994519156081E-04 -1049945192E-14
-1 0 16 2372 2.00000000 0.104386068785104E-50 -10438606879E-61
-1 0 17 2372 2.00000000 0.105517152724508E-85 -105517152725E-97
-1 0 18 2372 2.00000000 0.104689851937451E-27 -1046898519375E-40
-1 0 19 2372 2.00000000 0.106550720182526E-68 -10655072018253E-82
-1 1 6 2372 2.04659549 0.105102688336646E-56 -11-58
-1 1 7 2372 2.00457601 0.105517152724508E-85 -106-88
-1 1 8 2372 2.00046250 0.106550720182526E-68 -1066-72
-1 1 9 2372 2.00004902 0.101065045949740E+55 -10107+50
-1 1 10 2372 2.00000470 0.100979525538105E-72 -100980-78
-1 1 11 2372 2.00000048 0.102370751310491E-84 -1023708-91
-1 1 12 2372 2.00000005 0.101273395006968E-49 -10127340-57
-1 1 13 2372 2.00000000 0.102668669508803E-61 -102668670-70
-1 1 14 2372 2.00000000 0.103461046851042E+60 -1034610469+50
-1 1 15 2372 0.100000000E+91 0.141848096365356E-89 -14184809637-10
-1 1 16 2372 0.100000000E+91 0.163903449840702E-88 -163903449841-10
-1 1 17 2372 0.100000000E+91 0.189388095843664E-87 -1893880958437-10
-1 1 18 2372 0.100000000E+91 0.108760259903906E-86 -10876025990391-10
-1 1 19 2372 0.100000000E+91 0.105517152724508E-85 -105517152724508-10
Fortran Pause - Enter command<CR> or <CR> to continue.
Terence
I agree with the comments that there are problems outside exponents of
magnitude above 99 or so, but in defence have to point out that my F77
manual states that real values are limited to +8.43e-37 to 3.37e+38
for single precision, and 4.1090D-302 to 1.67D+308 for double
precision.
So I thought I made sure the routine worked within the central 200 or
so possibilities since i didn't want to list and check over 600 values
for each of 12 field sizes and two mantissa signs.
I will study the notes and suggestions and try to make changes to
extend the range, even if I can't test all 64-bit possibilities with
this compiler and 32 bit register computer.
Richard Maine
> ...my F77
> manual states that real values are limited to +8.43e-37 to 3.37e+38
> for single precision, and 4.1090D-302 to 1.67D+308 for double
> precision.
That would be for the particular implementation - not for f77 in
general. The standard does not specify the ranges and f77 compilers have
existed with ranges a lot different than that.
glen herrmannsfeldt
> Terence <tbwr...@cantv.net> wrote:
>> ...my F77
>> manual states that real values are limited to +8.43e-37 to 3.37e+38
>> for single precision, and 4.1090D-302 to 1.67D+308 for double
>> precision.
> That would be for the particular implementation - not for f77 in
> general. The standard does not specify the ranges and f77 compilers have
> existed with ranges a lot different than that.
For the Cray-1 and related processors, the binary exponent has 15 bits,
allowing for about 1e-4900 to 1e+4900. I believe Cray used the
64 bit format as single precision, and a (presumably) rarely used
software 128 bit for double precision, as Fortran requires a
double precision.
The ranges Terence gave are pretty common for 32 bit and 64 bit
binary floating point (even before IEEE).
For IBM S/360 hex float, the range is from about 5.4e-79 to
about 7.2e+75, single or double precision.
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Richard Maine <nos...@see.signature> wrote:
>> Terence <tbwr...@cantv.net> wrote:
>
>>> ...my F77
>>> manual states that real values are limited to +8.43e-37 to 3.37e+38
>>> for single precision, and 4.1090D-302 to 1.67D+308 for double
>>> precision.
>
>> That would be for the particular implementation - not for f77 in
>> general. The standard does not specify the ranges and f77 compilers have
>> existed with ranges a lot different than that.
>
>binary floating point (even before IEEE).
Er, no. Even on the VAX, they were only two of the options. Yes,
they existed, but it's inaccurate to imply that they were common.
Few general rules applied.
Regards,
Nick Maclaren.
Colin Watters
> On Nov 8, 10:01 am, "Colin Watters" <b...@qomputing.com> wrote:
> > OK I have found one problem. The write statement using format 901 is
> > subject to error caused by rounding-up when the first 2 significant
> > digits
> > of the mantissa are '95'. Changing it to use E22.15 fixes the first 22
> > or
> > so errors. The first line still has a rather high error but its much
> > better
> > than it was..
> >
> > After that there is another issue, caused by the removal of the decimal
> > point resulting in a need for a 3-digit exponent when the original
> > needed
> > just 2. I will try to nail that as well, but its getting late here...
> >
> > Here is the latest output:
> >
> > error orig char
> > 1 0 6 2372 0.899981683 0.999816860659935E+89 100E86
<snip>
> > -1 1 19 2372 0.100000000E+91 0.105517152724508E-85 -105517152724508-10
> > Fortran Pause - Enter command<CR> or <CR> to continue.
> >
> > --
> > Qolin
> >
> > Email: my qname at domain dot com
> > Domain: qomputing
>
> I agree with the comments that there are problems outside exponents of
> magnitude above 99 or so, but in defence have to point out that my F77
> manual states that real values are limited to +8.43e-37 to 3.37e+38
> for single precision, and 4.1090D-302 to 1.67D+308 for double
> precision.
> So I thought I made sure the routine worked within the central 200 or
> so possibilities since i didn't want to list and check over 600 values
> for each of 12 field sizes and two mantissa signs.
>
> I will study the notes and suggestions and try to make changes to
> extend the range, even if I can't test all 64-bit possibilities with
> this compiler and 32 bit register computer.
OK, I have fixed all the problems. Here is the test program output:
error orig char
-1 0 6 7477 0.333227005 -0.150011962846494E-84 -2E-85
-1 0 7 7477 0.474430592E-01 -0.105017641806163E-18 -11E-20
-1 0 8 7477 0.481592698E-02 -0.103498440933700E-38 -103E-41
-1 0 9 7477 0.487680760E-03 -0.101350573275379E-82 -1014E-86
-1 0 10 7477 0.493694888E-04 -0.100875019851840E-39 -10088E-44
-1 0 11 7477 0.486969065E-05 -0.102300501828203E-73 -102301E-79
-1 0 12 7477 0.483313448E-06 -0.101467849040776E-69 -1014678E-76
-1 0 13 7477 0.488459525E-07 -0.100169744892887E-22 -10016974E-30
-1 0 14 7477 0.482892823E-08 -0.101585260509452E-56 -101585261E-65
-1 0 15 7477 0.492342494E-09 -0.100641973450450E-65 -1006419735E-75
-1 0 16 7477 0.484098150E-10 -0.101820491184929E-30 -10182049118E-41
-1 0 17 7477 0.482230831E-11 -0.102237410911493E-32 -102237410911E-44
-1 0 18 7477 0.493632091E-12 -0.100641973450450E-65 -1006419734504E-78
-1 0 19 7477 0.485469617E-13 -0.100758429273895E-52 -10075842927390E-66
-1 1 6 7477 0.475240953E-01 -0.105009517677524E+77 -11+75
-1 1 7 7477 0.481592698E-02 -0.103498440933700E-38 -103-41
-1 1 8 7477 0.489975708E-03 -0.100750634636472E+43 -1008+39
-1 1 9 7477 0.493694888E-04 -0.100875019851840E-39 -10088-44
-1 1 10 7477 0.496140224E-05 -0.100688499556147E+84 -100688+78
-1 1 11 7477 0.494365324E-06 -0.101046250046238E+28 -1010463+21
-1 1 12 7477 0.488459525E-07 -0.100169744892887E-22 -10016974-30
-1 1 13 7477 0.482892823E-08 -0.101585260509452E-56 -101585261-65
-1 1 14 7477 0.492342494E-09 -0.100641973450450E-65 -1006419735-75
-1 1 15 7477 0.379726660E-09 -0.118093233044843E-89 -1180932330-99
-1 1 16 7477 0.412503547E-10 -0.114630498984729E-88 -11463049898-99
-1 1 17 7477 0.398472092E-11 -0.105268964069419E-87 -105268964069-99
-1 1 18 7477 0.409661619E-12 -0.111269299338246E-87 -1112692993382-100
-1 1 19 7477 0.426663072E-13 -0.102600664749026E-88 -10260066474903-102
1 0 6 7477 0.474430592E-01 0.105017641806163E-18 11E-20
1 0 7 7477 0.481592698E-02 0.103498440933700E-38 103E-41
1 0 8 7477 0.487680760E-03 0.101350573275379E-82 1014E-86
1 0 9 7477 0.493694888E-04 0.100875019851840E-39 10088E-44
1 0 10 7477 0.486969065E-05 0.102300501828203E-73 102301E-79
1 0 11 7477 0.483313448E-06 0.101467849040776E-69 1014678E-76
1 0 12 7477 0.488459525E-07 0.100169744892887E-22 10016974E-30
1 0 13 7477 0.482892823E-08 0.101585260509452E-56 101585261E-65
1 0 14 7477 0.492342494E-09 0.100641973450450E-65 1006419735E-75
1 0 15 7477 0.484098150E-10 0.101820491184929E-30 10182049118E-41
1 0 16 7477 0.482230831E-11 0.102237410911493E-32 102237410911E-44
1 0 17 7477 0.493632091E-12 0.100641973450450E-65 1006419734504E-78
1 0 18 7477 0.485469617E-13 0.100758429273895E-52 10075842927390E-66
1 0 19 7477 0.490769791E-14 0.100579905383813E-24 100579905383813E-39
1 1 6 7477 0.481592698E-02 0.103498440933700E-38 103-41
1 1 7 7477 0.489975708E-03 0.100750634636472E+43 1008+39
1 1 8 7477 0.493694888E-04 0.100875019851840E-39 10088-44
1 1 9 7477 0.496140224E-05 0.100688499556147E+84 100688+78
1 1 10 7477 0.494365324E-06 0.101046250046238E+28 1010463+21
1 1 11 7477 0.488459525E-07 0.100169744892887E-22 10016974-30
1 1 12 7477 0.482892823E-08 0.101585260509452E-56 101585261-65
1 1 13 7477 0.492342494E-09 0.100641973450450E-65 1006419735-75
1 1 14 7477 0.379726660E-09 0.118093233044843E-89 1180932330-99
1 1 15 7477 0.412503547E-10 0.114630498984729E-88 11463049898-99
1 1 16 7477 0.398472092E-11 0.105268964069419E-87 105268964069-99
1 1 17 7477 0.409661619E-12 0.111269299338246E-87 1112692993382-100
1 1 18 7477 0.426663072E-13 0.102600664749026E-88 10260066474903-102
1 1 19 7477 0.458791384E-14 0.102182263689070E-86 102182263689070-101
Fortran Pause - Enter command<CR> or <CR> to continue.
And below is the code. I had to make some more changes to CMAXD in order to
work out WTFWGO, and some of these will doubtless cause your F77 compiler
to barf. I use CVF here at home. Main problems were in the exponents
rounding down from -99 to -100, and +ve mantissa doing approximately the
same:
PROGRAM EFORMAT
implicit none
REAL*8 V, v_new, err, max_err, v_max, vv
INTEGER IW,IESW , ip
INTEGER IE,IL,INEG
CHARACTER*20 CIW , ciw_max
write(*,229)
229 format(10x,' error orig char')
C
!-----loop for positive or negative
do ineg = -1, +1, +2
!-------loop for with/without an E in the exponent
DO IEsw = 0, 1
!---------loop through character widths
DO IW = 6, 19
max_err = 0.
!-----------loop through values of v
vv = 1d-90
DO Ip=1, 200000
!-------------increase v, exit when it gets big enough
vv = vv * 1.057
if(vv.gt.1d90) exit
v = vv * ineg
!-------------convert to character
CIW=' '
CALL CMAXD(V,IESW,IW,CIW)
!-------------convert back to real, compare with original
read(ciw,'(f22.0)', err=102) v_new
err = (v-v_new)/v
if(abs(err).gt.max_err) then
CIW=' '
CALL CMAXD(V,IESW,IW,CIW)
max_err = abs(err)
!! print *,v,trim(ciw),v_new, err
ciw_max = ciw
v_max = v
continue
endif
cycle
102 continue
CALL CMAXD(V,IESW,IW,CIW)
enddo
write(*,'(3i3,i5,1x,g16.9,1x,g22.15,1x,a)') ineg,iesw,iw,ip,
& max_err, v_max, ciw_max
CALL CMAXD(V_max*ineg,IESW,IW,CIW)
enddo
enddo
enddo
pause
900 FORMAT(/,' WIDTH=',I2,' IESW=',I1)
901 FORMAT(' V=',0PE16.9,' R=',A20)
END
C-------------------------------------
C-------------------------------------
C-------------------------------------
SUBROUTINE CMAXD(V,IESW,aIW,CIW)
IMPLICIT none
C SUBROUTINE TO REDUCE REAL NUMBER TO MINIMUM CHARACTER PRESENTATION
C AUTHOR T.B.WRIGHT, TAU Systems
C IW IS REQUESTED FIELD WIDTH TO SHOW V AS TEXT, RETURNED IN FIELD CIW
C MAXIMUM FIELD LENGTH 19, MAXIMUM PRECISION 15
C IESW=0 TO ALWAYS REMOVE 'E', ELSE IESW=1, TO CHANGE ONLY 'E+' TO '+'
REAL*8 , intent(in ) :: V ! value to be converted
INTEGER , intent(in ) :: aIW ! allowed width
INTEGER , intent(in ) :: IESW ! 0 = retain E in exponent; 1 =
remove it
CHARACTER*20, intent(out) :: CIW
C WORK AREA, REMOTE FORMAT, TEST EXPONENT, FINAL UNREDUCED EXPONENT
CHARACTER*22 C22
CHARACTER*12 CFRM
CHARACTER*22 C8
CHARACTER*4 C4
C WORK LENGTH, ABS(EXPONENT), MANTISSA LENGTH
INTEGER KW,K,ND, iw
C EXPONENT VALUES: GIVEN AND MODIFIED
INTEGER IEA,IEw
C SWITCHES FOR NEGATIVE, ABS(FINAL EXPONENT)<10, +/E REMOVAL
INTEGER IS0,ISE
C CHARACTER STRING INDEXES TO 'E' '+' '0' IN EXPONENT
INTEGER K3,K2,K1
integer ruc ! rounding-up correction
C BLANK THE WORK AREA
C22=' '
if(v.ge.0.) then
iw = aiw
else
iw = aiw - 1 ! leave room for a leading minus
endif
C GET SIGN AND MAGNITUDE OF EXPONENT IEA, USING WIDTH 8 STRING C8
C WILL FAIL IF MAGNITUDE EXPONENT IS >999
WRITE(C8,901,ERR=11) V
901 FORMAT(E22.15)
C HAVE s.vvesdd OR s.vvsddd
IF (C8(19:19).EQ.'E') THEN
C HAVE s.vvesdd
READ(C8,902) IEA
902 FORMAT(19X,I3)
ELSE
C HAVE s.vvsddd
READ(C8,903) IEA
903 FORMAT(18X,I4)
ENDIF
C
C IF ORIGINAL EXPONENT BELOW -01 PERHAPS CAN USE E FORMAT
IF (IEA.GE.-01) THEN
C PAUSE 'IEA>-01'
C K IS EFFECTIVE WIDTH WITHOUT - SIGN
K=IW
IF (IEA.LE.K) THEN
C
C**** F FORMAT POSSIBLE
C CAN USE Fw.d FORMAT WITH POINT AND ND DECIMALS (IEA IS +VE OR
ZERO)
C NEED IW -DOT -#SIGNIFICANTS) DECIMALS
ND=IW-1
IF (IEA.GE.0) ND=ND-IEA
KW=IW
IF (ND.LT.0) THEN
K=IW+2
WRITE(CFRM,904) K
WRITE(C22,CFRM,ERR=11) V
904 FORMAT('(F',I3.3,'.0 ) ')
ELSE
K=IW+1
WRITE(CFRM,905) K,ND
WRITE(C22,CFRM,ERR=11) V
905 FORMAT('(F',I3.3,'.',I2.2,') ')
ENDIF
GO TO 10 ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
ENDIF
ENDIF
C
C **** E FORMAT NEEDED:
C EXPONENT FOR s.ddEsee OR s.ddseee FORM IS IEA
C ORIGINAL EXPONENT IS IEA, MODIFIED EXPONENT WILL BE IEW
C IEW=IEA-2+ISN-(IW-6)
IEW=IEA+4-IW
C
C CAN REMOVE 'E'. IESW=1 SAYS TAKE E, ELSE ONLY TAKE + FROM E+
ISE=IESW
IF (IEW.GT.0) ISE=1
C BUT NOT IF EXPONENT OVER TWO DIGITS
C TAKES >100 TO >99?
IF (IEW.GT.100) ISE=0
C TAKES <-99 TO <-100?
IF (IEW.Le.-99) ISE=0
C INCLUDE AFFECTS OF ISE (EXPONENT MORE NEGATIVE IF MORE LEAD DIGITS)
IEW=IEW-ISE
C DOES, OR CAN, EXPONENT CONTAIN LEADING ZERO?
IS0=1
IF (IEW.GT.10) IS0=0
IF (IEW.LE.-9) IS0=0
C CAN GET MORE PRECISION IF ISE OR IS0 OR, BOTH AND DOT REMOVED
IEW=IEW-IS0
KW=IW+ISE+IS0+1
C GET ABSOLUTE VALUE OF IEW
K=IEW
IF (K.LT.0) K=-K
C ERROR IF FINAL EXPONENT >999
IF (K.GT.999) GO TO 11 ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
C WORK WITH WANTED LENGTH PLUS UP TO 3 EXTRA
KW=IW+ISE+IS0+1
!!! kw = max(7,kw)
C DOT AND EXPONENT TAKE 5 OF WORK LENGTH
ND=KW-5
WRITE(CFRM,908) KW,ND
908 FORMAT('(0PE',I3.2,'.',I2.2,') ')
C
WRITE(C22,CFRM) abs(V)
!-----detect mantissa being rounded up from 9 to 10
ruc = 0
if(c22(2:2).eq.'1') then
if(c8(4:4).eq.'9') then
ruc = 1 ! rounding-up correction
endif
endif
C 100<IEA<100; WRITE SIGNED VALUE TO C4
IF (K.GT.99) THEN
WRITE(C4,906,ERR=11) IEW+ruc
906 FORMAT(I4.3)
ELSE
WRITE(C4,907,ERR=11) IEW+ruc
907 FORMAT('E',I3.2)
IF (C4(2:2).EQ.' ') C4(2:2)='+'
ENDIF
K1=KW-3
C22(K1:KW)=C4
C NEG. CASES ARE S.dddEs0e OR S.dddEsee OR s.dddseee...
C POS. CASES ARE .ddddEs0e OR .ddddEsee OR .ddddseee...
C OUTPUT IS 1,2 OR 3 LONGER THAN REQUESTED (FOR DOT,IS0,ISE)
K1=KW-1
IF (IS0.EQ.1) THEN
C REMOVE KNOWN 0 FROM Es0d
C22(K1:K1)=C22(KW:KW)
C22(KW:KW)=' '
ENDIF
K2=K1-1
C TAKE E OR ONLY TAKE +?
IF (IESW.EQ.0) THEN
C REMOVE '+'
IF (C22(K2:K2).EQ.'+') THEN
C22(K2:)=C22(K1:KW)
ENDIF
ELSE
C REMOVE 'E'
K3=K2-1
IF (C22(K3:K3).EQ.'E') THEN
C22(K3:)=C22(K2:KW)
ENDIF
ENDIF
C REMOVE DOT
IF (C22(1:1).EQ.'-') C22(2:2)='-'
10 K1=IW+1
CIW(1:IW)=C22(2:K1)
!-----add in the leading minus for negatives
if(v.lt.0.) then
ciw = '-'//ciw
endif
RETURN
C NOT POSSIBLE
11 CIW(1:IW)='********************'
RETURN
END
Terence
> "Terence" <tbwri...@cantv.net> wrote in message
>
> read more »
In my posted version there is a real typo in the testing program:
I had
DO I=1,20
and what got posted was
DO I=1L,20
Which error does not realy affect the subroutine but might affect the
testing.
I don't even see how it got compiled with a a loop variable name
starting with a digit.
My compiler won't take it. I also note missing and added letters in
other notes of mine in the past (other than real typos), form my local
copis.
Colin says FORMAT statement 901 should be changed to
E22.15
so I assume he means in the subroutine (not the 901 format in the test
program).
901 FORMAT(' V=',0PE16.9,' R=',A20)
But my compiler only does what I want if there is a leading 0P; the
rest of the change is, I suppose to show more digits of the texted
value, but there are only nine of them in the test sequences, so I put
9 for the precision and had 7 more field positions to cover sign, dot,
nine digits and 4 exponent characters plus one to end with a clean
blank.
I do not understand the refeence to an exponent of "95" causing a s
pecial case.
As for the rest of the variances, I find that Ccolin's listing
shows my result to correctly be rounded at the indicated point. Any
further digits are junk. And the quoted errors are beyond the rounding
position.
I don't know if the uncleared junk comes for my subroutine compiled
for a another system, but my own test results gave pure zeroes after
the rounding up to the length specified.
I would appreciate if Colin communicated privately to explain the
comments clearly enough for me. I do not doubt he must be assumed to
be correct but my tests in the exponent range -99 to 99 seemed to give
exact matches other than the required rounding, and with the
appropriate exponent sign and number.
Terence
>Colin says FORMAT statement 901 should be changed to
> E22.15
>so I assume he means in the subroutine (not the 901 format in the test
>program).
> 901 FORMAT(' V=',0PE16.9,' R=',A20)
>
>But my compiler only does what I want if there is a leading 0P; the
>rest of the change is, I suppose to show more digits of the texted
>value, but there are only nine of them in the test sequences, so I put
>9 for the precision and had 7 more field positions to cover sign, dot,
>nine digits and 4 exponent characters plus one to end with a clean
>blank.
>
> I do not understand the refeence to an exponent of "95" causing a
>special case.
>
I'm using a two digit mantissa (E8.2) just to get at the signed
exponent, which he says will will effect the exponent abovemani=tissas
of '.95' due to rounding to two digits, but with this field size the
exponent is not really affected until the mantissa is .995; however no
matter how many digits of mantissa are captured, there's always the
case of more nines, eg. .9999999x, with x a digit between 5 and 9 .
So yes, I should use a field size greater than the requested final
field size, (or the greatest supported field size), to cover the worst
case for that field size, in order to pick up the original exponent
before modifying it.
Ok, that takes care of |.99xesnn|.
Now there is a similar case around exponents of magnitude 999, when
the positive case can fall into a supportable range and the negative
case can move out of such.
The other points about difference of computations and representation I
still don't understand, mainly because the headings of the first table
columns are missing. One must be length, one must be the E-switch, but
I don't know what the first (-1) and fourth (7477) colulumns are for.
glen herrmannsfeldt
(snip, I wrote)
>>The ranges Terence gave are pretty common for 32 bit and 64 bit
>>binary floating point (even before IEEE).
> Er, no. Even on the VAX, they were only two of the options. Yes,
> they existed, but it's inaccurate to imply that they were common.
> Few general rules applied.
Well, I didn't say 'usual' this time.
With 32 bits, subtract one for sign, divide up the rest of the
bits between exponent and significand. The 1e-38 to 1e38 with
an eight bit biased exponent is about as small a range as one might
have and still call it floating point. It is also somewhat
convenient for software emulation (such as on 8 bit micros),
as one can add back the hidden one and process it bytewise.
For 64 bits, one could keep the eight bit exponent, as VAX did
with D-Float, but most would consider more exponent bits.
How many more? Adding three, as for VAX G-float, seems to
be a reasonably compromise between exponent and significand bits.
The IBM Hex floating point, uses a seven bit biased exponent
of 16 for all three lengths. The 1e-78 to 1e75 range is a little
small, but works well enough most of the time. It seems that
the Data General Eclipse also uses a similar Hex float form.
In specifying 32 bit and 64 bit binary, I excluded other word
sizes (36, 48, 60) and bases (8, 10, 16). Before IEEE many
such machines existed.
-- glen
Terence
(SNIP)
I corrected the format 901 and work area (C8 becomes CTT) to be able
to use F22.15 with a work field of 22, (as suggested by Colin Watters)
and adjusted the references within the new string. This solved the .
999x mantissa magnitude.
901
FORMAT(E22.15)
C HAVE s.vv..vvesdd OR
s.vv..vvsddd
IF (CTT(19:19).EQ.'E')
THEN
C HAVE
s.vv..vvesdd
READ(CTT(19:22),902)
IEA
902
FORMAT(1X,I3)
ELSE
C HAVE
s.vv..vvsddd
READ(CTT(19:22),903)
IEA
903
FORMAT(I4)
ENDIF
Then a 'snnn' new exponent write to C4 needed a test for blank
positive sign and its replacement with '+' to get the later texts and
compression to work. The blank was killing the 'E+' situation when the
exponent was '+100' and above.
IF (C4(1:1).EQ.' ') C4(1:1)='+'
Then finding a "+" sign as the first of a 4-charcter expont indicates
there is no 'E' or '+' to be removed.
That seems to solve all the problems so far, and extends the range of
use to near +999 to -999 (I have to check more, I think; I already am
checking 120 to -110 which should cover 'near' +999 to -999
exponents). That was two more lines to the subroutine and four index
changes.
I know that there is still a rare case result of .123456789E-08 which
needs special treatment to add one more digit of precision, for option
combinations that produce a final change to a potential -09 exponent
and therefore -9 with extra precision when '0' can be removed.
Colin Watters
I have tried to email you 3 times but keep getting bounced, as in:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
<email address snipped, but its tbwright at cantv dot net..>
SMTP error from remote mail server after RCPT TO:<snipped>:
host relay.cantv.net [200.44.32.36]: 550 5.7.1 <snipped>... Mail from
195.173.77.133 refused:
Vea http://abuso.cantv.net/bl/spam.html
...etc
Qolin
qolin at domain dot com
domain: qomputing
Colin Watters
> "Terence" <tbwr...@cantv.net> wrote in message
> news:ea57b359-a31b-4d69...@o11g2000prf.googlegroups.com...
OK then, can you post or email the latest source please? My email address
is below, make the obvious substitutions. I'll do a speed comparison with
my brute force stuff and let you know by what order of magnitude yours
beats mine!
BTW I noticed the 1L thing in the do-statement, I assumed it was a
compiler-specific way to specify the precision of an integer constant.
I agree the errors are rounding correctly, at least they are now, but
originally they were way out. I always try to get my code to find its own
errors, so much easier than doing it myself.
The headings in the table: first is the sign multiplier, the do-loop index
INEG; and the 7477 is IP, the number of times the inner loop cycles (I just
wanted some idea of how many numbers between 1e-90 and 1e+90 it was dealing
with).
robin
>In <4cd0a65d$0$22687$c30e...@exi-reader.telstra.net>, on 11/03/2010
> at 11:01 AM, "robin" <rob...@dodo.com.au> said:
>
>>If you want to get values back, you pass the original array, and also
>>do a DEFINED/iSUB in the called procedure.
>
>existing code, not what new code you could write for the subroutine.
You've got it wrong again. The issue was translating old FORTRAN code to PL/I.
That was one of the methods. I had already given an alternative method,
which was to pass the array directly. And, of course, an iSUB/DEFINED array can be passed
by creating/simulating the dummy in and out.
robin
>In <4cd01db0$0$22683$c30e...@exi-reader.telstra.net>, on 11/02/2010
> at 07:19 PM, "robin" <rob...@dodo.com.au> said:
>
>>It isn't irrelevant, because a DEFINED/iSUB array can be passed.
>
>
>>In each of two previous posts, you claimed/inferred that it could
>>not be ; and I corrected your mistake.
>
Here's another wrong claim that you made:
----start quote----
From: Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>
Newsgroups: comp.lang.fortran,comp.lang.pl1
Date: Thursday, 28 October 2010 22:01
Subject: Re: FORTRAN to PL/I
>In <4cc8b663$0$497$c30e...@exi-reader.telstra.net>, on 10/28/2010
> at 10:31 AM, "robin" <rob...@dodo.com.au> said:
>
>>Of course such an array can be passed!
>
>Not as CONNECTED.
------end of quote-----
> since you
>invented the cl;aims, the mistakes were yours.
Since I didn't invent the claims, the mistakes were YOURS.
robin
>In <4cd01db0$0$22683$c30e...@exi-reader.telstra.net>, on 11/02/2010
> at 07:19 PM, "robin" <rob...@dodo.com.au> said:
>
>
>
>>not be ; and I corrected your mistake.
>
Wrong again, It was YOU who made the claim. Here's one of them:
-------start quote-----
From: Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid>
Newsgroups: comp.lang.fortran,comp.lang.pl1
Date: Sunday, 31 October 2010 12:50
Subject: Re: FORTRAN to PL/I
>In <4ccae9a4$0$500$c30e...@exi-reader.telstra.net>, on 10/30/2010
> at 02:34 AM, "robin" <rob...@dodo.com.au> said:
>
>>As anything.
>
>No. The value can be passed, but not an array locator/descriptor.
-----end of quote-----
When a dummy array is created, its descriptor is passed.
Terence
> Terence
>
> I have tried to email you 3 times but keep getting bounced, as in:
>
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
> <email address snipped, but its tbwright at cantv dot net..>
>
> SMTP error from remote mail server after RCPT TO:<snipped>:
> host relay.cantv.net [200.44.32.36]: 550 5.7.1 <snipped>... Mail from
> 195.173.77.133 refused:
>
> ...etc
>
> Qolin
>
> qolin at domain dot com
> domain: qomputing
My public (Latin-American) e-mail server (to be able to check reieved
contents) is itself a source of SPAM, but they bitch about getting
any. Any server found to have emitted SPAM is struck of the acceptance
list until they grovel, ask forgiveness and promise it won't happen
again. The wole of Australia gets struck off about twice a year. Think
about it!
Since I live in Australia, I find I can't write to people in some
countries until the near-monopoly service here sends the many-time-
copied letter to get re-admission.
I'll give anybody who needs it the e-mail of my secret hide-out (that
is, once I find who needs it, whichever wy works...)
So Colin's server (195.173.77.133) is on the naughty list at the
moment.
I like Colin's idea of testing, by writing out my generated text
strings and then reading back, reconverting (using routine twice) and
then comparing, to list any differences.
I'll test that way.
I was wondering if a test value of mantissa +/- .9999999 (repeated to
required precision) would be a better test?
Colin Watters
...
>
> I like Colin's idea of testing, by writing out my generated text
> strings and then reading back, reconverting (using routine twice) and
> then comparing, to list any differences.
>
> I'll test that way.
> I was wondering if a test value of mantissa +/- .9999999 (repeated to
> required precision) would be a better test?
Testing algoritha such as this with known troublesome values is indeed
sensable. IMO the tests will indeed be "better" if such values are added to
the existing harness, but not if they replace it.
The objective of testing is usually to exercise the code over the range of
data it must deal with, which was the intention of my loop using small
incriments. Find a way to make it use .99999999 as well.
Are there any more troublesome mantissas I wonder? or exponents come to
that?
Incidentally the idea of the multiple calls to CMAXD is not to see if you
get the same answer, but to allow you to breakpoint on the line of code
after the IF that identifies a large error. Then you can step into the
subroutine, and follow it with the debugger to work out what is going
wrong. That's how I found all the bugs.
I'm interested to get your latest source to see if your changes fix all the
problems under my compiler, CVF. From your earlier postings I get the
impression you missed one or two of them.