Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
write negative numbers using parentheses
420 views
Skip to first unread message
Beliavsky
Oct 21, 2017, 9:44:15 PM10/21/17
to
Sometimes in finance and accounting, negative numbers are printed using parentheses instead of a negative sign, because the parentheses are harder to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did this. Would anyone else like this feature?
In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
Gary Scott
Oct 21, 2017, 10:18:25 PM10/21/17
to
On 10/21/2017 8:44 PM, Beliavsky wrote:
> Sometimes in finance and accounting, negative numbers are printed using parentheses instead of a negative sign, because the parentheses are harder to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did this. Would anyone else like this feature?
>
> In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
>
It would be handy for output, but input might be a bit messy??
> Sometimes in finance and accounting, negative numbers are printed using parentheses instead of a negative sign, because the parentheses are harder to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did this. Would anyone else like this feature?
>
> In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
>
Terence
Oct 22, 2017, 2:06:13 AM10/22/17
to
"Beliavsky" wrote
I dealt with this problem by writing a fairly general subroutine for my
library.
Subroutine EDIT was called as indicated by the code snippet:-
SUBROUTINE EDIT(VAL,LEN,NDEC,MAT,JCODE)
IMPLICIT INTEGER*2 (I-N)
C JCODE 1=* IF TOO SMALL, 2=ZERO AS 0.0, 4=negative as (val), 8=% AT END
REAL*4 VAL,VALR,F,FD(6)
CHARACTER MAT(1),CWRK(58)
VAL is the real variable to be printed in a field of LEN characters (3 to
58).
into the passed character string MAT, with NDEC decimals after the decimal
point,
edited by a bit-wise integer code JCODE, where JCODE could take values 1 to
15.
1 requests fill the field with '*' if the field if LEN is too small
2 requests zero to show as 1.0
4 requests showing negative values inside parentheses (VAL) instead of -VAL
8 requests a trailing "%" sign
Terence
herrman...@gmail.com
Oct 22, 2017, 3:53:32 AM10/22/17
to
On Saturday, October 21, 2017 at 6:44:15 PM UTC-7, Beliavsky wrote:
> Sometimes in finance and accounting, negative numbers
> are printed using parentheses instead of a negative sign,
> because the parentheses are harder to miss: (3.1) instead
> of -3.1. I wish there were Fortran formats that did this.
> Would anyone else like this feature?
It used to be that the IRS wanted this for tax forms,
> Sometimes in finance and accounting, negative numbers
> are printed using parentheses instead of a negative sign,
> because the parentheses are harder to miss: (3.1) instead
> of -3.1. I wish there were Fortran formats that did this.
> Would anyone else like this feature?
and maybe still does, but all the tax programs that I
know of, generate - signs.
If you use non-advancing I/O, it isn't hard to do sign
specific formats for each field.
if(x.lt.0) write(6,"('(',F6.2,')')",advance='no') x
if(x.ge.0) write(6,"(F7.2,1X)",advance='no') x
Does COBOL have a formatted output that does this?
Terence
Oct 22, 2017, 5:15:29 PM10/22/17
to
"Beliavsky" wrote
>Sometimes in finance and accounting, negative numbers are printed using
>parentheses instead of a negative sign, because the parentheses are harder
>to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did
>this. Would anyone else like this feature?
>In the absence of this feature, one can write a function that converts a
>real to a string and supply an argument to the function that tells it to
>use parentheses for negative numbers.
(Oops!)
>Sometimes in finance and accounting, negative numbers are printed using
>parentheses instead of a negative sign, because the parentheses are harder
>to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did
>this. Would anyone else like this feature?
>In the absence of this feature, one can write a function that converts a
>real to a string and supply an argument to the function that tells it to
>use parentheses for negative numbers.
I always did that, this way.
I dealt with this problem by writing a fairly general subroutine for my
library. Subroutine EDIT was called as indicated by the code snippet:-
SUBROUTINE EDIT(VAL,LEN,NDEC,MAT,JCODE)
IMPLICIT INTEGER*2 (I-N)
C JCODE 1=* IF TOO SMALL, 2=ZERO AS 0.0, 4=negative as (val), 8=% AT END
REAL*4 VAL,VALR,F,FD(6)
CHARACTER MAT(1),CWRK(58)
VAL is the real variable to be printed in a field of LEN characters (3 to
58).
into the passed character string MAT, with NDEC decimals after the decimal
point, edited by a bit-wise integer code JCODE, where JCODE could take
values 1 to 15.
1 requests fill the field with '*' if the field if LEN is too small
2 requests zero to show as 0.0 (zero, dot, zero!! )
I dealt with this problem by writing a fairly general subroutine for my
library. Subroutine EDIT was called as indicated by the code snippet:-
SUBROUTINE EDIT(VAL,LEN,NDEC,MAT,JCODE)
IMPLICIT INTEGER*2 (I-N)
C JCODE 1=* IF TOO SMALL, 2=ZERO AS 0.0, 4=negative as (val), 8=% AT END
REAL*4 VAL,VALR,F,FD(6)
CHARACTER MAT(1),CWRK(58)
VAL is the real variable to be printed in a field of LEN characters (3 to
58).
into the passed character string MAT, with NDEC decimals after the decimal
point, edited by a bit-wise integer code JCODE, where JCODE could take
values 1 to 15.
1 requests fill the field with '*' if the field if LEN is too small
Louis Krupp
Oct 22, 2017, 5:27:29 PM10/22/17
to
On Sun, 22 Oct 2017 00:53:30 -0700 (PDT), herrman...@gmail.com
wrote:
As far as I can tell, it doesn't.
Excel does, though.
Louis
wrote:
Excel does, though.
Louis
robin....@gmail.com
Oct 22, 2017, 11:05:52 PM10/22/17
to
robin....@gmail.com
Oct 22, 2017, 11:08:36 PM10/22/17
to
On Sunday, October 22, 2017 at 12:44:15 PM UTC+11, Beliavsky wrote:
> Sometimes in finance and accounting, negative numbers are printed using parentheses instead of a negative sign, because the parentheses are harder to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did this. Would anyone else like this feature?
>
> In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
Then write it. It isn't something that needs to be added to the language.
> Sometimes in finance and accounting, negative numbers are printed using parentheses instead of a negative sign, because the parentheses are harder to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did this. Would anyone else like this feature?
>
> In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
It's well within the capacity of Fortran to do.
robin....@gmail.com
Oct 22, 2017, 11:12:51 PM10/22/17
to
You need ABS(x).
Lynn McGuire
Oct 23, 2017, 1:39:53 PM10/23/17
to
On 10/21/2017 8:44 PM, Beliavsky wrote:
> Sometimes in finance and accounting, negative numbers are printed using parentheses instead of a negative sign, because the parentheses are harder to miss: (3.1) instead of -3.1. I wish there were Fortran formats that did this. Would anyone else like this feature?
>
> In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
In the past, I wrote my own print function that handled numeric prints
>
> In the absence of this feature, one can write a function that converts a real to a string and supply an argument to the function that tells it to use parentheses for negative numbers.
in the way that I liked to see them. Sadly, the function disappeared in
the 1980s while I was not looking.
In C++, I have written a polymorphic library function that allows me to
customize as necessary. I do not know if you can do something like this
in modern Fortran but if so, it might fit your needs.
std::string asString ();
std::string asString (void * val);
std::string asString (int val);
std::string asString (long val);
std::string asString (unsigned int val);
std::string asString (double val);
std::string asString (unsigned long val);
std::string asString (const char *val);
std::string asString (int val, const char * conversion);
std::string asString (long val, const char * conversion);
std::string asString (unsigned int val, const char * conversion);
std::string asString (unsigned long val, const char * conversion);
std::string asString (double val, const char * conversion);
Lynn
FortranFan
Oct 23, 2017, 4:08:27 PM10/23/17
to
On Saturday, October 21, 2017 at 9:44:15 PM UTC-4, Beliavsky wrote:
> .. I wish there were Fortran formats that did this. Would anyone else like this feature?
> ..
On Sunday, October 22, 2017 at 11:08:36 PM UTC-4, robin....@gmail.com wrote:
> .. It isn't something that needs to be added to the language. ..
@Beliasvky,
You ask, "Would anyone else like this feature?" I find @robin....@gmail.com's comment, "It isn't something that needs to be added to the language" entirely nonsensical. My own thought re: your inquiry is sure, why not? I don't see how it can "break" any existing facilities in the standard and I personally feel it is good to have more options for practitioners.
Moreover, I find with each standard revision some additional options provided with input/output facilities e.g., N2137 document toward the committee draft of Fortran 2015 standard has:
Input/output:
.. The G0.d edit descriptor can be used for list items of type Integer, Logical, and Character. The D, E, EN, and ES edit descriptors can have a field width of zero, analogous to the F edit descriptor. The exponent width e in a data edit descriptor can be zero, analogous to a field width of zero. Floating-point formatted input accepts hexadecimal-significand numbers that conform to ISO/IEC/IEEE 60559:2011. The EX edit descriptor provides hexadecimal-significand formatted output conforming to ISO/IEC/IEEE 60559:2011. ..
I don't know how and who made it possible to get these into Fortran 2015. You might figure that out with your researching skills. But it clearly shows Fortran language needn't remain *frozen* in terms of its IO facilities. So when Fortran 2020 finally rolls around, perhaps there will be an item corresponding to your interest expressed in this thread too, why not!?
Hopefully you can find a way to propose to J3 Fortran group a feature request and see how it goes.
> .. I wish there were Fortran formats that did this. Would anyone else like this feature?
> ..
On Sunday, October 22, 2017 at 11:08:36 PM UTC-4, robin....@gmail.com wrote:
> .. It isn't something that needs to be added to the language. ..
@Beliasvky,
You ask, "Would anyone else like this feature?" I find @robin....@gmail.com's comment, "It isn't something that needs to be added to the language" entirely nonsensical. My own thought re: your inquiry is sure, why not? I don't see how it can "break" any existing facilities in the standard and I personally feel it is good to have more options for practitioners.
Moreover, I find with each standard revision some additional options provided with input/output facilities e.g., N2137 document toward the committee draft of Fortran 2015 standard has:
Input/output:
.. The G0.d edit descriptor can be used for list items of type Integer, Logical, and Character. The D, E, EN, and ES edit descriptors can have a field width of zero, analogous to the F edit descriptor. The exponent width e in a data edit descriptor can be zero, analogous to a field width of zero. Floating-point formatted input accepts hexadecimal-significand numbers that conform to ISO/IEC/IEEE 60559:2011. The EX edit descriptor provides hexadecimal-significand formatted output conforming to ISO/IEC/IEEE 60559:2011. ..
I don't know how and who made it possible to get these into Fortran 2015. You might figure that out with your researching skills. But it clearly shows Fortran language needn't remain *frozen* in terms of its IO facilities. So when Fortran 2020 finally rolls around, perhaps there will be an item corresponding to your interest expressed in this thread too, why not!?
Hopefully you can find a way to propose to J3 Fortran group a feature request and see how it goes.
herrman...@gmail.com
Oct 24, 2017, 1:04:49 AM10/24/17
to
On Monday, October 23, 2017 at 1:08:27 PM UTC-7, FortranFan wrote:
(snip)
compiler writers, but also in people having to learn how
to use (or not use) it.
> Moreover, I find with each standard revision some additional
> options provided with input/output facilities e.g.,
> N2137 document toward the committee draft of
> Fortran 2015 standard has:
(snip)
> I don't know how and who made it possible to get these
> into Fortran 2015. You might figure that out with your
> researching skills. But it clearly shows Fortran
> language needn't remain *frozen* in terms of its IO
> facilities.
Note that the above comments are unrelated to the actual
desirability of the feature(s) mentioned. Just that there
is a cost/benefit relationship that needs to be considered.
(snip)
> You ask, "Would anyone else like this feature?"
> I find @robin....@gmail.com's comment, "It isn't something
> that needs to be added to the language" entirely nonsensical.
> My own thought re: your inquiry is sure, why not?
> I don't see how it can "break" any existing facilities in
> the standard and I personally feel it is good to have
> more options for practitioners.
No. Every feature has a cost, maybe just in the work of
> I find @robin....@gmail.com's comment, "It isn't something
> that needs to be added to the language" entirely nonsensical.
> My own thought re: your inquiry is sure, why not?
> I don't see how it can "break" any existing facilities in
> the standard and I personally feel it is good to have
> more options for practitioners.
compiler writers, but also in people having to learn how
to use (or not use) it.
> Moreover, I find with each standard revision some additional
> options provided with input/output facilities e.g.,
> N2137 document toward the committee draft of
> Fortran 2015 standard has:
> I don't know how and who made it possible to get these
> into Fortran 2015. You might figure that out with your
> researching skills. But it clearly shows Fortran
> language needn't remain *frozen* in terms of its IO
> facilities.
desirability of the feature(s) mentioned. Just that there
is a cost/benefit relationship that needs to be considered.
Arjen Markus
Oct 24, 2017, 2:37:38 AM10/24/17
to
On Tuesday, October 24, 2017 at 7:04:49 AM UTC+2, herrman...@gmail.com wrote:
>
> Note that the above comments are unrelated to the actual
> desirability of the feature(s) mentioned. Just that there
> is a cost/benefit relationship that needs to be considered.
>
Indeed, it is easier to create a small library to deal with such formatting. The output part of such a library ought to be easy enough, perhaps even via the UDDTIO facility. The input part will take a bit more work, proper parsing is always difficult, but I doubt financial applications will also deal with complex numbers, so I deem confusion unlikely.
>
> Note that the above comments are unrelated to the actual
> desirability of the feature(s) mentioned. Just that there
> is a cost/benefit relationship that needs to be considered.
>
Putting such a feature in a library rather than in the language itself also makes it easier to deal with unexpected interactions: a language feature has to be foolproof, as it is always present, whereas a library is used only when you need it.
Regards,
Arjen
robin....@gmail.com
Oct 24, 2017, 2:51:50 AM10/24/17
to
On Tuesday, October 24, 2017 at 7:08:27 AM UTC+11, FortranFan wrote:
> On Saturday, October 21, 2017 at 9:44:15 PM UTC-4, Beliavsky wrote:
>
> > .. I wish there were Fortran formats that did this. Would anyone else like this feature?
> > ..
>
> On Saturday, October 21, 2017 at 9:44:15 PM UTC-4, Beliavsky wrote:
>
> > .. I wish there were Fortran formats that did this. Would anyone else like this feature?
> > ..
>
> @Beliasvky,
>
> You ask, "Would anyone else like this feature?"
> I find @r....@gmail.com's comment, "It isn't something that needs
>
> You ask, "Would anyone else like this feature?"
> to be added to the language" entirely nonsensical.
I do not agree.
It is trivial to write out the parentheses for negative values
using existing facilities.
Ian Harvey
Oct 24, 2017, 4:31:44 AM10/24/17
to
On 24/10/2017 3:09 AM, Lynn McGuire wrote:
...
pointers to objects of class type. None of the above functions take
such an argument.
The functions above simply overload the name asString.
User defined overloading has been available since Fortran 90, via
generic interfaces.
...
> In C++, I have written a polymorphic library function that allows me to
> customize as necessary. I do not know if you can do something like this
> in modern Fortran but if so, it might fit your needs.
>
> std::string asString ();
> std::string asString (void * val);
> std::string asString (int val);
> std::string asString (long val);
> std::string asString (unsigned int val);
> std::string asString (double val);
> std::string asString (unsigned long val);
> std::string asString (const char *val);
> std::string asString (int val, const char * conversion);
> std::string asString (long val, const char * conversion);
> std::string asString (unsigned int val, const char * conversion);
> std::string asString (unsigned long val, const char * conversion);
> std::string asString (double val, const char * conversion);
Runtime polymorphism in C++ is accessed in source through references and
> customize as necessary. I do not know if you can do something like this
> in modern Fortran but if so, it might fit your needs.
>
> std::string asString ();
> std::string asString (void * val);
> std::string asString (int val);
> std::string asString (long val);
> std::string asString (unsigned int val);
> std::string asString (double val);
> std::string asString (unsigned long val);
> std::string asString (const char *val);
> std::string asString (int val, const char * conversion);
> std::string asString (long val, const char * conversion);
> std::string asString (unsigned int val, const char * conversion);
> std::string asString (unsigned long val, const char * conversion);
> std::string asString (double val, const char * conversion);
pointers to objects of class type. None of the above functions take
such an argument.
The functions above simply overload the name asString.
User defined overloading has been available since Fortran 90, via
generic interfaces.
FortranFan
Oct 24, 2017, 9:50:54 AM10/24/17
to
On Tuesday, October 24, 2017 at 1:04:49 AM UTC-4, herrman...@gmail.com wrote:
> ..
Why don't you present to OP and to forum readers here of your cost-benefit analysis of the feature requested in this thread by OP and also include as reference the cost-benefit analyses used by the standards committee of each and every item included in, say, the last 2 standard revisions, Fortran 2008 and 2015. OP might then realize writing the function is a better option, or not!
> ..
>
> No. Every feature has a cost, maybe just in the work of
> compiler writers, but also in people having to learn how
> to use (or not use) it.
> ..
> No. Every feature has a cost, maybe just in the work of
> compiler writers, but also in people having to learn how
> to use (or not use) it.
>
> Note that the above comments are unrelated to the actual
> desirability of the feature(s) mentioned. Just that there
> is a cost/benefit relationship that needs to be considered.
>
@Glen,
> Note that the above comments are unrelated to the actual
> desirability of the feature(s) mentioned. Just that there
> is a cost/benefit relationship that needs to be considered.
>
Why don't you present to OP and to forum readers here of your cost-benefit analysis of the feature requested in this thread by OP and also include as reference the cost-benefit analyses used by the standards committee of each and every item included in, say, the last 2 standard revisions, Fortran 2008 and 2015. OP might then realize writing the function is a better option, or not!
FortranFan
Oct 24, 2017, 10:02:38 AM10/24/17
to
On Tuesday, October 24, 2017 at 2:37:38 AM UTC-4, Arjen Markus wrote:
> ..
> Indeed, it is easier to create a small library to deal with such formatting. ..
>
> Putting such a feature in a library rather than in the language itself also makes it easier to deal with unexpected interactions: a language feature has to be foolproof, as it is always present, whereas a library is used only when you need it. ..
I disagree entirely with Arjen Markus' view.
My own view is facilities that are close to the aspects the language has long considered part of its domain are better handled in the language standard itself rather than shunted off to a library. Fortran from its very roots has included IO and formatting facilities and it has a bunch of things like DC and DP editing and BN/BZ, RU thru' RP, kP, SS/SP editing that are all, in my opinion. similar to what OP seeks here. There are obvious benefits with having standard facilities. Under the circumstances, it is a legitimate request and it should be given a consideration by the committee.
> ..
> Indeed, it is easier to create a small library to deal with such formatting. ..
>
> Putting such a feature in a library rather than in the language itself also makes it easier to deal with unexpected interactions: a language feature has to be foolproof, as it is always present, whereas a library is used only when you need it. ..
I disagree entirely with Arjen Markus' view.
My own view is facilities that are close to the aspects the language has long considered part of its domain are better handled in the language standard itself rather than shunted off to a library. Fortran from its very roots has included IO and formatting facilities and it has a bunch of things like DC and DP editing and BN/BZ, RU thru' RP, kP, SS/SP editing that are all, in my opinion. similar to what OP seeks here. There are obvious benefits with having standard facilities. Under the circumstances, it is a legitimate request and it should be given a consideration by the committee.
herrman...@gmail.com
Oct 24, 2017, 2:28:06 PM10/24/17
to
On Tuesday, October 24, 2017 at 6:50:54 AM UTC-7, FortranFan wrote:
(snip)
> @Glen,
> Why don't you present to OP and to forum readers here of
> your cost-benefit analysis of the feature requested in
> this thread by OP and also include as reference the
> cost-benefit analyses used by the standards committee
> of each and every item included in, say, the last
> 2 standard revisions, Fortran 2008 and 2015.
> OP might then realize writing the function is a
> better option, or not!
I wasn't suggesting in that post that I had an idea of
the cost-benefit, only that the cost was greater than zero.
In a previous post, I asked if COBOL, a language commonly
used for business/financial reports had this feature, and
someone noted that it didn't.
(snip)
> @Glen,
> Why don't you present to OP and to forum readers here of
> your cost-benefit analysis of the feature requested in
> this thread by OP and also include as reference the
> cost-benefit analyses used by the standards committee
> of each and every item included in, say, the last
> 2 standard revisions, Fortran 2008 and 2015.
> OP might then realize writing the function is a
> better option, or not!
the cost-benefit, only that the cost was greater than zero.
In a previous post, I asked if COBOL, a language commonly
used for business/financial reports had this feature, and
someone noted that it didn't.
herrman...@gmail.com
Oct 24, 2017, 2:40:09 PM10/24/17
to
PL/I has a P (picture) format descriptor that allows one to
specify in much more detail how one wants data formatted.
P allows for commas to be specified, printing of a desired
number of leading zeros, floating dollar signs, and trailing
DB or CR (debit or credit) on negative values. It also allows
for the positioning of the decimal point separate from the
printed decimal point, if any.
It is describe somewhat better than I can say it in:
http://bitsavers.org/pdf/ibm/360/pli/SC20-1651-1_A_Guide_to_PL_I_for_Commercial_Programmers_Apr68.pdf
I suspect that this came from a related COBOL feature, and
so should be well understood. It seems like parentheses aren't
a feature included, but it wouldn't be hard to add them.
This is much more general, though, and should be useful to
others, including for non-financial I/O.
As above, it allows specifying leading zeros, a feature someone
else was recently asking about.
This being more general, it should also have more benefit,
and maybe not so much more cost.
Lynn McGuire
Oct 24, 2017, 3:06:24 PM10/24/17
to
Thanks,
Lynn
robin....@gmail.com
Oct 24, 2017, 9:07:52 PM10/24/17
to
On Wednesday, October 25, 2017 at 5:40:09 AM UTC+11, herrman...@gmail.com wrote:
> PL/I has a P (picture) format descriptor that allows one to
> specify in much more detail how one wants data formatted.
>
> P allows for commas to be specified, printing of a desired
> number of leading zeros, floating dollar signs, and trailing
> DB or CR (debit or credit) on negative values. It also allows
> for the positioning of the decimal point separate from the
> printed decimal point, if any.
That's because PL/I is a general-purpose language,
> PL/I has a P (picture) format descriptor that allows one to
> specify in much more detail how one wants data formatted.
>
> P allows for commas to be specified, printing of a desired
> number of leading zeros, floating dollar signs, and trailing
> DB or CR (debit or credit) on negative values. It also allows
> for the positioning of the decimal point separate from the
> printed decimal point, if any.
designed for both scientific and commercial data processing ;
Fortran isn't.
Gary Scott
Oct 25, 2017, 9:01:16 AM10/25/17
to
On 10/24/2017 8:07 PM, robin....@gmail.com wrote:
> On Wednesday, October 25, 2017 at 5:40:09 AM UTC+11, herrman...@gmail.com wrote:
>> PL/I has a P (picture) format descriptor that allows one to
>> specify in much more detail how one wants data formatted.
>>
>> P allows for commas to be specified, printing of a desired
>> number of leading zeros, floating dollar signs, and trailing
>> DB or CR (debit or credit) on negative values. It also allows
>> for the positioning of the decimal point separate from the
>> printed decimal point, if any.
>
> That's because PL/I is a general-purpose language,
> designed for both scientific and commercial data processing ;
> Fortran isn't.
Is so...:P
> On Wednesday, October 25, 2017 at 5:40:09 AM UTC+11, herrman...@gmail.com wrote:
>> PL/I has a P (picture) format descriptor that allows one to
>> specify in much more detail how one wants data formatted.
>>
>> P allows for commas to be specified, printing of a desired
>> number of leading zeros, floating dollar signs, and trailing
>> DB or CR (debit or credit) on negative values. It also allows
>> for the positioning of the decimal point separate from the
>> printed decimal point, if any.
>
> That's because PL/I is a general-purpose language,
> designed for both scientific and commercial data processing ;
> Fortran isn't.
robin....@gmail.com
Oct 25, 2017, 11:01:45 PM10/25/17
to
On Thursday, October 26, 2017 at 12:01:16 AM UTC+11, Gary Scott wrote:
Whatever you say.
But the fact is that Fortran was not designed for commercial data processing.
It does not have the decimal arithmetic facilities needed for commercial work.
But the fact is that Fortran was not designed for commercial data processing.
It does not have the decimal arithmetic facilities needed for commercial work.
herrman...@gmail.com
Oct 25, 2017, 11:28:35 PM10/25/17
to
On Wednesday, October 25, 2017 at 8:01:45 PM UTC-7, robin....@gmail.com wrote:
(snip)
> Whatever you say.
> But the fact is that Fortran was not designed for commercial
> data processing.
> It does not have the decimal arithmetic facilities needed for
> commercial work.
Some decimal arithmetic does make it easier, but not that much.
The Picture format allows one to print values with the decimal
point shifted from the stored position. Once can do arithmetic
in cents, and print values in dollars and cents.
Mostly decimal is convenient when you do minimal arithmetic
between input and output, such that the conversion to/from
binary takes longer than the operation. But on processors now,
it doesn't take all that long, anyway.
Picture format is convenient for other uses.
Allowing commas is sometimes nice, even for non-commercial
uses.
(snip)
> Whatever you say.
> But the fact is that Fortran was not designed for commercial
> data processing.
> It does not have the decimal arithmetic facilities needed for
> commercial work.
The Picture format allows one to print values with the decimal
point shifted from the stored position. Once can do arithmetic
in cents, and print values in dollars and cents.
Mostly decimal is convenient when you do minimal arithmetic
between input and output, such that the conversion to/from
binary takes longer than the operation. But on processors now,
it doesn't take all that long, anyway.
Picture format is convenient for other uses.
Allowing commas is sometimes nice, even for non-commercial
uses.
robin....@gmail.com
Oct 26, 2017, 1:29:05 AM10/26/17
to
On Thursday, October 26, 2017 at 2:28:35 PM UTC+11, herrman...@gmail.com wrote:
> On Wednesday, October 25, 2017 at 8:01:45 PM UTC-7, robin....@gmail.com wrote:
>
> (snip)
>
> > Whatever you say.
>
> > But the fact is that Fortran was not designed for commercial
> > data processing.
> > It does not have the decimal arithmetic facilities needed for
> > commercial work.
>
> Some decimal arithmetic does make it easier, but not that much.
Try telling that to s commercial programmer.
> On Wednesday, October 25, 2017 at 8:01:45 PM UTC-7, robin....@gmail.com wrote:
>
> (snip)
>
> > Whatever you say.
>
> > But the fact is that Fortran was not designed for commercial
> > data processing.
> > It does not have the decimal arithmetic facilities needed for
> > commercial work.
>
> Some decimal arithmetic does make it easier, but not that much.
Mostly their work is in decimal arithmetic.
> The Picture format allows one to print values with the decimal
> point shifted from the stored position. Once can do arithmetic
> in cents, and print values in dollars and cents.
including drifting currency symbol, zero supression,
forcing leading zero, decimal point suppression or not,
substitute comma, CR and DB for negative values.
> Mostly decimal is convenient when you do minimal arithmetic
> between input and output, such that the conversion to/from
> binary takes longer than the operation.
If minimal arithmetic is used, a picture data type ic convenient.
> But on processors now,
> it doesn't take all that long, anyway.
>
> Picture format is convenient for other uses.
> Allowing commas is sometimes nice, even for non-commercial
> uses.
and PL/I's picture formats allow this to be done conveniently.
Gary Scott
Oct 26, 2017, 8:01:19 AM10/26/17
to
Arjen Markus
Oct 30, 2017, 9:36:15 AM10/30/17
to
Regards,
Arjen
FortranFan
Oct 30, 2017, 10:01:45 AM10/30/17
to
On Monday, October 30, 2017 at 9:36:15 AM UTC-4, Arjen Markus wrote:
> ..
> ..
> Fortran does allow that as well - using the DECIMAL= keyword for the OPEN statement or the DC DP control edit descriptors.
> ..
That's exactly what I was suggesting with my post upthread:
https://groups.google.com/d/msg/comp.lang.fortran/IGdLIaGjEKI/oZGlNYggBQAJ
Considering what the standard already provides with DC and DP editing and BN/BZ, RU thru' RP, kP, SS/SP editing, enhancing the edit descriptor facilities for what the OP mentioned should be a natural extension and very much worthy of a strong consideration by the standards committee.
robin....@gmail.com
Oct 30, 2017, 8:25:58 PM10/30/17
to
On Tuesday, October 31, 2017 at 12:36:15 AM UTC+11, Arjen Markus wrote:
> On Thursday, October 26, 2017 at 7:29:05 AM UTC+2, r....@gmail.com wrote:
However, PL/I allows the commas/periods to be selectively used
in format specifications, with multiple commas (or periods)
conveiently placed in large values such as 123,456,789.12
> On Thursday, October 26, 2017 at 7:29:05 AM UTC+2, r....@gmail.com wrote:
> > On Thursday, October 26, 2017 at 2:28:35 PM UTC+11, h....@gmail.com wrote:
>
> >
> > > Allowing commas is sometimes nice, even for non-commercial
> > > uses.
> >
> > The role of commas and periods is reversed in European countries,
> > and PL/I's picture formats allow this to be done conveniently.
>
> Fortran does allow that as well - using the DECIMAL= keyword for the OPEN statement or the DC DP control edit descriptors.
I'm aware of that.
>
> >
> > > Allowing commas is sometimes nice, even for non-commercial
> > > uses.
> >
> > The role of commas and periods is reversed in European countries,
> > and PL/I's picture formats allow this to be done conveniently.
>
> Fortran does allow that as well - using the DECIMAL= keyword for the OPEN statement or the DC DP control edit descriptors.
However, PL/I allows the commas/periods to be selectively used
in format specifications, with multiple commas (or periods)
conveiently placed in large values such as 123,456,789.12
robin....@gmail.com
Oct 30, 2017, 9:13:31 PM10/30/17
to
On Tuesday, October 31, 2017 at 12:36:15 AM UTC+11, Arjen Markus wrote:
> On Thursday, October 26, 2017 at 7:29:05 AM UTC+2, r.....@gmail.com wrote:
are provided in PL/I.
In addition to the comma and period, the slash and blank can be inserted,
to produce such outputs as:
123,456,789.98
123 456 789.98
31/10/2017
2017/10/31
2017 10 31
> On Thursday, October 26, 2017 at 7:29:05 AM UTC+2, r.....@gmail.com wrote:
> > On Thursday, October 26, 2017 at 2:28:35 PM UTC+11, h.....@gmail.com wrote:
>
> >
> > > Allowing commas is sometimes nice, even for non-commercial
> > > uses.
> >
> > The role of commas and periods is reversed in European countries,
> > and PL/I's picture formats allow this to be done conveniently.
>
> Fortran does allow that as well - using the DECIMAL= keyword for the OPEN statement or the DC DP control edit descriptors.
I should perhaps have mentioned also that other insertion characters
>
> >
> > > Allowing commas is sometimes nice, even for non-commercial
> > > uses.
> >
> > The role of commas and periods is reversed in European countries,
> > and PL/I's picture formats allow this to be done conveniently.
>
> Fortran does allow that as well - using the DECIMAL= keyword for the OPEN statement or the DC DP control edit descriptors.
are provided in PL/I.
In addition to the comma and period, the slash and blank can be inserted,
to produce such outputs as:
123,456,789.98
123 456 789.98
31/10/2017
2017/10/31
2017 10 31
khb
Nov 29, 2017, 2:00:36 PM11/29/17
to
Prime (back in the day) had a "business editing" format (B) which offered a "PIC" like syntax, and used CR to indicate a negative number (I don't recall it using parens). People have written emulation logic (Promula, for example, as part of the runtime for their multi-Fortran dialect to C product ... again, back in the day).
herrman...@gmail.com
Nov 30, 2017, 5:13:58 AM11/30/17
to
inherited from COBOL.
As someone noted earlier, COBOL doesn't have the parentheses
for negative numbers.
The US tax software that I know of puts in - signs, even
though the traditional IRS form is parentheses.
robin....@gmail.com
Nov 30, 2017, 9:41:15 AM11/30/17
to
specifically to put in CR or DB -- or even a trailing minus --
for negative values. [among other things, of course]
0 new messages