@amiloradovsky I don't think so, it was something someone made using those (I assume). But it was an example of what was possible rather than a theory

I checked, just in case, but didn't find anything

Some time ago, I saw a toot with a link to a #Coq proof involving real numbers, but I can't find it anymore :(

I think it was about proving that the ratio of two Fibonacci numbers converges to the golden ratio, but I'm not sure.

Anyone remembers it and knows where I can find it?

#SILE hacking: finally got around to writing a little grammar for writing math in a TeX-like style (left) rather than in MathML directly (right).

Which one do you prefer? 😜

Amazon rainforest rant

If your stance on the Amazon burning is that "humans are a plague", when indigenous humans have been defending and maintaining the forests for THOUSANDS of years, your take is lazy and reductive.

The enemies are colonialism, imperialism, and capitalism, and especially Bolsonaro.

More cuuuuurves

@otini The small-angle approximation is a lie

I wanted to explain the code you get in Haskell to write this sort of model, but it's actually quite tricky to explain in a toot^^

Hopefully I'll write a blog post about this when this is more polished

Cuuuuurves

Forgot the units, it's radian for the angle and radian per second for the angle's variation

More cuuuuurves

On the previous graph, the curves kind of looked like sine wave because the angles remain small. But, this isn't true anymore for larger angle, as illustrated by the result one gets if the pendulum is released from 3π/4 radian (135 ° from the vertical)

Show thread

Cuuuuurves

So now I can make graphs like this and write my equations in #Haskell!

This is the result of a simulation of the movement of a frictionless pendulum, suspended to a 1 m rod for 10 s. It starts with no velocity at an angle of π/6 with the vertical. The solver returns every 0.1 second. Blue curve is the angle over time, orange curve is the derivative of the angle over time.

Show thread

It's not perfect, for instance, I still have one weird problem with the types of some function pointers not being imported correctly. But, while I didn't test anything until I had done everything, I haven't had any segfault or unexpected result with the generated bindings, and I find that pretty impressive!

So after a few days at working with #c2hs to make bindings to #sundials in #haskell, I'm actually impressed by it.

It's a tool to help with writing bindings to C library. It can generate a lot of the boilerplate associated with this sort of stuff (e.g., generating wrapper types on the Haskell side) and typechecks the FFI imports by analyzing the C types in the library's headers.

re: Haskell question, C bindings and c2hs

Everything I've tried has failed, either because I can't use void* as the type of some hooks (either it can't parse it, or it complains it's not declared anywhere or it just fails with an internal error, depending on the hook I try to use).

Does anyone know if there's a way around the problem, or if I'm just condemned to use Ptr () for this?

Haskell question, C bindings and c2hs

I'm trying to use #c2hs to generate bindings to #sundials.

Sundials has a function IDACreate, wish allocates a block of memory to then pass around. This block of memory is simply of type void*

When I import this function with c2hs, I would like to make the Haskell version return a newtype wrapper around the pointer, but c2hs doesn't let me do that.

PhD student at the University of Nottingham ⋅ Interested in functional programming (Haskell, OCaml), modeling languages and synchronous languages

Joined Jan 2018