wavebitscientific / functional-fortran Goto Github PK

It will be beneficial to implement many of the functions (head, tail, map, filter, fold, unfold, and others) for a derived type. Within functional fortran, this could be an empty type:

type :: basetype
endtype basetype

The user would then extend this type when implementing their own:

type,extends(basetype) :: mytype
   ! mytype components
   ! mytype methods
endtype mytype

Evaluate the time complexity of the functions, repeat for multiple intrinsic types, and different compiler vendors.

See the HN comment thread for reference.

The message in the log seems to indicate that gfortran-6 is no longer in the package list. The task could be updated to use gfortran-7 or higher.

Hello Milan, a lot of thanks for all your contributions. I think it must be very useful to have the functional-fortran as an fpm package.

Can't open module file ‘mod_testing.mod’ for reading at (1): No such file or directory
won't compile with use mod_functional

Is there a plan to produce tagged release versions? I'm about to install functional-fortran in the next release of the Sourcery Institute Linux virtual machine. I usually include version information in the installation path along with the compiler and compiler version, for example: /opt/functional-fortran/1.0.0/gnu/6.3.0 and I often summarize my download/installation steps in a bash script in which I'd generally rather access a tar ball via curl or wget. That makes it easier to insure that I'm getting the same thing every time I run the script.

Hello,
Thank you for this excellent library.
Here, I would report an issue. As I invoked ctest after installation, following error message was shown:

96% tests passed, 1 tests failed out of 25
Total Test time (real) =   7.27 sec
The following tests FAILED:
	 16 - test_map (Failed)
Errors while running CTest

Would you please see to this?
Best regards,
Tamoghna

Dear Milan,

thanks for very interesting module.

Any plans to add support of complex type numbers and arrays (at least where it is easy and directly applicable)?

Hello!

Thank you for taking the time to work on this great project!

I noticed that the subscript function does not work for the last element of the array. For example, print*, subscript(-arange(1, 10), [1, 3, 9, 10]) gives -1 -3 -9, instead of the expected -1 -3 -9 -10. This can be fixed by replacing indices = pack(ind, ind > 0 .and. ind < size(x)) with indices = pack(ind, ind > 0 .and. ind <= size(x)) in the functions subscript_*. I could create a pull request if you agree that this should be the expected behavior (or you can fix it yourself in a minute).

Related point. There is a lot of code duplication needed to handle the various types. Using templates (https://github.com/SCM-NV/ftl) would help with this.

Best regards,
Nakib

Implement the following functions that aid the expressiveness of Fortran programs:

• ones(n) - returns an array of ones that is n-long, similar to Python's numpy.ones
• zeros(n) - returns an array of zeros that is n-long, similary to Python's numpy.zeros
• empty(a) - returns an allocated array of size 0 and type and kind of a. This has some use with conjunction with other functional operators.

I can barely read the text on this site.

https://contrastrebellion.com/#page4

This test fails on Darwin ppc with gfortran-12:

16/25 Testing: test_map
16/25 Test: test_map
Command: "/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_fortran_functional-fortran/functional-fortran/work/build/bin/test_map"
Directory: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_fortran_functional-fortran/functional-fortran/work/build
"test_map" start time: Apr 20 10:42 CST
Output:
----------------------------------------------------------
test map,  int8                                                           : �[32mPASS�[0m
test map,  int16                                                          : �[32mPASS�[0m
test map,  int32                                                          : �[32mPASS�[0m
test map,  int64                                                          : �[32mPASS�[0m
test map,  real32                                                         : �[32mPASS�[0m
test map,  real64                                                         : �[32mPASS�[0m
test map,  real128                                                        : �[31mFAIL�[0m
test map,  complex real32                                                 : �[32mPASS�[0m
test map,  complex real64                                                 : �[32mPASS�[0m
test map,  complex real128                                                : �[32mPASS�[0m
Ran a total of  10 tests.
  9 tests PASSED,    1 tests FAILED.
STOP 1
<end of output>
Test time =   0.01 sec
----------------------------------------------------------
Test Failed.
"test_map" end time: Apr 20 10:42 CST
"test_map" time elapsed: 00:00:00
----------------------------------------------------------

Everything else passes.

instead of

pure logical function even(x)
  integer, intent(in) :: x
  even = .false.
  if(mod(x, 2) == 0) even = .true.
endfunction even

I suggest

pure logical function even(x)
  integer, intent(in) :: x
  even = mod(x, 2) == 0
end function even

Adding support for character arrays would open up a plethora of functionality for manipulating strings. Given proper interfaces, the following functions should be useful for manipulating character strings: complement, filter, fold[lrt], head, init, insert, intersection, iterfold, last, map, reverse, set, sort, tail, union.

This relates to #2.

OK, I'm opening this anyway even though further investigation indicated that a change between Fortran 2008 and 2018 renders my idea pointless, as far as I can tell.

In Fortran 2008 the contiguous attribute of assumed shape dummy arguments could be used to enforce they were argument associated with contiguous actual arguments and prevent copies. Fortran 2018 however, dictates that non-contiguous actual arguments will be copied into local contiguous arrays. For very complex and high AI/OI (operations per byte) workloads this copy would be beneficial and prevent subsequent copies. But the whole reason assumed shape dummy arguments are usually slow is because the compiler is creating array temporaries.

AFAICT, as of Fortran 2018, there is no point putting the contiguous attribute on dummy arrays unless you know that you want to enforce a local copy in the event that the array is not contiguous. A discussion of the change in the standard can be found here: https://stackoverflow.com/questions/47852648/passing-non-contiguous-argument-to-contiguous-dummy-array-in-a-fortran-procecdue

FYI: @afanfa @rouson

Hello, all!

Is there a roadmap to the first stable release? A wish list?

(By the way, I'm posting this as an issue since there is no way to start a discussion.)

Best,
Nakib