API for a bitset data type

[wclodius2]

Both C++ and Java define a bitset type, so I propose that the standard
library also have a module implementing a bitset type. My first draft
for a public API for that module is as follows.

The module name is STDLIB_BITSETS.

The module exports one constant, BITS_KIND, to be used as a KIND
value in addressing bits in the bitset. This will initially be
INT32.

The module exports one derived type, BITSETS, with a plural name so
that users can name their scalar realizations as BITSET. The type
will contain two private components: BITS a scalar integer of kind
BITS_KIND giving the number of bits in a bitset entity, and a rank
one allocatable integer array BLOCK of private kind BLOCK_KIND,
that will be INT32, to be used in holding the bit values. The type
has an ASSIGNMENT(=) operation defined.

BITSETS will have the following procedures: ALL, AND, AND_NOT,
ANY_BIT, BIT_COUNT, BITS, CLEAR, EOR, EQUIV, EXTRACT,
FLIP, INIT, INPUT, MAX_SET_BIT, NONE, OR, OUTPUT,
PRINT_BITSET, READ_BITSET, SET, TEST, and VALUE. Some of
these procedures will be overloaded:

interface clear
    module procedure clear_bit, clear_range
end interface clear

interface flip
    module procedure flip_bit, flip_range
end interface flip

interface init
    module procedure init_copy, init_zero
end interface init

interface set
    module procedure set_bit, set_range
end interface set

interface print_bitset
    module procedure print_bitset_string, print_bitset_unit
end interface print_bitset

interface read_bitset
    module procedure read_bitset_string, read_bitset_unit
end interface read_bitset

The API for the individual procedures is listed below. The following
aspects of the API may be controversial:

1. How the range is defined for CLEAR_RANGE, FLIP_RANGE, and
   SET_RANGE. I have roughly followed Java's bitset here.

2. That the first argument is modified in AND, AND_NOT, EOR, and
   OR. That is how it is done in the Java bitset, but I can see
   having a function that returns the result rather than a subroutine
   that modifies the first argument.

3. That the I/O procedures INPUT, OUTPUT, PRINT_BITSET, and
   READ_BITSET have STATUS flags.

4. That the procedures often ignore user specification of positions
   outside the range 0 to BITS-1. An alternative is to make the
   procedures impure and invoking ERROR STOP. Another option is to
   add a STATUS argument, but I am reluctant to do that for a simple
   user error.

5. The names of some of the procedures could be more similar to the
   names of Fortran's bit intrinsics.

subroutine init_copy(set, aset, bits)
: Creates the bitset SET, of size BITS if present, otherwise of the
size of ASET. All bits in the range of ASET are copied from ASET. If
BITS is present and larger than the size of ASET then all additional
bits are zero.

subroutine init_zero(set, bits)
: Creates the bitset, SET, of size BITS, with all bits initialized to
zero. BITS must be non-negative.

elemental function all_bits( set )
: Returns .TRUE. if all bits in SET are 1, .FALSE. otherwise.

elemental subroutine and(set1, set2)
: Sets the bits in SET1 to the bitwise AND of the original bits in
SET1 and SET2. If SET1 has fewer bits than SET2 then the
additional bits in SET2 are ignored. If SET1 has more bits than
SET2, then the absent SET2 bits are treated as if present with
zero value.

elemental subroutine and_not(set1, set2)
: Sets the bits in SET1 to the bitwise and of the original bits in
SET1 with the bitwise negation of SET2. If SET1 has fewer bits
than SET2 then the additional bits in SET2 are ignored. If SET1
has more bits, then the absent SET2 bits are treated as if present
with zero value.

elemental function any_bit(set)
: Returns .TRUE. if any bit in SET is 1, .FALSE. otherwise

elemental function bit_count(set)
: Returns the number of non-zero bits in SET.

elemental function bits(set)
: Returns the number of bit positions in SET.

elemental subroutine clear_bit(set, pos)
: Sets to zero the POS position in SET. If POS is less than zero
or greater than BITS(SET)-1 it is ignored.

pure subroutine clear_range(set, start_pos, stop_pos)
: Sets to zero all bits from the START_POS to STOP_POS positions in
SET. If STOP_POS < START_POS then no bits are modified. Positions
outside the range 0 to BITS(SET)-1 are ignored.

elemental subroutine eor(set1, set2)
: Sets the bits in SET1 to the bitwise EOR of the original bits in
SET1 and SET2. If SET1 has fewer bits than SET2 then the
additional bits in SET2 are ignored. If SET1 has more bits than
SET2, then the absent SET2 bits are treated as if present with
zero value.

elemental function equiv(set1, set2)
: Returns .TRUE. if all bits in SET1 and SET2 have the same
value, .FALSE. otherwise. If the sets differ in size a value true
will be returned if and only if the sets are equivalent in the
overlapping range, and all bits outside the overlapping range are
zero.

pure function extract(set, start_pos, stop_pos)
: Creates a new bitset from a range, START_POS to STOP_POS, in
bitset SET.

elemental subroutine flip_bit(set, pos)
: Flips the value at the POS position in SET, provided the
position is valid. If POS is less than 0 or greater than
BITS(SET)-1, then no value is changed.

pure subroutine flip_range(set, start_pos, stop_pos)
: Flips all valid bits from the START_POS to STOP_POS positions in
SET. If STOP_POS < START_POS no bits are flipped. Positions less
than 0 or greater than BITS(SET)-1 are ignored.

subroutine input(unit, set, status)
: Reads the components of the bitset, SET, from the logical unit,
UNIT, assuming that the components were written using OUTPUT.

elemental function max_set_bit( set )
: Returns the maximum position with a set bit. If no bit is set
returns -1.

elemental function none(set)
: Returns .TRUE. if none of the bits in SET have the value 1.

elemental subroutine or(set1, set2)
: Sets the bits in SET1 to the bitwise OR of the original bits in
SET1 and SET2. If SET1 has fewer bits than SET2 then the
additional bits in SET2 are ignored. If SET1 has more bits than
SET2, then the absent SET2 bits are treated as if present with
zero value.

subroutine output(unit, set, status)
: Writes the components of the bitset, SET, to the logical unit,
UNIT, in a unformatted sequence compatible with INPUT.

subroutine print_bitset_string(string, set)
: Writes a BITSETS literal to the allocatable default character
STRING, representing the individual bit values in the bitsets,
SET.

subroutine print_bitset_unit(unit, set, status, advance)
: Writes a bitsets literal to the logical unit, UNIT, representing
the individual bit values in the bitsets, SET. If STATUS is not
present and an error occurs then processing stops with an error
message. If STATUS is present then it has the error code SUCCESS
if no error occurs, has the value ALLOC_FAULT if failure is due to
the allocation of a temporary and, has the value WRITE_FAULT if an
error occurs in the write to the unit. By default or if ADVANCE is
present with the value 'YES', advancing output is used. If ADVANCE
is present with the value 'NO', then the current record is not
advanced by the write.

subroutine read_bitset_string(string, set, status)
: Uses the bitsets literal in the default character STRING, to
define the bitset, SET. The literal may be preceded by an an
arbitrary sequence of blank characters. If STATUS is not present
then an error results in the sending an error message to ERROR_UNIT
and the termination of the program. If STATUS is present then it has
the error code SUCCESS if no error occurs, the value
INVALID_STRING if the sequence of characters after an initial
sequence of blanks is not a BITSETS literal, the value
INVALID_ARRAY_SIZE if the literal's bit size is too large to be
represented by the bit size integer kind, the value ALLOC_FAULT if
allocation of SET failed for the specified BITSIZE, or
INVALID_INTEGER if the HEX literal constant is too large to be
represented by a bit size binary integer. If STATUS is present with
the value SUCCESS then SET is defined, otherwise it is not
defined.

subroutine read_bitset_unit(unit, set, status)
: Uses the bitsets literal at the current position in the formatted
file with logical unit, UNIT, to define the bitset, SET. The
literal may be preceded by an an arbitrary sequence of blank
characters. If STATUS is not present then an error results in the
sending an error message to ERROR_UNIT and the termination of the
program. If STATUS is present then it has the error code SUCCESS
if no error occurs, the value INVALID_STRING if the sequence of
characters after an initial sequence of blanks is not a BITSETS
literal, the value INVALID_ARRAY_SIZE if the literal's bitsize is
too large to be represented by the bitsize integer kind, the value
ALLOC_FAULT if allocation of SET failed for the specified bitsize,
or INVALID_INTEGER if the HEX literal constant is too large to be
represented by a bitsize binary integer. If STATUS is present with
the value SUCCESS then SET is defined, otherwise it is not
defined.

elemental subroutine set_bit(set, pos)
: Sets the value at the POS position in SET, provided the position
is valid. If the position is less than 0 or greater than BITS(SET)-1
then SET is unchanged.

pure subroutine set_range(set, start_pos, stop_pos)
: Sets all valid bits to 1 from the START_POS to the STOP_POS
positions in SET. If STOP_POS < START_POS no bits are
changed. Positions outside the range 0 to BITS(SET)-1 are ignored.

elemental function test(set, pos)
: Returns .TRUE. if the POS position is set, .FALSE.
otherwise. If POS is negative or greater than BITS(SET) - 1 the
result is .FALSE..

elemental function value(set, pos)
: Returns 1 if the POS position is set, 0 otherwise. If POS is
negative or greater than BITS(SET) - 1 the result is 0.

[jvdp1]

Thank you. Interesting proposition.
I work quite often at the bit-level to spare memory (I must store large tables with values only equal to 0,1,2, or 3). Therefore, I wrote something similar but not as complete.

Could it be that some procedures are available outside the DT? E.g. The olderFortran Standard does not provide a pop_count intrinsic function. Therefore, such a function outside the DT could be useful.

The module exports one constant, BITS_KIND, to be used as a KIND
value in addressing bits in the bitset. This will initially be
INT32.

I guess that it could be easily extended to other kinds with fypp.

[wclodius2]

Maybe I am misunderstanding what you are saying, but I think you are misunderstanding what I am saying. I think that you think that BITS_KIND is the kind of integer used to store the bits when it is the kink of integer used to address the bits. You would want to change BITS_KIND only in two different circumstances: 1. You will want to address more than about 2**31 bits in one entity, in which case you will want fo make it an INT64. 2. You will only want to address about 32 bits, but want to address that number in a large number entities so the memory taken up by the BITS member is significant. However the memory taken up by the array descriptor for the BLOCK member of the type is even more significant. (Probably several INT64s.) In that case you want to go for a different type structure, with the BLOCK array a small fixed size array, with at least as many bits as the largest number of bits you want to address. Probably an array of INT8, with BITS also an INT8 to further minimize the memory footprint.

…

On Jul 18, 2020, at 1:42 AM, Jeremie Vandenplas ***@***.***> wrote: Thank you. Interesting proposition. I work quite often at the bit-level to spare memory (I must store large tables with values only equal to 0,1,2, or 3). Therefore, I wrote something similar but not as complete. Could it be that some procedures are available outside the DT? E.g. The Fortran Standard does not provide a pop_count intrinsic function. Therefore, such a function outside the DT could be useful. The module exports one constant, BITS_KIND, to be used as a KIND value in addressing bits in the bitset. This will initially be INT32. I guess that it could be easily extended to other kinds with fypp. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOSW4F4XIBWR76NOBETR4FG47ANCNFSM4O7IG3CQ>.

[jvdp1]

Maybe I am misunderstanding what you are saying, but I think you are misunderstanding what I am saying.

Indeed, I misundertood you. Sorry and thank you for the explanations.

On overall I am fine with the API.

[wclodius2]

Thanks! Now if only more people showed an interest in the topic. I can’t see making this part of the standard library with this minimal show of interest.

…

On Jul 21, 2020, at 2:03 PM, Jeremie Vandenplas ***@***.***> wrote: Maybe I am misunderstanding what you are saying, but I think you are misunderstanding what I am saying. Indeed, I misundertood you. Sorry and thank you for the explanations. On overall I am fine with the API. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOVXFEYVD2YI5LQJE5TR4XX73ANCNFSM4O7IG3CQ>.

[Romendakil]

Personally I never saw the need for a bitmaps type, however, it was an ever and ever recurring topic on c.l.f., so I am pretty sure it would be used if available. So you clearly have my endorsement. But I am pretty new here and just started to read the messages since 2 weeks or so. Your proposal for the API seems very good to me.

[milancurcic]

I'm not the target audience for this, but I don't object to it being part of stdlib. I think it's in scope and the API is clean and clear.

@certik @aradi @arjenmarkus @MarDiehl do you mind offering your feedback?

[arjenmarkus]

Sure, I will have a look :). Op do 23 jul. 2020 om 20:26 schreef Milan Curcic <notifications@github.com>:

…

I'm not the target audience for this, but I don't object to it being part of stdlib. I think it's in scope and the API is clean and clear. @certik <https://github.com/certik> @aradi <https://github.com/aradi> @arjenmarkus <https://github.com/arjenmarkus> @MarDiehl <https://github.com/MarDiehl> do you mind offering your feedback? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR7SSTTR5IV3BBUFSYLR5B6HDANCNFSM4O7IG3CQ> .

[arjenmarkus]

I have looked at the proposal and while I don't use bitsets myself, I can see that there are applications for them in Fortran. The specifications seem complete, but perhaps a bit overcomplete. Here are my detailed remarks:

• In the introduction you mention ALL, but later it is called ALL_BITS
• I think a name like ANY_BITS is more consistent
• Is a function like NONE really needed? You can get the same effect with .NOT. ANY
• Exclusive OR appears as .XOR., not as .EOR. - perhaps use "XOR"?
• Equivalent appears as .EQV. - I therefore suggest EQV
• There is a max_set_bit function, but not a first_set_bit function - does that not have any use?
• The description of the formatted input/output routines does not include the actual format for the bitsets. Only a vage mention is made of HEX. Is it really useful to only support hexadecimal input/output? Why not a sequence of 0 's and 1's? It would be much easier to specify in my opinion.
• The elemental routines AND, AND_NOT etc. require some further explanation: if SET2 is smaller than SET1, then some convention must be used to deal with the extra bits in SET1. Am I correct in assuming that the design is such that SET2 is (at least conceptually) extended with 0 bits? An alternative could be to extend it (again conceptually) in such a way that the extra bits in SET1 are NOT changed.

Just a few remarks and suggestions :).

[wclodius2]

FWIW I suspect I should follow the names for Fortran’s bit intrinsics, but I don’t like the leading I. Fortran has ALL and ANY but they are not bit intrinsics. So maybe ALL_BITS, and ANY_BITS are better. I agree NONE is not needed. Fortran has IEOR for the original bit intrinsics, but the atomic ones are XOR, so maybe XOR is best. I’ll go along with EQV. I am wondering if MAX_SET_BIT has any use. The problem with using just 0s and 1s is that the resulting string is an order of magnitude larger. FWIW I thought of the syntax for the bitset literal content as *bitset-literal-constant* is *bitsize-literal-constant* *hex-literal-constant* where *bitsize-literal-constant* is “S'” *digit* [*digit*…] and *hex-literal-constant* is “Z’” *hex-digit* [*hex-digit*…] but a binary literal constant is much easier to implement and more legible for small bit set sizes. For different sized sets, there are two cases of procedures. For the comparison functions, e.g., EQV, the shorter bitset is treated as if padded with zeros. For thee routines that modify the first argument, if the second argument is larger the trailing bits are ignored, while if it is shorter it is treated as if padded with zeros.

…

On Jul 23, 2020, at 2:21 PM, Arjen Markus ***@***.***> wrote: I have looked at the proposal and while I don't use bitsets myself, I can see that there are applications for them in Fortran. The specifications seem complete, but perhaps a bit overcomplete. Here are my detailed remarks: In the introduction you mention ALL, but later it is called ALL_BITS I think a name like ANY_BITS is more consistent Is a function like NONE really needed? You can get the same effect with .NOT. ANY Exclusive OR appears as .XOR., not as .EOR. - perhaps use "XOR"? Equivalent appears as .EQV. - I therefore suggest EQV There is a max_set_bit function, but not a first_set_bit function - does that not have any use? The description of the formatted input/output routines does not include the actual format for the bitsets. Only a vage mention is made of HEX. Is it really useful to only support hexadecimal input/output? Why not a sequence of 0 's and 1's? It would be much easier to specify in my opinion. The elemental routines AND, AND_NOT etc. require some further explanation: if SET2 is smaller than SET1, then some convention must be used to deal with the extra bits in SET1. Am I correct in assuming that the design is such that SET2 is (at least conceptually) extended with 0 bits? An alternative could be to extend it (again conceptually) in such a way that the extra bits in SET1 are NOT changed. Just a few remarks and suggestions :). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOV5ACEEUU4HEACYLIDR5CLULANCNFSM4O7IG3CQ>.

[arjenmarkus]

I think it is a good idea to stay close to the names of the Fortran intrinsics, indeed. The reason I asked about the hexadecimal format is that I would find it much easier to specify or interpret a particular bit pattern using zeroes and ones than using hexadecimal notation. But I agree that hexadecimal is much shorter :). Supporting both seems to me the best way. For the routines that deal with two sets, having a consistent philosophy - and documenting it :) - is important. It will be much easier to reason about. It reminds me of an explanation I found in a book on (mainly) C by Kernighan and Pike (IIRC, I did not try and look it up): they designed functions like memset() with assignments in mind - the first argument would get changed, as if you read an assignment from left to right. They complained though that many people did not figure this out. Regards, Arjen Op vr 24 jul. 2020 om 01:29 schreef William B. Clodius < notifications@github.com>:

…

FWIW I suspect I should follow the names for Fortran’s bit intrinsics, but I don’t like the leading I. Fortran has ALL and ANY but they are not bit intrinsics. So maybe ALL_BITS, and ANY_BITS are better. I agree NONE is not needed. Fortran has IEOR for the original bit intrinsics, but the atomic ones are XOR, so maybe XOR is best. I’ll go along with EQV. I am wondering if MAX_SET_BIT has any use. The problem with using just 0s and 1s is that the resulting string is an order of magnitude larger. FWIW I thought of the syntax for the bitset literal content as *bitset-literal-constant* is *bitsize-literal-constant* *hex-literal-constant* where *bitsize-literal-constant* is “S'” *digit* [*digit*…] and *hex-literal-constant* is “Z’” *hex-digit* [*hex-digit*…] but a binary literal constant is much easier to implement and more legible for small bit set sizes. For different sized sets, there are two cases of procedures. For the comparison functions, e.g., EQV, the shorter bitset is treated as if padded with zeros. For thee routines that modify the first argument, if the second argument is larger the trailing bits are ignored, while if it is shorter it is treated as if padded with zeros. > On Jul 23, 2020, at 2:21 PM, Arjen Markus ***@***.***> wrote: > > > I have looked at the proposal and while I don't use bitsets myself, I can see that there are applications for them in Fortran. The specifications seem complete, but perhaps a bit overcomplete. Here are my detailed remarks: > > In the introduction you mention ALL, but later it is called ALL_BITS > I think a name like ANY_BITS is more consistent > Is a function like NONE really needed? You can get the same effect with .NOT. ANY > Exclusive OR appears as .XOR., not as .EOR. - perhaps use "XOR"? > Equivalent appears as .EQV. - I therefore suggest EQV > There is a max_set_bit function, but not a first_set_bit function - does that not have any use? > The description of the formatted input/output routines does not include the actual format for the bitsets. Only a vage mention is made of HEX. Is it really useful to only support hexadecimal input/output? Why not a sequence of 0 's and 1's? It would be much easier to specify in my opinion. > The elemental routines AND, AND_NOT etc. require some further explanation: if SET2 is smaller than SET1, then some convention must be used to deal with the extra bits in SET1. Am I correct in assuming that the design is such that SET2 is (at least conceptually) extended with 0 bits? An alternative could be to extend it (again conceptually) in such a way that the extra bits in SET1 are NOT changed. > Just a few remarks and suggestions :). > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub < #221 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/APTQDOV5ACEEUU4HEACYLIDR5CLULANCNFSM4O7IG3CQ >. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR4OQPFBQJDAGGVQ7ZDR5DBVLANCNFSM4O7IG3CQ> .

[wclodius2]

I now think it is a bad idea to have two formats for the BITSETS literal representation: 1. It will be difficult to come up with two unique terms to describe two closely related concepts. 2. Even with distinguishing names users will sometimes confuse them and feed the output of one write format to the input of the other read format 3. I don’t want to write and support four extra subroutines. I am really inclined to make the BITSETS literal a string of zeros and ones. Its intuitive and if people want to save memory they should use the binary representation.

…

On Jul 24, 2020, at 4:20 AM, Arjen Markus ***@***.***> wrote: I think it is a good idea to stay close to the names of the Fortran intrinsics, indeed. The reason I asked about the hexadecimal format is that I would find it much easier to specify or interpret a particular bit pattern using zeroes and ones than using hexadecimal notation. But I agree that hexadecimal is much shorter :). Supporting both seems to me the best way. For the routines that deal with two sets, having a consistent philosophy - and documenting it :) - is important. It will be much easier to reason about. It reminds me of an explanation I found in a book on (mainly) C by Kernighan and Pike (IIRC, I did not try and look it up): they designed functions like memset() with assignments in mind - the first argument would get changed, as if you read an assignment from left to right. They complained though that many people did not figure this out. Regards, Arjen <snip> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOUBNMANIVUN7BSI5DDR5FN7BANCNFSM4O7IG3CQ>.

[MarDiehl]

I am really inclined to make the BITSETS literal a string of zeros and ones. Its intuitive and if people want to save memory they should use the binary representation.

I have never used BITSETS, but using a string of zeros and ones seems odd to me. Why not use an array (of variable size) of logicals/booleans?

[wclodius2]

Note I was writing about a BITSETS literal, a character string representation of the underlying values. A bitset is normally implemented as an array of large integers, with bit intrinsics used to read and manipulate them. The bit operations are used to save memory and reduce memory traffic, so the operations may be faster than say operations on byte sized logicals.

…

On Jul 24, 2020, at 12:45 PM, Martin Diehl ***@***.***> wrote: I am really inclined to make the BITSETS literal a string of zeros and ones. Its intuitive and if people want to save memory they should use the binary representation. I have never used BITSETS, but using a string of zeros and ones seems odd to me. Why not use an array (of variable size) of logicals/booleans? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOW32I67ON7HFNUVB33R5HJFHANCNFSM4O7IG3CQ>.

[ivan-pi]

Speaking of BITSET literals, I don't see a reason why arrays of integers could not be used:

use stdlib_bitsets, only: bitsets, assignment(=)
type(bitsets) :: b

b = [1,0,1,0,0,0,0,0] ! (overloaded assignment for assumed size arrays)
b = "10100000"        ! (overloaded assignment for character literals)

But personally, I find using a string more attractive. Using logical literals .true./.false. is too verbose.

In the potential use case, where you would need to convert an array of zeros and ones (or a logical mask) to a string, you could probably do so using something along the lines of:

character(len=:), allocatable :: bstr
integer, allocatable :: ib(:), dc(:)
integer :: i
dc = [(i,i=1,20)]
allocate(ib,mold=dc)
where (mod(dc,2)==0)
  ib = 1
else where
  ib = 0
end where

allocate(character(len=size(ib)) :: bstr)
write(bstr,'(*(I1))') ib

write(*,'(*(I1))') dc
write(*,'(*(I1))') ib
write(*,'(A)'), bstr

which produces the output:

12345678
01010101
01010101

I haven't looked up the details on boz constants, so I don't know if this could be perhaps also allowed:

b = b'10100000'
b = z'A0'

[wclodius2]

Ivan: Maybe I am misunderstanding what you wrote, but I think you are over interpreting what I wrote. Bitset literals are primarily for writing out the values for human readers, and not fro representing bit sets internally. For writing out for human readers arrays of integers are not useful. An array of zeros and ones are certainly memory wasteful for an internal representation

…

On Jul 25, 2020, at 5:47 AM, Ivan ***@***.***> wrote: Speaking of BITSET literals, I don't see a reason why arrays of integers could not be used: use stdlib_bitsets, only: bitsets, assignment(=) type(bitsets) :: b b = [1,0,1,0,0,0,0,0] ! (overloaded assignment for assumed size arrays) b = "10100000" ! (overloaded assignment for character literals) But personally, I find using a string more attractive. Using logical literals .true./.false. is too verbose. In the potential use case, where you would need to convert an array of zeros and ones (or a logical mask) to a string, you could probably do so using something along the lines of: character(len=:), allocatable :: bstr integer, allocatable :: ib(:), dc(:) integer :: i dc = [(i,i=1,20)] allocate(ib,mold=dc) where (mod(dc,2)==0) ib = 1 else where ib = 0 end where allocate(character(len=size(ib)) :: bstr) write(bstr,'(*(I1))') ib write(*,'(*(I1))') dc write(*,'(*(I1))') ib write(*,'(A)'), bstr which produces the output: 12345678 01010101 01010101 I haven't looked up the details on boz constants, so I don't know if this could be perhaps also allowed: b = b'10100000' b = z'A0' — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#221 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APTQDOS3G7SFKFJPZFR2G3LR5LA4BANCNFSM4O7IG3CQ>.