[stdlib_linalg] Add zeros, ones function.

[zoziha]

• add zeros function;
• add ones function;

add expand function. (the name ex needs to discussed) (aready to expand) (discard!😏)

More routines to do, not this PR

see #476.

[zoziha]

The existing grammar of Fortran cannot reproduce the ones and zeros of Matlab and Python very well. I am looking for ways to adapt the Fortran grammar to write such routines, hoping that the Fortran committee will support features such as generics and look forward to changes.
We can keep such routines in the experimental version, and if we know that Fortran has a better solution (maybe it has to wait for generics or other?), correct them!

[Jim-215-Fisher]

I will review this one.

[zoziha]

Sorry, later I will remove this dependency stdlib_string_type.o (There is no need here, it is a wrong).

[zoziha]

Ditto (lk, c_bool, string_type)

[gareth-nx]

Hi @zoziha

Thanks for the pull request. I just started looking at this, and think it might be useful to have more discussion about the use-cases of these routines in the context of Fortran.

To me there are a couple of situations to consider:

1. We want to initialize an array A to 0's or 1's. In Fortran there are 2 such situations:
   • If the array size is already known then we can just write A=1 or A=0 to achieve results equivalent to zeros and ones. That is simpler than a function call, and should be easier for a compiler to optimize.
   • If the array size is unknown (allocatable), anyway the rank is known (here Fortran differs from matlab/python). In that case the alternative allocate(A(dim), source=0) is only slightly more complex than zeros or ones. But allocate has the advantage of generalising to any rank, and any value.
2. Using the functions within a right-hand-slide statement (e.g. A = (20.0*ones(2,2) + 5.0), or whatever). In this situation we could simply write A = 20.0 + 5.0. Offhand I can't think of cases where the function call could not be straightforwardly eliminated like this -- what are examples? Another benefit of elimination is that there is less risk of users not noticing that zeros and ones always return integers (as noted in the documentation, it is easy to imagine some users not realising ones(2,2)/2 == 0 -- whereas IMO they are more likely to notice that 1/2 == 0).

This is all I could think of -- and it did make me question whether zeros and ones would be helpful for stdlib -- however I may well be missing important use cases, so would appreciate some discussion.

[zoziha]

Thank you @gareth-nx and everyone who reviewed this PR , I think what you @gareth-nx said makes sense, and I agree to cancel this PR.
My original intention was:

1. Replace allocate(array(2, 2), source=0) to array = ones(2, 2), which is simpler for stdlib_linalg (only for matrix and vector operations).
   And I may want to adapt matlab.ones and numpy.ones too much, and ignore some differences between statically compiled language and dynamic scripting language.
   I will follow the stdlib workflow and discussions about API more.

real, allocatable :: array(:, :)

array = ones(2, 2)
array = ones(3, 4)
---
allocate(array(2, 2), source=1)
deallocate(array)
allocate(array(3, 4), source=1)

Now it seems that it is not necessary. Fortran itself can handle these well, and zeros/ones have some adaptive shortcomings.