Home > Archive > Fortran > July 2007 > Unsigned Integers and Fortran
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Unsigned Integers and Fortran
|
|
| analyst41@hotmail.com 2007-06-20, 10:06 pm |
| >From what I understand from the simulation expert, he was able to
generate pseudo-random numbers very efficiently in C, using unsigned
integers.
(1) There must have been some issues connected with introducing
unsigned ints as a native data type into Fortran - would the experts
please spell out what they are ?
(2) Using N bits, we have -2**(N-1) <= representable integers <=
2**(N-1) - 1.
If we add the constant 2**(N-1) to the set of representable integers
we get the set of representable unsigned ints
0 <= representable unsigned
ints <= 2**N - 1.
I think that this fact should let us define unsigned ints efficiently
as a derived data type.
| |
|
|
| glen herrmannsfeldt 2007-06-21, 10:05 pm |
| analyst41@hotmail.com wrote:
> generate pseudo-random numbers very efficiently in C, using unsigned
> integers.
The use of unsigned integers isn't so important, but the ability
to multiply two integers and generate a double length product
is important. Some compilers will generate three multiply instructions,
or even a subroutine call, for the required multiplication.
The primary need for unsigned in C is for known properties
in the case of overflow. C, like Fortran, makes no guarantee
on the results for signed integer overflow, but C does require
that unsigned arithmetic give the modulo 2**N result for
unsigned overflow.
-- glen
| |
| Ron Shepard 2007-06-21, 10:05 pm |
| In article <ldmdnbU9Iec5b-TbnZ2dnUVZ_oavnZ2d@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> The primary need for unsigned in C is for known properties
> in the case of overflow. C, like Fortran, makes no guarantee
> on the results for signed integer overflow, but C does require
> that unsigned arithmetic give the modulo 2**N result for
> unsigned overflow.
Yes, but if I remember correctly, the N in your expression is not
necessarily the number of bits in the representation. Most machines
have the appropriate hardware and do implement it that way, but it
is not required by the C standard. I would expect if an unsigned
integer type were added to fortran, it would be with the same
conditions, and that there would be intrinsic inquiry functions to
verify how the wrapping would occur.
$.02 -Ron Shepard
| |
| Dick Hendrickson 2007-06-21, 10:05 pm |
| analyst41@hotmail.com wrote:
> generate pseudo-random numbers very efficiently in C, using unsigned
> integers.
>
> (1) There must have been some issues connected with introducing
> unsigned ints as a native data type into Fortran - would the experts
> please spell out what they are ?
>
Since the experts seem to be busy, I'll take a swing at this.
It's always hard to say why something wasn't done, (other than
nobody wanted to do it). But, here's a couple of guesses.
1) Historically, FORTRAN was designed to map very efficiently onto the
existing machines. In the old days, machines didn't detect integer
overflow at all. There was essentially no hardware support for any
of the hard unsigned integer cases. (That's still true, as the thread
about i+j overflow shows). In the early days, integers were used for
subscripts and for counting things. Unsigned wasn't needed for either.
2) Since then, nobody has "seriously" asked for them. Just saying
"why don't you guys go do some extra work" isn't a "serious enough"
request. There can be several reasons for this. Maybe nobody
really wants them. Maybe the people who do figure that J3 will
never do it, so why waste everybody's time on something that will
be ignored. Maybe some vendors think they have a competitive
advantage with a feature that other vendors don't have.
3) It's hard to figure out what should happen on one's and two's
complement machines, as well as on signed magnitude ones (and maybe
also on machines that pass (some) integer arithmetic through the
floating point hardware. If you look at the BIT model in Fortran 2003
it essentially says the model is processor dependent if the sign bit is
set.
4) It's hard to know what the right or expected thing is if you do
mixed mode (signed and unsigned) arithmetic. Which type coerces to
the other type? Is it forbidden? What about COMMON/EQUIVALENCE? Or
argument association? It's not that you can't come up with answers
to these questions. It's that not everybody has the same expectations
or needs.
5) (I'm not trying to be stupid or pick a fight here.) It's been
my understanding that the most common historical idiomatic use of
unsigned integers in C has been for 8 bit "characters". If this
is right, then (IMO) the Fortran character type solution is much
better and there's no need for unsigned integers.
That's my set of guesses. I'm pretty sure about 1 and 2. The
rest is speculation.
| |
| Richard Maine 2007-06-21, 10:05 pm |
| Dick Hendrickson <dick.hendrickson@att.net> wrote:
> analyst41@hotmail.com wrote:
>
> Since the experts seem to be busy, I'll take a swing at this.
I'll throw in a few things, some of them partially overlapping with
Dick's, but from a slightly different different viewpoint.
I'll focus on the questions of why anyone would want such a thing.
Answers I've seen are
1. Just because C does. Well, not until f2003 was C interop an explicit
goal of the standard. One might happen to think that a bit late (I do),
but that's a different matter. Adding unsigned just for C interop would
have been a pretty big thing to bite off. It was proposed, but it would
have been pretty big. The adopted approach is perhaps less convenient at
times, but is hugely simpler in terms of the language - and in many
uses, it isn't even less convenient.
2. To squeeze one more bit of range out of something. Maybe you want to
be able to use numbers larger than (approx) 2 billion, but 4 billion is
enough. Or the same issues with smaller sizes - 255 is plenty, but 127
isn't. I actually think this is the most common reason... other than the
C interop one. But that puts it in a pretty small nich of good
application areas. And what happens when the requirement grows just a
hair more and now you need something with 1 more bit?
3. Points made previously in this thread about things that shouldn't be
negative, so it might be nice to have the compiler catch them. These all
seem to me to be just special cases of subranges. I don't see that doing
unsigned is the "right" way to address that. If one wants subranges, one
should do subranges in general rather than one specific case and that
case only. There are arguments for doing subranges; they have certainly
been proposed. But that's a different proposal. If one is really after
subranges, then unsigned does only one specific case and is not
plausibly extendable to cover other cases. You'd have to throw it out
and start over again to do the more general case. That's not a very good
selling point for unsigned if that is the objective.
4. Some/most hardware can do it, so Fortran ought to take advantage of
that hardware for efficiency and simplicity. I'd categorize the OP's
interest as in this direction. I know he didn't state it that way, and
perhaps he'd disagree with my categorization, but that's how I see it.
The problem with this, from a standard perspective, is that it is too
strongly dependent on particular hardware issues. If you require that
things work just like on a particular piece of hardware, then you can
make things pretty bad on other hardware - severely hurting instead of
helping performance and simplicity. This is a special case of a major
general issue with standardization - you have to decide how much to
cater to particular hardware features. Obviously you have to pay some
attention to hardware, or one ends up with a language that is useless in
practice. But pay too muuch attention to particular hardware features
and you end up with a language that has portability issues.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2007-06-21, 10:05 pm |
| Richard Maine <nospam@see.signature> wrote:
> 3. Points made previously in this thread...
....
> I'd categorize the OP's interest...
My above mentions of "this thread" and the "OP" were referring to the
other recent/ongoing thread where questions about unsigned came up. I
failed to notice that this was a separate thread (and I didn't even see
the OP's post in this thread, except for the brief part that Dick
quoted.)
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2007-06-21, 10:06 pm |
| Ron Shepard wrote:
(I wrote)
[color=darkred]
> Yes, but if I remember correctly, the N in your expression is not
> necessarily the number of bits in the representation. Most machines
> have the appropriate hardware and do implement it that way, but it
> is not required by the C standard. I would expect if an unsigned
> integer type were added to fortran, it would be with the same
> conditions, and that there would be intrinsic inquiry functions to
> verify how the wrapping would occur.
Yes, there is the possible use of padding bits, bits other
than value bits and (for signed types) a sign bit.
http://en.wikipedia.org/wiki/Stdint.h
http://c0x.coding-guidelines.com/6.2.6.2.html
With the small number of machines where it matters, and the different
versions of the C standard, it is hard to say much more.
As far as I can tell, (unsigned char) never has padding bits, and
other unsigned types should have the same number of padding bits
as the corresponding signed types.
C99 defines some new types (or typedefs) that, if supported, have a
known width and no padding bits. Appropriate for this discussion are
int32_t, uint32_t, int64_t, and uint64_t, which are signed and unsigned
32 bit integers, and signed and unsigned 64 bit integers.
-- glen
| |
| glen herrmannsfeldt 2007-06-21, 10:06 pm |
| Dick Hendrickson wrote:
(snip)
> 1) Historically, FORTRAN was designed to map very efficiently onto the
> existing machines. In the old days, machines didn't detect integer
> overflow at all. There was essentially no hardware support for any
> of the hard unsigned integer cases. (That's still true, as the thread
> about i+j overflow shows). In the early days, integers were used for
> subscripts and for counting things. Unsigned wasn't needed for either.
In the early days subscripts had to be positive, and so did the
values of DO loops. It seems that the index registers of the 704
were unsigned. (As I understand it, they always decrement and
arrays on the 704 are stored in decreasing order in memory.)
(snip)
> 3) It's hard to figure out what should happen on one's and two's
> complement machines, as well as on signed magnitude ones (and maybe
> also on machines that pass (some) integer arithmetic through the
> floating point hardware. If you look at the BIT model in Fortran 2003
> it essentially says the model is processor dependent if the sign bit is
> set.
It says that for the C standard for signed types, too. Even for the
twos complement value with the sign bit set and all value bits zero.
(snip)
> 5) (I'm not trying to be stupid or pick a fight here.) It's been
> my understanding that the most common historical idiomatic use of
> unsigned integers in C has been for 8 bit "characters". If this
> is right, then (IMO) the Fortran character type solution is much
> better and there's no need for unsigned integers.
Well, (unsigned char) is a special type in C, with rules that don't
apply to any other type. In addition, Java has only one unsigned
type, the 16 bit char. It doesn't seem that it is missed much
for Java.
C requires all characters in the normal character set to have
positive values. For ASCII-7 this allows for either signed
or unsigned char if char is eight bits, for EBCDIC and eight
bit char, it only allows for unsigned.
-- glen
| |
| glen herrmannsfeldt 2007-06-21, 10:06 pm |
| Richard Maine wrote:
(snip discussion on unsigned integer types)
> I'll focus on the questions of why anyone would want such a thing.
> Answers I've seen are
> 1. Just because C does. Well, not until f2003 was C interop an explicit
> goal of the standard. One might happen to think that a bit late (I do),
> but that's a different matter. Adding unsigned just for C interop would
> have been a pretty big thing to bite off. It was proposed, but it would
> have been pretty big. The adopted approach is perhaps less convenient at
> times, but is hugely simpler in terms of the language - and in many
> uses, it isn't even less convenient.
For those (rare) cases where it is needed, with C interop one can
always call a C routine to do it. Also, it complicates the description
and use of bit manipulation functions. In most cases, one can assume
that all representations are allowed and use all the bits, but the
standard doesn't require that.
> 2. To squeeze one more bit of range out of something. Maybe you want to
> be able to use numbers larger than (approx) 2 billion, but 4 billion is
> enough. Or the same issues with smaller sizes - 255 is plenty, but 127
> isn't. I actually think this is the most common reason... other than the
> C interop one. But that puts it in a pretty small nich of good
> application areas. And what happens when the requirement grows just a
> hair more and now you need something with 1 more bit?
Small, but there are important cases. For 32 bit processors with 32
bit addressing, it allows for addressing half the address space.
The result of getting this wrong in early C implementations has caused
many problems. I have had programs that won't run on machines with
more than 2GB of available memory, claiming that not enough memory
is available. (Treating available memory as a signed value.)
Similarly for available disk space. (Most likely those cases are
using signed integers in C, and not Fortran.) Memory sizes in C
should be done with unsigned types, but the argument to fs () is
supposed to be signed (to allow relative ss).
> 3. Points made previously in this thread about things that shouldn't be
> negative, so it might be nice to have the compiler catch them. These all
> seem to me to be just special cases of subranges. I don't see that doing
> unsigned is the "right" way to address that. If one wants subranges, one
> should do subranges in general rather than one specific case and that
> case only. There are arguments for doing subranges; they have certainly
> been proposed. But that's a different proposal. If one is really after
> subranges, then unsigned does only one specific case and is not
> plausibly extendable to cover other cases. You'd have to throw it out
> and start over again to do the more general case. That's not a very good
> selling point for unsigned if that is the objective.
I agree with this one. Also, the C rules for mixed signed and unsigned
operations are confusing to even experienced C programmers.
> 4. Some/most hardware can do it, so Fortran ought to take advantage of
> that hardware for efficiency and simplicity. I'd categorize the OP's
> interest as in this direction. I know he didn't state it that way, and
> perhaps he'd disagree with my categorization, but that's how I see it.
Well, I believe he was primarily concerned with efficient generation
of a double length product, and secondarily with efficient unsigned,
but in any case it does seem that efficiency was important.
> The problem with this, from a standard perspective, is that it is too
> strongly dependent on particular hardware issues. If you require that
> things work just like on a particular piece of hardware, then you can
> make things pretty bad on other hardware - severely hurting instead of
> helping performance and simplicity. This is a special case of a major
> general issue with standardization - you have to decide how much to
> cater to particular hardware features. Obviously you have to pay some
> attention to hardware, or one ends up with a language that is useless in
> practice. But pay too muuch attention to particular hardware features
> and you end up with a language that has portability issues.
I agree for this case, and some other "why doesn't Fortran allow..."
that have been discussed here recently. (The one that occurs to me
is the carriage return/overprint question, but there are more.)
-- glen
| |
| tholen@antispam.ham 2007-06-22, 4:16 am |
| Richard Maine writes:
> 2. To squeeze one more bit of range out of something. Maybe you want to
> be able to use numbers larger than (approx) 2 billion, but 4 billion is
> enough. Or the same issues with smaller sizes - 255 is plenty, but 127
> isn't. I actually think this is the most common reason... other than the
> C interop one. But that puts it in a pretty small nich of good
> application areas. And what happens when the requirement grows just a
> hair more and now you need something with 1 more bit?
Best example I can think of is astronomical CCD images stored in FITS
format. Because you can't have less than zero light fall on a pixel,
values are best given as unsigned integers, which has double the dynamic
range of a signed integer. Of course, the FITS format deals with the
issue by implementing the BZERO keyword. Most CCD cameras produce pixel
values from 0 to 65535, and then the BZERO value is set to 32768, thereby
storing the pixel value as a signed integer between -32768 and +32767.
| |
| glen herrmannsfeldt 2007-06-22, 4:16 am |
| tholen@antispam.ham wrote:
> Richard Maine writes:
(snip)
[color=darkred]
> Best example I can think of is astronomical CCD images stored in FITS
> format. Because you can't have less than zero light fall on a pixel,
> values are best given as unsigned integers, which has double the dynamic
> range of a signed integer. Of course, the FITS format deals with the
> issue by implementing the BZERO keyword. Most CCD cameras produce pixel
> values from 0 to 65535, and then the BZERO value is set to 32768, thereby
> storing the pixel value as a signed integer between -32768 and +32767.
With the assumption that -32768 is legal, you can store just as much
as an unsigned 16 bit value. You have to be a little careful how
you use it, but it isn't so hard. If it isn't the largest available
type you can assign to a larger type and mask off the extra bits.
-- glen
| |
| analyst41@hotmail.com 2007-06-22, 10:07 pm |
| On Jun 21, 11:30 am, Dick Hendrickson <dick.hendrick...@att.net>
wrote:
> analys...@hotmail.com wrote:
>
>
> Since the experts seem to be busy, I'll take a swing at this.
>
> It's always hard to say why something wasn't done, (other than
> nobody wanted to do it). But, here's a couple of guesses.
>
> 1) Historically, FORTRAN was designed to map very efficiently onto the
> existing machines. In the old days, machines didn't detect integer
> overflow at all. There was essentially no hardware support for any
> of the hard unsigned integer cases. (That's still true, as the thread
> about i+j overflow shows). In the early days, integers were used for
> subscripts and for counting things. Unsigned wasn't needed for either.
>
> 2) Since then, nobody has "seriously" asked for them. Just saying
> "why don't you guys go do some extra work" isn't a "serious enough"
> request. There can be several reasons for this. Maybe nobody
> really wants them. Maybe the people who do figure that J3 will
> never do it, so why waste everybody's time on something that will
> be ignored. Maybe some vendors think they have a competitive
> advantage with a feature that other vendors don't have.
>
> 3) It's hard to figure out what should happen on one's and two's
> complement machines, as well as on signed magnitude ones (and maybe
> also on machines that pass (some) integer arithmetic through the
> floating point hardware. If you look at the BIT model in Fortran 2003
> it essentially says the model is processor dependent if the sign bit is
> set.
>
> 4) It's hard to know what the right or expected thing is if you do
> mixed mode (signed and unsigned) arithmetic. Which type coerces to
> the other type? Is it forbidden? What about COMMON/EQUIVALENCE? Or
> argument association? It's not that you can't come up with answers
> to these questions. It's that not everybody has the same expectations
> or needs.
>
> 5) (I'm not trying to be stupid or pick a fight here.) It's been
> my understanding that the most common historical idiomatic use of
> unsigned integers in C has been for 8 bit "characters". If this
> is right, then (IMO) the Fortran character type solution is much
> better and there's no need for unsigned integers.
>
> That's my set of guesses. I'm pretty sure about 1 and 2. The
> rest is speculation.
Thanks - that was very informative. While looking at the overflow
problem, I realized that unsigned integers are "wasteful" - given the
same precision, more sums overflow (about twice I think) than in the
case of signed integers.
I still haven't fully understood how the professor was able to
generate random numbers very efficiently using C's unsigned integers
(but apparently not with anything Fortran has to offer). I have
always felt that one shouldn't have to get into "bits and bytes" to
solve real world problems - is this an exception to that rule ? :-)
| |
| robert.corbett@sun.com 2007-06-22, 10:07 pm |
| On Jun 21, 1:09 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> I agree with this one. Also, the C rules for mixed signed
> and unsigned operations are confusing to even experienced
> C programmers.
Too true, which is why Sun f90/f95 bans mixed signed and
unsigned operations in most cases. If a programmer wants
to mixed signed and unsigned integers in an expression,
he must use explicit conversions.
Sun f90/f95 makes special case exception for constants.
The statement
U = U + 1
is allowed. We did not allow that at first, but users
complained about having to write
U = U + 1U
Bob Corbett
| |
|
| "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:b8adnWNt_-aiWufbnZ2dnUVZ_q6vnZ2d@comcast.com...
> Dick Hendrickson wrote:
> (snip)
>
>
> In the early days subscripts had to be positive, and so did the
> values of DO loops.
In the early days, subscripts could be anything, and the start
and final values of loops could be anything.
FORTRAN imposed those restrictions on users of that language.
| |
|
| "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:ldmdnbU9Iec5b-TbnZ2dnUVZ_oavnZ2d@comcast.com...
> analyst41@hotmail.com wrote:
>
> The use of unsigned integers isn't so important, but the ability
> to multiply two integers and generate a double length product
> is important.
From the early days, RNGs did not generate or require double-length
integer products.
Some RNGs don't require integer arithmetic at all for the RNG itself.
| |
|
| "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:sQwei.200708$p47.16042@bgtnsc04-news.ops.worldnet.att.net...
> analyst41@hotmail.com wrote:
>
> Since the experts seem to be busy, I'll take a swing at this.
>
> It's always hard to say why something wasn't done, (other than
> nobody wanted to do it). But, here's a couple of guesses.
>
> 1) Historically, FORTRAN was designed to map very efficiently onto the
> existing machines. In the old days, machines didn't detect integer
> overflow at all.
From 1965 the IBM 360 series detected integer overflow.
There may have been earlier machines that did also,
possibly the stack machines of Burroughs and English Electric
(KDF9), c. 1963.
> There was essentially no hardware support for any
> of the hard unsigned integer cases.
That's not the case at all. Some machines dating from 1951
provided unsigned integer multiply only, and produced a
double-length unsigned integer product.
That arrangement was to facilitate the use of multiple-word
arithmetic. Software to support triple- and quadruple-length
integer arithmetic was available.
One such application comes to mind, (re-)discovered only
recently, where 5-word integer arithmetic (160 bits) was used in 1965
to generate Babylonian tables.
But double-word float using integers was common in the
1950s and 1960s.
> (That's still true, as the thread
> about i+j overflow shows). In the early days, integers were used for
> subscripts and for counting things. Unsigned wasn't needed for either.
In the early days, integers were used for ALL arithmetic
(including FLOAT) and for logical operations.
> 2) Since then, nobody has "seriously" asked for them. Just saying
> "why don't you guys go do some extra work" isn't a "serious enough"
> request. There can be several reasons for this. Maybe nobody
> really wants them. Maybe the people who do figure that J3 will
> never do it, so why waste everybody's time on something that will
> be ignored. Maybe some vendors think they have a competitive
> advantage with a feature that other vendors don't have.
>
> 3) It's hard to figure out what should happen on one's and two's
> complement machines, as well as on signed magnitude ones (and maybe
> also on machines that pass (some) integer arithmetic through the
> floating point hardware. If you look at the BIT model in Fortran 2003
> it essentially says the model is processor dependent if the sign bit is
> set.
groan.
> 4) It's hard to know what the right or expected thing is if you do
> mixed mode (signed and unsigned) arithmetic. Which type coerces to
> the other type? Is it forbidden? What about COMMON/EQUIVALENCE? Or
> argument association? It's not that you can't come up with answers
> to these questions. It's that not everybody has the same expectations
> or needs.
>
> 5) (I'm not trying to be stupid or pick a fight here.) It's been
> my understanding that the most common historical idiomatic use of
> unsigned integers in C has been for 8 bit "characters". If this
> is right, then (IMO) the Fortran character type solution is much
> better and there's no need for unsigned integers.
>
> That's my set of guesses. I'm pretty sure about 1 and 2. The
> rest is speculation.
| |
| Charles Russell 2007-06-25, 10:07 pm |
| Richard Maine wrote:
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>
>
> I'll throw in a few things, some of them partially overlapping with
> Dick's, but from a slightly different different viewpoint.
>
> I'll focus on the questions of why anyone would want such a thing.
> Answers I've seen are
>
> (etc.)
I'll add another. On the rare occasions when I've had to manipulate
binary files, I've done so in C, treating the data as
array-of-unsigned-8bit-byte. The code has been portable to various
machines. I'm a scientific fortran user, not a programmer, and am most
comfortable thinking in terms of arrays of integers. Sadly, I don't
know how to do the same thing as simply in fortran as in C.
| |
| gary.l.scott@lmco.com 2007-06-25, 10:07 pm |
| On Jun 25, 2:13 pm, Charles Russell <SPAMworFREE...@bellsouth.net>
wrote:
> Richard Maine wrote:
>
>
>
>
>
>
>
> I'll add another. On the rare occasions when I've had to manipulate
> binary files, I've done so in C, treating the data as
> array-of-unsigned-8bit-byte. The code has been portable to various
> machines. I'm a scientific fortran user, not a programmer, and am most
> comfortable thinking in terms of arrays of integers. Sadly, I don't
> know how to do the same thing as simply in fortran as in C.
I've also done a lot of bitmap image processing, rasterization, and
byte-stream data processing over the years in Fortran. It wasn't
perfectly portable, but it was never very difficult to adapt to any
other system I moved to.
| |
| Richard Maine 2007-06-25, 10:07 pm |
| Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:
> Richard Maine wrote:
[as unsigned integers][color=darkred]
>
> I'll add another. On the rare occasions when I've had to manipulate
> binary files, I've done so in C, treating the data as
> array-of-unsigned-8bit-byte. The code has been portable to various
> machines. I'm a scientific fortran user, not a programmer, and am most
> comfortable thinking in terms of arrays of integers. Sadly, I don't
> know how to do the same thing as simply in fortran as in C.
I don't know what this has to do in particular with unsigned. Seems to
me that an array of 8-bit signed integers would do the same thing. If
not, then I suspectthe reason reduces to one of the others I stated -
either C interop or to squeeze an extra bit of range out of 8 bits.
Note that the f2003 stream I/O helps a lot with using non-Fortran binary
files, but that again doesn't have much obvious correlation with
unsigned.
Perhaps you were just talking about having an 8-bit integer kind
available. That I well understand. I use them a lot myself for exactly
this kind of thing. But the question at hand was about unsigned integers
(of any size), which is orthogonal to the qquestion about having 8-bit
sizes.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2007-06-25, 10:07 pm |
| Charles Russell wrote:
(snip)
> I'll add another. On the rare occasions when I've had to manipulate
> binary files, I've done so in C, treating the data as
> array-of-unsigned-8bit-byte. The code has been portable to various
> machines.
Unsigned char is special in C, though with no guarantee that it
is actually eight bits. Many programs assume that it is.
> I'm a scientific fortran user, not a programmer, and am most
> comfortable thinking in terms of arrays of integers. Sadly, I don't
> know how to do the same thing as simply in fortran as in C.
Fortran and C are different. Still, with C interoperability
it shouldn't be too hard to do most of the things that you
would do with unsigned char in C.
Note that even in C actually working with unsigned char
the actual operations are normally done as int. For example,
unsigned char i,j,k;
i=j=-128;
k=i+j;
According to C, i and j are converted to int, added together, and
the result converted back to unsigned char. The expression i+j
in a function call would have type int. (or possibly unsigned int).
In Fortran, one might read in data as integers of the
SELECTED_INT_KIND(2), convert them to default INTEGER type while
operating on them, then back to SELECTED_INT_KIND(2) for output.
-- glen
| |
| Charles Russell 2007-06-26, 10:06 pm |
| Richard Maine wrote:
> Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:
>
>
> [as unsigned integers]
>
> I don't know what this has to do in particular with unsigned. Seems to
> me that an array of 8-bit signed integers would do the same thing. If
> not, then I suspectthe reason reduces to one of the others I stated -
> either C interop or to squeeze an extra bit of range out of 8 bits.
>
> Note that the f2003 stream I/O helps a lot with using non-Fortran binary
> files, but that again doesn't have much obvious correlation with
> unsigned.
>
> Perhaps you were just talking about having an 8-bit integer kind
> available. That I well understand. I use them a lot myself for exactly
> this kind of thing. But the question at hand was about unsigned integers
> (of any size), which is orthogonal to the qquestion about having 8-bit
> sizes.
>
A major reason that I used C was to avoid having to deal with explicit
buffers. Stream I/O should indeed solve that problem. I have given no
thought to how to handle the rest of the problem without using unsigned
byte, so possibly it is not really much of a problem, but I found it
simplest to treat every byte as a positive integer. Not being a
programmer, I am uncomfortable dealing with internal representations,
bit-level operations, and explicit buffers.
At one time - has it changed? - Sun and DEC fortran manuals were written
with the nonprogrammer in mind, and gave simple cookbook methods for
calling C routines from fortran. Fortunately, the same methods work
with g77.
| |
| Kevin G. Rhoads 2007-06-26, 10:07 pm |
| >Best example I can think of is astronomical CCD images
However, I would argue that once one attempts to adjust for
dark-current backgrounds, one can no longer presume that
values must necessarily be non-negative.
| |
| tholen@antispam.ham 2007-06-26, 10:07 pm |
| Kevin G. Rhoads writes:
[color=darkred]
> However, I would argue that once one attempts to adjust for
> dark-current backgrounds, one can no longer presume that
> values must necessarily be non-negative.
Dark current can't be negative. However, any time you "adjust"
for any source of counts, whether it be dark current, bias, or
sky background, noise in that source can lead to negative pixel
values in the corrected image.
| |
| robin 2007-06-26, 10:07 pm |
| "Richard Maine" <nospam@see.signature> wrote in message
news:1i09l2p.14th0tr135d2m4N%nospam@see.signature...
> Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:
>
>
> I don't know what this has to do in particular with unsigned. Seems to
> me that an array of 8-bit signed integers would do the same thing.
If you can get them.
Processing the data as characters, however, can be done
in a more-or-less portable manner.
| |
| robin 2007-06-26, 10:07 pm |
| "Charles Russell" <SPAMworFREEwor@bellsouth.net> wrote in message
news:vtUfi.4566$G85.4561@trndny08...
> I'll add another. On the rare occasions when I've had to manipulate
> binary files, I've done so in C, treating the data as
> array-of-unsigned-8bit-byte. The code has been portable to various
> machines. I'm a scientific fortran user, not a programmer, and am most
> comfortable thinking in terms of arrays of integers. Sadly, I don't
> know how to do the same thing as simply in fortran as in C.
The equivalent in Fortran is to use CHARACTER, length 1.
I've processed picture files that way (created and read in).
| |
| robin 2007-06-26, 10:07 pm |
| "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:5OudncHYvqP3ux3bnZ2dnUVZ_oernZ2d@co
mcast.com...
> In Fortran, one might read in data as integers of the
> SELECTED_INT_KIND(2),
Not guaranteed to give a byte.
CHARACTER of length 1 is the best bet.
| |
| Dan Nagle 2007-06-26, 10:07 pm |
| Hello,
robin wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:5OudncHYvqP3ux3bnZ2dnUVZ_oernZ2d@co
mcast.com...
>
>
> Not guaranteed to give a byte.
>
> CHARACTER of length 1 is the best bet.
Not guaranteed to give a byte.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Richard Maine 2007-06-26, 10:07 pm |
| Dan Nagle <dannagle@verizon.net> wrote:
> robin wrote:
>
> Not guaranteed to give a byte.
And also not guaranteed to support 256 values at all. There have been
systems, even where characters were 8 bits, that did things like force
the top bit of character data to zero. I've used such implementations,
though it has been a while. It was particularly so for formatted I/O as
I recall.
I find it far safer to use integers to represent integers than to try to
fake it with characters.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
|
| "Richard Maine" <nospam@see.signature> wrote in message
news:1i0befo.7rdz2c8s289yN%nospam@see.signature...
> Dan Nagle <dannagle@verizon.net> wrote:
>
>
> And also not guaranteed to support 256 values at all. There have been
> systems, even where characters were 8 bits, that did things like force
> the top bit of character data to zero. I've used such implementations,
> though it has been a while. It was particularly so for formatted I/O as
> I recall.
How many systems currently in existence do not support 256 values?
> I find it far safer to use integers to represent integers than to try to
> fake it with characters.
Where there is no 8-bit integer alternative,
CHARACTER is the only alternative when it comes to the I/O part
of the process.
| |
|
| "Dan Nagle" <dannagle@verizon.net> wrote in message
news:70dgi.2383$YS.13@trnddc03...
> Hello,
>
> robin wrote:
>
> Not guaranteed to give a byte.
It has, for longer and on more systems than SELECTED_INT_KIND(2).
To be sure, some computers had only words. Most are long since gone.
The PC predominates.
| |
| Dan Nagle 2007-06-27, 8:07 am |
| Hello,
robin wrote:
> "Dan Nagle" <dannagle@verizon.net> wrote in message
> news:70dgi.2383$YS.13@trnddc03...
>
> It has, for longer and on more systems than SELECTED_INT_KIND(2).
Are you saying that Fortran 66 came before Fortran 90? :-)
If you're going to think back that far, what's a byte?
> To be sure, some computers had only words. Most are long since gone.
> The PC predominates.
Where multi-character code O/S are the norm.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
|
| "Dan Nagle" <dannagle@verizon.net> wrote in message
news:U7pgi.5276$yN.1895@trnddc07...
> Hello,
>
> robin wrote:
>
> Are you saying that Fortran 66 came before Fortran 90? :-)
You don't know that it did?
It may have escaped your notice that many of those posting in this ng
are using Fortran 77, and thus will be using CHARACTER,
which FYI gives a byte on pretty well most systems in use.
> If you're going to think back that far, what's a byte?
You mean that you don't know that either?
>
> Where multi-character code O/S are the norm.
We aren't talking about O/Ss. It's Fortran.
| |
| glen herrmannsfeldt 2007-06-30, 8:05 am |
| Dan Nagle wrote:
(big snip)
> Are you saying that Fortran 66 came before Fortran 90? :-)
> If you're going to think back that far, what's a byte?
OS/360 Fortran documentation mostly says 'storage locations'
where you would expect it to say 'byte', but everyone I knew
at the time called it 'byte', anyway.
OS/360 Fortran only has one type that is one byte long, that
is LOGICAL*1. Not so convenient, as you can't use relational
operators on it.
-- glen
| |
| glen herrmannsfeldt 2007-06-30, 8:05 am |
| Richard Maine wrote:
(snip regarding small integers and CHARACTER variables)
> And also not guaranteed to support 256 values at all. There have been
> systems, even where characters were 8 bits, that did things like force
> the top bit of character data to zero. I've used such implementations,
> though it has been a while. It was particularly so for formatted I/O as
> I recall.
C guarantees that char is at least 8 bits, so I would expect it
in Fortran with C interoperability, also.
> I find it far safer to use integers to represent integers than to try to
> fake it with characters.
I agree.
-- glen
| |
| Dan Nagle 2007-06-30, 8:05 am |
| Hello,
glen herrmannsfeldt wrote:
> OS/360 Fortran documentation mostly says 'storage locations'
> where you would expect it to say 'byte', but everyone I knew
> at the time called it 'byte', anyway.
I would expect IBM's 1960s technical documentation to avoid
the term 'byte' because there were so many different bytes.
JOTTOMH, 6-bits, 7-bits, 8-bits, 9-bits, and 12-bits. I might
be able to think of another if I spent some time on it.
Colloquially, some programmers made the equation that IBM
terminology defined the standard language. (I carried an ANSI
Fortran 77 standard when teaching Fortran during the 1980s
to counter such misconceptions. I preached the Gospel
according to St. Ansi as if from a pulpit.)
In careful use, for example in standards documents, the term
for '8-bits' is 'octet' to be clear.
On modern equipment, there is in some quarters a push towards
characters larger than 8 bits in order to support internationalization.
My original point was that the equation that a 'byte' is a character
is an 8-bit integer was wrong, is wrong, and may be expected to be
wrong for the foreseeable future.
So I think Glen, Richard and I are in violent agreement,
but apparently, one must be especially clear lest unhelpful comments
be made.
<snip>
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| glen herrmannsfeldt 2007-07-01, 4:18 am |
| Dan Nagle wrote:
(snip)
> On modern equipment, there is in some quarters a push towards
> characters larger than 8 bits in order to support internationalization.
Java has only one unsigned type: the 16 bit char.
Though it might be that even 16 bits isn't enough for everyone.
-- glen
| |
| Gary Scott 2007-07-01, 4:18 am |
| glen herrmannsfeldt wrote:
> Dan Nagle wrote:
>
> (snip)
>
>
>
> Java has only one unsigned type: the 16 bit char.
>
> Though it might be that even 16 bits isn't enough for everyone.
Having a 16-bit fixed width character size was never necessary. I think
definitions like DBCS/MBCS/... just shows lack of imagination. It
would have been better to define a prefix/suffix, or shift in/out,
escape sequence/process to allow different sized "characters" as
necessary. With only a little thought, efficient
searching/backspacing/indexing, etc. can be easily accommodated with
only a minimal support library. 16-bit characters are still just a
kludge solution.
>
> -- glen
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
| |
| Terence 2007-07-01, 4:18 am |
| On Jun 30, 9:54 pm, Dan Nagle <danna...@verizon.net> wrote:
> In careful use, for example in standards documents, the term
> for '8-bits' is 'octet' to be clear.
>
> On modern equipment, there is in some quarters a push towards
> characters larger than 8 bits in order to support internationalization.
>
> My original point was that the equation that a 'byte' is a character
> is an 8-bit integer was wrong, is wrong, and may be expected to be
> wrong for the foreseeable future.
Bits often come in packets from hardware devices and are stored in
registers.
I would prefer to call the minimum packet a "word of bits".
There are 12-bit "words" coming from an old punched card reader, from
an RS232C frame-of-bits recievr/transmitter register and several kinds
of OMR readers. I agree "byte" has become inappropriate, and as
mentioned by Dan, the World's languages are now mainly conveyed as 16
bit packets. And the venerable keyboard handler still passes 16 bits
per key!
| |
| Wade Ward 2007-07-01, 4:18 am |
|
"Terence" <tbwright@cantv.net> wrote in message
news:1183245461.554481.17170@g37g2000prf.googlegroups.com...
> On Jun 30, 9:54 pm, Dan Nagle <danna...@verizon.net> wrote:
>
>
> Bits often come in packets from hardware devices and are stored in
> registers.
> I would prefer to call the minimum packet a "word of bits".
> There are 12-bit "words" coming from an old punched card reader, from
> an RS232C frame-of-bits recievr/transmitter register and several kinds
> of OMR readers. I agree "byte" has become inappropriate, and as
> mentioned by Dan, the World's languages are now mainly conveyed as 16
> bit packets. And the venerable keyboard handler still passes 16 bits
> per key!
I think that's because the number of fingers on Homo Sapiens is relatively
constant. Of course, I haven't been to eastern Kentucky recently.
--
WW
| |
| David Thompson 2007-07-22, 7:10 pm |
| On Thu, 21 Jun 2007 15:30:32 GMT, Dick Hendrickson
<dick.hendrickson@att.net> wrote:
> analyst41@hotmail.com wrote:
<snip>
> 5) (I'm not trying to be stupid or pick a fight here.) It's been
> my understanding that the most common historical idiomatic use of
> unsigned integers in C has been for 8 bit "characters". If this
Well, yes and no. C has both (explicitly) signed and unsigned char
types, which are typically used for tiny integers, and 'plain' char
(no modifier) which can be either signed or unsigned depending on the
implementation/platform; in the first (PDP-11) C it was signed
(because the MOVB mem8b,reg16b instruction sign-extends).
(This is unlike other integer types in C, which default to signed if
you don't specify unsigned. Except, optionally, bitfields.)
In practice on most machines nowadays C plain char is unsigned, but
most things you do with characters and strings, even in C, don't
depend on signedness, and for portability must not. The only IME
common exception is translation or other attribute tables, such as
used for the <ctype.h> inquiries like isupper(), and for portability
of those you must use or (more usually) convert to unsigned char.
Unsigned char is also the only type (still) guaranteed to have no
padding bits or trap representations, and so is used as the type for
accessing arbitrary chunks of memory e.g. in memcpy().
Probably the most common use of unsigned integers in C is for size of
things in memory or of chunks of memory, because the standard-defined
type for this, size_t, must be unsigned, and also because it may need
to be unsigned to cover the full address space as noted IIRC by glen
h. Probably a substantial number of indexes through memory are also
unsigned so that when compared to an unsigned size/limit they don't
produce annoying warnings on many compilers.
I'd bet the next most common category is things that are really just
bits -- either bit 'arrays', or combinations of bitfields like the
classic example of an I/O device control register in a driver for it
-- and after that multiword/bignum numbers and arithmetic (which IIRC
started this thread).
> is right, then (IMO) the Fortran character type solution is much
> better and there's no need for unsigned integers.
>
And one minor nit: when glen h says elsethread
> C requires all characters in the normal character set to have
> positive values. For ASCII-7 this allows for either signed
> or unsigned char if char is eight bits, for EBCDIC and eight
> bit char, it only allows for unsigned.
the 'normal' character set is more precisely the members of the 'basic
execution character set' as detailed by the Standard, which are (not
by accident) the 90-ish common graphics of ASCII and 'core' EBCDIC
(that is, 4-7/a-f+0+1 specials and 8-bc-f/1-9+0+1 mostly alnum) plus a
handful of controls also common to ASCII and EBCDIC with the special
case that null is required to be in the basic set but represented as
zero (which isn't positive).
If the implementation's actual 'execution character set' includes
additional characters, as either EBCDIC or ASCII much less 8859 does,
they may be negative. In particular it is perfectly conforming, though
inconvenient, to use 8859 in 8 bits with the 'high half' negative.
- formerly david.thompson1 || achar(64) || worldnet.att.net
| |
| Colin Paul Gloster 2007-07-23, 8:05 am |
| On 2007-07-22, David Thompson <dave.thompson2@verizon.net> wrote:
|-----------------------------------------------------------------------|
|"[..] |
| |
| [..] C has both (explicitly) signed and unsigned char |
| types, which are typically used for tiny integers, and 'plain' char |
| (no modifier) which can be either signed or unsigned depending on the |
| implementation/platform; [..] |
| (This is unlike other integer types in C, which default to signed if |
| you don't specify unsigned. Except, optionally, bitfields.) |
| |
|[..]" |
|-----------------------------------------------------------------------|
Hello,
Other integral types in C can default to signed or unsigned, depending
on the implementation.
Regards,
Colin Paul Gloster
| |
| Colin Paul Gloster 2007-07-23, 8:05 am |
| On 2007-06-25, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
|-----------------------------------------------------------------------|
|"[..] |
| |
| Unsigned char is special in C, though with no guarantee that it |
| is actually eight bits. Many programs assume that it is." |
|-----------------------------------------------------------------------|
C99 has uint8_t but not everyone has C99.
|-----------------------------------------------------------------------|
|"[..] |
| |
| Fortran and C are different. [..]" |
|-----------------------------------------------------------------------|
Only in details and syntax.
|-----------------------------------------------------------------------|
|" |
| Note that even in C actually working with unsigned char |
| the actual operations are normally done as int. For example, |
| |
| unsigned char i,j,k; |
| |
| i=j=-128; |
| k=i+j; |
| |
| According to C, i and j are converted to int, added together, and |
| the result converted back to unsigned char. The expression i+j |
| in a function call would have type int. (or possibly unsigned int). |
| |
| [..]" |
|-----------------------------------------------------------------------|
I believe this is true.
Regards,
Colin Paul Gloster
|
|
|
|
|