This question already has answers here:
Program crash for array copy with ifort
(2 answers)
How can I avoid a stack overflow when Fortran produces a large, internal, temporary array?
(1 answer)
Stack overflow in Fortran 90
(6 answers)
Closed 4 years ago.
I'm experiencing some problems which appear to be from memory handling in my code. I've managed to isolate the problem in the following example. It returns a segmentation fault (core dumped) at iteration 1024 (that's why I started the loop at 1000) when compiling it with intel but not with gfortran. If the call to the function is commented out, the call to the subroutine will keep working at least to the end of the loop. The theory is that when calling the function, gfortran is fetching the memory for Dmat from the heap, whereas intel is fetching it from the stack.
Is this the case? Is something else happening? This would mean that in order for my code to scale adequately and support intel compilation, I have to define all my procedures as subroutines and just give up on functions?
Test case:
module auxmod
implicit none
contains
function matmul3_fun( Amat, Bmat, Cmat ) result( Dmat )
implicit none
real*8, intent(in) :: Amat(:,:)
real*8, intent(in) :: Bmat(:,:)
real*8, intent(in) :: Cmat(:,:)
real*8 :: Dmat( size(Bmat,1), size(Bmat,2) )
real*8, allocatable :: Emat(:,:)
allocate( Emat( size(Bmat,1), size(Bmat,2) ) )
Emat = matmul( Amat, Bmat )
Dmat = matmul( Emat, Cmat )
end function matmul3_fun
subroutine matmul3_sub( Amat, Bmat, Cmat, Dmat)
implicit none
real*8, intent(in) :: Amat(:,:)
real*8, intent(in) :: Bmat(:,:)
real*8, intent(in) :: Cmat(:,:)
real*8, intent(out) :: Dmat( size(Bmat,1), size(Bmat,2) )
real*8, allocatable :: Emat(:,:)
allocate( Emat( size(Bmat,1), size(Bmat,2) ) )
Emat = matmul( Amat, Bmat )
Dmat = matmul( Emat, Cmat )
end subroutine matmul3_sub
end module auxmod
program size_overflow
use auxmod
implicit none
real*8, allocatable :: Amat(:,:)
real*8, allocatable :: Bmat(:,:)
real*8, allocatable :: Cmat(:,:)
real*8, allocatable :: Dmat(:,:)
integer :: kk
do kk=1000, 2000
allocate ( Amat(kk,kk), Bmat(kk,kk), Cmat(kk,kk), Dmat(kk,kk) )
Amat(:,:) = 1.d0
Bmat(:,:) = 2.d0
Cmat(:,:) = 3.d0
call matmul3_sub( Amat, Bmat, Cmat, Dmat )
write(*,*) "SUB works for size = ", kk
Dmat = matmul3_fun( Amat, Bmat, Cmat )
write(*,*) "FUN works for size = ", kk
deallocate( Amat, Bmat, Cmat, Dmat )
end do
end program size_overflow
Related
I have a OTP - 19.3.6 environment.
I am trying to use a library that depends on OTP - 22.
So, I am trying to use and write compatibilities to use that library.
For eg. I ran into string:lowercase and unicode_util, issues, so I found a compat lib to get past those issues: https://github.com/benoitc/unicode_util_compat
Then I ran into maps:iterator and maps:next issues.
Based on my limited erlang understanding, I tried to write maps_compat.erl
I got past maps:iterator and maps:next issues.
However, I got this error where map_next is erts_internal.erl function:
Stacktrace =
** [{erlang,nif_error,[undefined],[]},
{maps_compat,map_next,3, [{file,"../apns_v2_otp_19.3.6/_build/default/lib/xxx/src/maps_compat.erl"}
from https://github.com/erlang/otp/blob/master/erts/preloaded/src/erts_internal.erl
%% return the next assoc in the iterator and a new iterator
-spec map_next(I, M, A) -> {K,V,NI} | list() when
I :: non_neg_integer(),
M :: map(),
K :: term(),
V :: term(),
A :: iterator | list(),
NI :: maps:iterator().
map_next(_I, _M, _A) ->
erlang:nif_error(undefined).
I modified the above function in my maps_compat.erl as
%% return the next assoc in the iterator and a new iterator
-spec map_next(I, M, A) -> {K,V,NI} | list() when
I :: non_neg_integer(),
M :: map(),
K :: term(),
V :: term(),
A :: iterator | list(),
NI :: iterator().
map_next(_I, _M, _A) ->
erlang:nif_error(undefined).
but it failed with the error above.
Can this issue be fixed?
If so, how can I fix this?
Is there a maps_compat library already such as unicode_util_compat?
Please help me resolve this issue.
As per suggestion in https://github.com/erlang/otp/issues/4595, I implemented this to not get this error anymore.
maps_iterator(Map) ->
maps:to_list(Map).
maps_next([{K,V} | T]) ->
{K, V, T};
maps_next([]) ->
none.
I'm trying to define a greedy function
greedy :: ReadP a -> ReadP [a]
that parses a sequence of values, returning only the "maximal" sequences that cannot be extended any further. For example,
> readP_to_S (greedy (string "a" +++ string "ab")) "abaac"
[(["a"],"baac"),(["ab","a","a"],"c")]
I'm using a very simple and probably clumsy way. Just parse the values and see if they can be parsed any further; if so, then reapply the function again to get all the possible values and concat that with the previous ones, or else just return the value itself. However, there seems to be some type problems, below is my code.
import Text.ParserCombinators.ReadP
addpair :: a -> [([a],String)] -> [([a],String)]
addpair a [] = []
addpair a (c:cs) = (a : (fst c), snd c ) : (addpair a cs)
greedy :: ReadP a -> ReadP [a]
greedy ap = readS_to_P (\s ->
let list = readP_to_S ap s in
f list )
where
f :: [(a,String)] -> [([a],String)]
f ((value, str2):cs) =
case readP_to_S ap str2 of
[] -> ([value], str2) : (f cs)
_ -> (addpair value (readP_to_S (greedy ap) str2)) ++ (f cs)
The GHC processes the code and says that function "f" has type [(a1,String)] -> [([a1],String)] but greedy is ReadP a -> ReadP [a]. I wonder why it is so because I think their type should agree. It also really helps if anyone can come up with some clever and more elegant approach to define the function greedy(my approach is definitely way too redundant)
To fix the compilation error, you need to add the language extension
{-# LANGUAGE ScopedTypeVariables #-}
to your source file, or pass the corresponding flag into the compiler. You also need to change the type signature of greedy to
greedy :: forall a. ReadP a -> ReadP [a]
This is because your two a type variables are not actually the same; they're in different scopes. With the extension and the forall, they are treated as being the same variable, and your types unify properly. Even then, the code errors, because you don't have an exhaustive pattern match in your definition of f. If you add
f [] = []
then the code seems to work as intended.
In order to simplify your code, I took a look at the provided function munch, which is defined as:
munch :: (Char -> Bool) -> ReadP String
-- ^ Parses the first zero or more characters satisfying the predicate.
-- Always succeeds, exactly once having consumed all the characters
-- Hence NOT the same as (many (satisfy p))
munch p =
do s <- look
scan s
where
scan (c:cs) | p c = do _ <- get; s <- scan cs; return (c:s)
scan _ = do return ""
In that spirit, your code can be rewritten as:
greedy2 :: forall a. ReadP a -> ReadP [a]
greedy2 ap = do
-- look at the string
s <- look
-- try parsing it, but without do notation
case readP_to_S ap s of
-- if we failed, then return nothing
[] -> return []
-- if we parsed something, ignore it
(_:_) -> do
-- parse it again, but this time inside of the monad
x <- ap
-- recurse, greedily parsing again
xs <- greedy2 ap
-- and return the concatenated values
return (x:xs)
This does have the speed disadvantage of executing ap twice as often as needed; this may be too slow for your use case. I'm sure my code could be further rewritten to avoid that, but I'm not a ReadP expert.
I found the below type specification in Erlang module. I am trying to understand how is it used? Is it similar to record?
-type timestamp() :: {MegaSecs :: non_neg_integer(),
Secs :: non_neg_integer(),
MicroSecs :: non_neg_integer()}.
I found the below type specification in Erlang module. I am trying to
understand how is it used? Is it similar to record?
-type timestamp() :: {MegaSecs :: non_neg_integer(),
Secs :: non_neg_integer(),
MicroSecs :: non_neg_integer()}.
No, it is a user defined type.
...types can be used to specify types of record fields and also the
argument and return types of functions.
Type information can be used for the following:
To document function interfaces
To provide more information for bug
detection tools, such as Dialyzer
To be exploited by documentation
tools, such as EDoc, for generating program documentation of various
forms
For more information about types, see:
http://erlang.org/doc/reference_manual/typespec.html
and:
https://learnyousomeerlang.com/dialyzer
Here is an example:
-module(a).
-compile(export_all).
-type timestamp() :: {MegaSecs :: non_neg_integer(),
Secs :: non_neg_integer(),
MicroSecs :: non_neg_integer()}.
-record(bill, {name :: string(),
amount :: non_neg_integer(),
date :: timestamp()
}
).
-type bill() :: #bill{}.
-spec payment_due(bill()) -> timestamp().
payment_due(Bill) ->
{Mega, Sec, Micro} = Bill#bill.date,
{Mega+1, Sec, Micro}.
In the shell:
1> c(a).
a.erl:2: Warning: export_all flag enabled - all functions will be exported
{ok,a}
2> rr(a).
[bill]
3> Bill = #bill{name="John", amount=30, date={3, 2, 1}}.
#bill{name = "John",amount = 30,date = {3,2,1}}
4> a:payment_due(Bill).
{4,2,1}
Dialyzer:
~/erlang_programs$ dialyzer --build_plt --apps erts kernel stdlib crypto mnesia sasl commotest eunit
Compiling some key modules to native code... done in 0m35.60s
Creating PLT /Users/7stud/.dialyzer_plt ...
...
...
done (passed successfully)
~/erlang_programs$ dialyzer a.erl
Checking whether the PLT /Users/7stud/.dialyzer_plt is up-to-date... yes
Proceeding with analysis... done in 0m0.15s
done (passed successfully)
Good day, ladies and gentlemen!
I'm constantly writing parsers and codecs. Implementing both parsers and printers seems to be massive code duplication. I wonder whether it is possible to invert a stateful computation, given it is isomorphic by nature.
It is possible to invert pure function composition (Control.Lens.Iso did that by defining a composition operator over isomorphisms). As it can be observed,
Iso bc cb . Iso ab ba = Iso (bc . ab) (ba . cb) -- from Lenses talk
invert (f . g) = (invert g) . (invert f) -- pseudo-code
In other words, to invert a function composition one should compose inverted functions in the opposite order. So, given all primitive isomorphic pairs are defined, one can compose them to get more complicated pairs with no code duplication. Here is an example of pure bidirectional computation (Control.Lens is used, the explanatory video can help you to get the general idea of Lenses, Folds and Traversals):
import Control.Lens
tick :: Num a => Iso' a a
tick = iso (+1) (subtract 1) -- define an isomorphic pair
double :: Num a => Iso' a a
double = iso (+2) (subtract 2) -- and another one
threeTick :: Num a => Iso' a a
-- These are composed via simple function composition!
threeTick = double . tick
main :: IO ()
main = do
print $ (4 :: Int)^.tick -- => 5
print $ (4 :: Int)^.from tick -- => 3
print $ (4 :: Int)^.threeTick -- => 7, Composable
print $ (4 :: Int)^.from threeTick -- => 1, YEAH
As you can see, I didn't need to supply the inverted version of threeTick; it is obtained by backward composition automatically!
Now, let's consider a simple parser.
data FOO = FOO Int Int deriving Show
parseFoo :: Parser FOO
parseFoo = FOO <$> decimal <* char ' '
<*> decimal
parseFoo' :: Parser FOO
parseFoo' = do
first <- decimal
void $ char ' '
second <- decimal
return $ FOO first second
printFoo :: FOO -> BS.ByteString
printFoo (FOO a b) = BS.pack(show a) <>
BS.pack(" ") <>
BS.pack(show b)
main :: IO ()
main = do
print $ parseOnly parseFoo "10 11" -- => Right (FOO 10 11)
print $ parseOnly parseFoo' "10 11" -- => Right (FOO 10 11)
print . printFoo $ FOO 10 11 -- => "10 11"
print . parseOnly parseFoo . printFoo $ FOO 10 11 -- id
You can see that both versions of parseFoo are fairly declarative (thanks to parser combinators). Note the similarity between parseFoo and printFoo. Can I define isomorphisms over primitive parsers (decimal and char) and then just derive the printer (printFoo :: FOO -> String) automatically? Ideally, parser combinators will work as well.
I tried to redefine a monadic >>= operator in order to provide inverted semantics, but I've failed to do so. I feel that one could define inverted Kleisli composition operator (monadic function composition) similarly to composition inversion, but can one use it with ordinary monads?
f :: a -> m b, inverse f :: b -> m a
g :: b -> m c, inverse g :: c -> m b
inverse (f >=> g) = (inverse f) <=< (inverse g)
Why inverse f is of type b -> m a and not m b -> a? The answer is: monadic side effect is an attribute of an arrow, not that of a data type b. The state monad dualization is further discussed in the great Expert to Expert video.
If the solution does exist, could you please supply a working example of printFoo derivation? By the way, here is an interesting paper that could help us find the solution.
You may be interested in digging in further into the lens package for the concept of a Prism.
A Prism can be used as a 'smart constructor' to build something (e.g. a pretty printed string) unconditionally, and match on it (e.g. parse).
You'd have to ignore the laws or treat the laws as holding only up to a quotient though, as the string you get out of pretty printing is very likely not exactly the string you parsed.
I want to calculate a derived data type in a subroutine (or function). How would I reference the variable in the subroutine arguments?
So far, I can achieve my objective by referencing the entire object, then referencing the variable inside the subroutine. Is there a way to reference only the variable myObj%var in the subroutine arguments?
PROGRAM test
TYPE obj
INTEGER :: var
END TYPE obj
TYPE (obj) :: myObj
CALL set(myObj)
PRINT*, myObj%var
CONTAINS
SUBROUTINE set(myObj)
TYPE (obj) :: myObj
myObj%var = 5
END SUBROUTINE set
END PROGRAM test
You could simply write
SUBROUTINE set(an_int)
integer, intent(inout) :: an_int
an_int = 5
END SUBROUTINE set
and then call the subroutine like this:
CALL set(myObj%var)
My opinion that it is perverse to package components into derived types and then unpack them to pass to procedures is just an opinion, you are free to ignore it. Personally I'd go with a more radical rewrite of your code, something like the following. Be warned though that this uses some features introduced in the 2003 standard, though these are implemented in current editions of the most widely used compilers.
MODULE mytype
IMPLICIT NONE
TYPE obj
INTEGER, PRIVATE :: var
CONTAINS
PROCEDURE, PASS :: get_var
PROCEDURE, PASS :: set_var
END TYPE obj
CONTAINS
SUBROUTINE set_var(this,an_int)
CLASS(obj), INTENT(inout) :: this
INTEGER, INTENT(in) :: an_int
this%var = an_int
END SUBROUTINE set_var
INTEGER FUNCTION get_var(this)
CLASS(obj), INTENT(inout) :: this
get_var = this%var
END FUNCTION get_var
END MODULE mytype
PROGRAM test
USE mytype
IMPLICIT NONE
TYPE (obj) :: myObj
CALL myobj%set_var(12)
PRINT*, myObj%get_var()
END PROGRAM test
If you only have an F95 compiler without all the 2003/2008 bits, this is how it can be done.
MODULE ObjMod
IMPLICIT NONE
TYPE ObjType
INTEGER, PRIVATE :: var
END TYPE ObjType
CONTAINS
SUBROUTINE ObjCreate(this)
TYPE(ObjType), POINTER :: this
allocate(this)
END SUBROUTINE ObjCreate
SUBROUTINE ObjDelete(this)
TYPE(ObjType), POINTER :: this
deallocate (this)
END SUBROUTINE ObjDelete
SUBROUTINE ObjSet(this, value)
TYPE(ObjType), INTENT(inout) :: this
INTEGER, INTENT(in) :: value
this%var = value
END SUBROUTINE ObjSet
INTEGER FUNCTION ObjGet(this)
TYPE(ObjType), INTENT(inout) :: this
ObjGet = this%var
END FUNCTION ObjGet
END MODULE ObjMod
PROGRAM test
USE ObjMod
IMPLICIT NONE
TYPE (ObjType), POINTER :: testObj
CALL ObjCreate(testObj)
CALL ObjSet(testObj, 12)
PRINT*, ObjGet(testObj)
CALL ObjDelete(testObj)
STOP
END PROGRAM test
I also used to code like that in C in the early 80s before a decent C++ compiler came out. What you will find is that many systems written in the 70s up to the early 90s use this technique. It will work in any language that supports structures and dynamic memory allocation.