For any UK researchers, the #HiddenREF is now open for submissions: https://hidden-ref.org/submissions/
It's a major initiative to shift the culture of research assessment away from things that can be easily measured and towards things that are actually worth doing. Nominate yourself or others!
Categories include:
- Research Citizenship
- Enabling access to facilities
- Software
- "Grimpact" 😆
- ...
Full list of categories here: https://hidden-ref.org/categories/
Intel #oneAPI (first official release December 8, 2020) is a cross-platform toolset that covers several languages including C, C++, Fortran and Python. Intel oneAPI replaces Intel Parallel Studio. Intel oneAPI including the Fortran compiler is free-to-use and no login is required to download oneAPI. The no-cost oneAPI access is distinct from Intel Parallel Studio that requires a paid license, except for instructional use or to develop open source projects.
Ten simple rules for writing a paper about scientific software
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1008390
https://www.reddit.com/r/Open_Science/comments/k5ugsi/ten_simple_rules_for_writing_a_paper_about/?utm_source=ifttt
omg
"Orkestra Obsolete play Blue Monday using 1930s instruments - BBC Arts"
https://www.youtube.com/watch?v=cHLbaOLWjpc
realized just how different and impossible to recreate current music is to anything heard in history
#Music
Raku's junctions reconstructed in #Haskell, and then again in Raku. A sneak preview:
data JType = Any | All | One | None
data Junction a = Junction JType [a]
(•○) :: (a -> b) -> Junction a -> Junction b
(○•) :: Junction (b -> c) -> b -> Junction c
(○○) :: Junction (b -> c) -> Junction b -> Junction (Junction c)
so :: Junction Bool -> Bool
I wrote two new articles, both dealing with junctions in raku.
Junctions are these cool quantum superposition data types that result in auto-threaded computations.
But there is something odd about them, and that is the topic of my first article:
"The strange case of the greedy junction"
https://gist.github.com/wimvanderbauwhede/85fb4b88ec53a0b8149e6c05740adcf8
1. "Cleaner code with functional programming" https://wimvanderbauwhede.github.io/articles/decluttering-with-functional-programming/
2. "Roles as Algebraic Data Types in Raku" https://wimvanderbauwhede.github.io/articles/roles-as-adts-in-raku/
3. "List-based parser combinators in Haskell and Raku" https://wimvanderbauwhede.github.io/articles/list-based-parser-combinators/
4. "Function Types" https://wimvanderbauwhede.github.io/articles/function-types/
5. "Encoding types as functions in Raku" https://wimvanderbauwhede.github.io/articles/universal-interpreter-part-1/
6. "A universal interpreter" https://wimvanderbauwhede.github.io/articles/universal-interpreter-part-2/
Not essential but fun: "Everything is a function" https://wimvanderbauwhede.github.io/articles/everything-is-a-function/
In the past months I have written a series of blog posts on functional programming with a particular (but by no means exclusive) focus on the Raku programming language. If you're curious about functional programming, I think this series might be a good if maybe somewhat challenging and idiosyncratic introduction. It starts with the very basics but covers some more advanced concepts further on.
The suggested reading order would be:
"A theory of functionality is presently being developed, where traditional ideas of data structures are being reformulated in such a way that a structure is now seen as a functional operator missing some if its arguments. For instance, an integer is akin to a for-loop missing its body, a boolean is akin to a conditional missing its pair of branches, etc."
(from
Corrado Boehm and Alessandro Berarducci: Automatic Synthesis of Typed Lambda-Programs on Term Algebras
Theoretical Computer Science, 1985, v39, pp. 135--154. )
Type Safety in Fortran
I'd like to share something I worked out today about type safety in Fortran. It is part of a paper I'm working on and I am quite pleased about it. So you get a sneak preview.
It is not very widely known that venerable old Fortran has higher-order functions. You know, these fancy things functional programming languages have? It also has subtyping and polymorphic functions, but that's another story.
The issue with the higher order functions is how they are typed. When a function f1(x) with type
f1 : t1 -> t2
is passed as argument to a function f2(f), the type of f2 is:
f2 : t2 -> t3
So the type of the argument(s) of f1 is not considered. Which means that we can easily write unsafe code:
t3 function f2(f)
t2 :: f,y
t1 :: x
t4 :: z
logical :: c
...
if (c) then
y = f(x)
else
y = f(z,x)
end if
end function
The f(z,x) call, while patently wrong, will pass silently.
That's a bit not good, but fortunately all is not lost: algebraic data types to the rescue. This is a kind of type used by many functional programming languages, and it allows you to say something like "this type of thingy can either be A or B or C etc". In particular, I am going to use an algebraic data type where every type alternative is a function type, something like
datatype F12 = F1 t1 -> t2 | F2 t4 ->t1 ->t2
Fortran does not have such a type. But with a little trickery we can achieve the same effect.
Fortran requires us to explicitly declare which functions will be used as arguments in code unit. So we can look all functions so declared in a code unit, and make a list of their type signatures:
F12 = [ t1 -> t2 , t4 ->t1 ->t2 ]
The index in this list is a unique identifier for that type, F12[1] refers to the first type, F12[2] to the second.
And now we can do this:
t3 function f2(idx,f)
integer :: idx
t2 :: f,y
t1 :: x
t4 :: z
logical :: c
...
if (c) then
if (idx==1) then
y = f(x)
else
error('Type error!')
end if
else
if (idx==2) then
y = f(z,x)
else
error('Type error!')
end if
end if
end function
And so our higher-order functions are type safe at run time. In practice, the "we" is a refactoring compiler, so the programmer does not need to do anything.
shameless self promotion of my new paper
Our new article is finally published!
'What’s Wrong with Digital Stewardship: Evaluating the Organization of Digital Preservation Programs from Practitioners’ Perspectives"
Basically we (Peggy, Shira, Karl, Julia, and I) asked ~25 digital preservation practitioners about their workplace and the fields' downward workplace satisfaction trend and analyzed their answers.
Article (open access): https://elischolar.library.yale.edu/jcas/vol7/iss1/13
Data (mostly open except the interview transcripts themselves, participant protection): https://data.qdr.syr.edu/dataset.xhtml?persistentId=doi:10.5064/F6DJRPLK
I wrote another article in what is inadvertently becoming a small series on "typed functional programming in Raku":
"Function Types", starring Raku but with a supporting cast of Python, Rust, Haskell, C and even Fortran.
https://wimvanderbauwhede.github.io/articles/function-types/
In case you missed it earlier, I wrote an introduction to functional programming in wonderful Raku and serviceable Python.
https://wimvanderbauwhede.github.io/articles/decluttering-with-functional-programming/
We now have 55 users. Thanks for everyone helping to promote #FediScience.
If you look at my first Toots you will find some tips and tricks to survive in this new jungle.
I wrote an introduction to functional programming in Python and Raku.
https://wimvanderbauwhede.github.io/articles/decluttering-with-functional-programming/
I am extraordinarily pleased to announce a new release of my refactoring source-to-source compiler for FORTRAN 77! So happy!
https://github.com/wimvanderbauwhede/RefactorF4Acc
#coding
#compiler
#introductions
I am a computing scientist at the University of Glasgow in Scotland and my specific interests are compilers for acceleration of scientific code, parallel and heterogeneous programming, GPUs and specifically FPGAs.
λ🐫, -Ofun, compiler writer, FPGA researcher, Computing Scientist at Glasgow University.