Some weeks ago a group was created on Slack that is discussing the possibilities of
"mathematics of arrays" (MoA) within the context of Fortran.
Some weeks ago a group was created on Slack that is discussing the possibilities of "mathematics of arrays" (MoA) within the context of Fortran. The idea of this methodology is to express algorithms in such a way that they are independent of the numberof dimensions, which will make it easier for the compiler (both the MoA component and the regular compiler) to optimise the program. As the theory is fairly abstract, the initiator of this group Lenore Mullin, is preparing an introduction to the theory
If you are interested, let us know or join the Slack channel, "MoA Global Team"..
To get a bit better acquainted with the idea, here are a few references: https://docs.google.com/presentation/u/0/d/1g4TQB57NbmueIcl4icnkqIlVU5xSnB6Fkr-9IW8MzTA/mobilepresent
https://arxiv.org/abs/1904.02612 https://downloads.hindawi.com/journals/sp/2013/672424.pdf
Some weeks ago a group was created on Slack that is discussing the possibilities of "mathematics of arrays" (MoA) within the context of Fortran. The idea of this methodology is to express algorithms in such a way that they are independent of the numberof dimensions, which will make it easier for the compiler (both the MoA component and the regular compiler) to optimise the program. As the theory is fairly abstract, the initiator of this group Lenore Mullin, is preparing an introduction to the theory
I am then reminded of the way, I believe, Python and Octave store arrays. When you apply transpose to an array, instead of actually transposing the data, it just remembers, maybe with one bit, that it is transposed.
On 8/15/21 4:44 AM, gah4 wrote:.
I am then reminded of the way, I believe, Python and Octave store arrays. When you apply transpose to an array, instead of actually transposing the data, it just remembers, maybe with one bit, that it is transposed.I did not know that Python and Octave did that. However, I have always thought that fortran missed this opportunity with the introduction of
array operations in f90. If the language had allowed programmer access
to the array metadata,
then operations such as transpose and complex
conjugation could be done with O(0) effort rather than O(N) effort (for
N being the number of elements). It would also have been possible to use those operations on the left hand side of statements, the same way as
occurs in standard math notation.
A = Fast_Transpose( array expression )
Fast_Transpose(A) = array expression
This already occurs in the language in some cases, but it is not under control of the programmer, it is just a compiler optimization step. To
give an example, consider the following statement
call sub( Transpose(A), B )
where the first argument is intent(in). If you check memory locations of A(1,1) before the call and inside the subroutine, they are sometimes the same. That means the compiler has recognized the opportunity, and
instead of generating a temporary array for the first argument (which requires O(N) effort to allocate and copy the contents), it instead just fiddles with the array metadata, and uses the original data storage
(which requires only O(0) effort).
That is a good idea! I just wish I could do that same thing directly as
a programmer.
On Monday, August 16, 2021 at 4:10:49 AM UTC+10, Ron Shepard wrote:.
On 8/15/21 4:44 AM, gah4 wrote:
.I am then reminded of the way, I believe, Python and Octave store arrays. >>> When you apply transpose to an array, instead of actually transposing the >>> data, it just remembers, maybe with one bit, that it is transposed.
I did not know that Python and Octave did that. However, I have always.
thought that fortran missed this opportunity with the introduction of
array operations in f90. If the language had allowed programmer access
to the array metadata,
It does.
Try LBOUND and UBOUND.
On 21/08/16 4:24 AM, Robin Vowels wrote:
It does.
Try LBOUND and UBOUND.
That's only part of the array descriptor metadata (the stride still missing..) And it gives the user only read access.
On Thursday, August 19, 2021 at 2:08:04 PM UTC-7, Jos Bergervoet wrote:.
On 21/08/16 4:24 AM, Robin Vowels wrote:(snip)
It does.
Try LBOUND and UBOUND.
That's only part of the array descriptor metadata (the stride still missing..) And it gives the user only read access.Yes, it would be interesting to have an extension, or alternative, to C_F_POINTER that would allow one to specify the strides separarately,
such that one could arrange for all the different ways of addressing
array elements.
Reminds me that VAX defines an array descriptor, to be used for
pass by descriptor subroutine calls. It includes both the virtual
origin (needed for PL/i) and the actual origin (needed for Fortran).
In PL/I, when you pass an array to a procedure, it keeps its lower
bound, unlike Fortran. (Except when it does.) There is no provision
for run-time generation of such, though.
On Thursday, August 19, 2021 at 2:08:04 PM UTC-7, Jos Bergervoet wrote:
On 21/08/16 4:24 AM, Robin Vowels wrote:(snip)
It does.
Try LBOUND and UBOUND.
That's only part of the array descriptor metadata (the stride still missing..) And it gives the user only read access.Yes, it would be interesting to have an extension, or alternative, to C_F_POINTER that would allow one to specify the strides separarately,
such that one could arrange for all the different ways of addressing
array elements.
Reminds me that VAX defines an array descriptor, to be used for
pass by descriptor subroutine calls. It includes both the virtual
origin (needed for PL/i) and the actual origin (needed for Fortran).
In PL/I, when you pass an array to a procedure, it keeps its lower
bound, unlike Fortran. (Except when it does.) There is no provision
for run-time generation of such, though.
In PL/I, when you pass an array to a procedure, it keeps its lower
bound, unlike Fortran. (Except when it does.) There is no provision
for run-time generation of such, though.
PL/I passes both its lower bound and its upper bound
(along with the array address, of course).
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 99:28:26 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,786 |