<vincenzoml>
I tried to use continuations as typically advised. But it's problematic to do it right, as the recursive call is inside a for statement, that, in my case, is actually a function calling a function (an "iterator" if you wish) called, in fact "iter_post", that is used throughout the project to abstract from the specific implementation of a graph.
<vincenzoml>
And even if I would get this right, which I doubt, I also am concerned that calling a series of closures would not be as efficient as a sequence of functions separated by ';'
<vincenzoml>
any advice?
<Drup>
Sometimes, the simplest way is also the right one: use your own stack. ;)
<companion_cube>
or continuations
<vincenzoml>
yes, I am trying to do that, but ... I thought I could put on the stack just the (only) function argument
<companion_cube>
ah in this case, it's better with an explicit stack though
<vincenzoml>
but that seems not sufficient: I need to execute code "after" the call (that's the whole point) but in order to do the "call" at the right point, I can push the argument on the stack and then restart my iteration
<vincenzoml>
companion_cube: great! I see that I need also a flag on the stack ("enter","exit" in the example)
<vincenzoml>
this must be standard theory of interpreters that I have forgotten
<companion_cube>
it's the state machine you were talking about ^^
segmond has joined #ocaml
<vincenzoml>
yes, clearly! :) thanks. And `Exit(v,cell) takes a pair since "cell" is local data prior to the function call, isn't it?
<companion_cube>
must be something like that, it's been a while
<companion_cube>
yeah, it's associated to v, but it's on the stack to avoid a table lookup, iirc
<vincenzoml>
the only other problem is that for efficiency I was using a stack on top of a bigarray... but then I need to encode flags and tuples manually (how?) and also be able to predict stack usage properly
<vincenzoml>
or I could start with a dynamic stack and then see :)
<companion_cube>
on top of a bigarray?
<companion_cube>
you could have struct-of-arrays
<companion_cube>
(or struct-of-stacks, anyway)
<companion_cube>
one with unsigned 8 bit integers for the flag
<vincenzoml>
yes, true. This means more bigarrays, but on the other hand I expect memory size of a labelled integer to be less than 8+64, is this the case?
<companion_cube>
an integer living in a bigarray has no overhead
<vincenzoml>
yes indeed, what I mean is, if I would use a dynamic stack to see how much it does impact performance, at least I would use less memory or maybe it would not change that much?
maxirater has quit [Quit: Leaving]
<companion_cube>
type state = { mutable vertices: (int, int64_signed_elt) Array1.t; mutable flags: (int, int8_signed_elt) Array1.t; mutable len: int; }
<companion_cube>
^ this can contain both the two stacks (say) + the height of the stack
<companion_cube>
height being used to reallocate arrays if the stack is full
<vincenzoml>
I think I could predict the exact size in the case of Tarjan, but that's an assumption I should check
<companion_cube>
oh, right
<companion_cube>
you could also pair a bigarray for the vertex indices, with a bitset to know if it's enter/exit
<vincenzoml>
well, great, I have to understand this better. Indeed since Tarjan's algorithm also needs other flags (the "onstack" flag) I could as well pack my flags in the same 8-bit array.
<companion_cube>
yeah
<companion_cube>
do you really deal with such huge graphs? :)
psacrifice has joined #ocaml
<Drup>
hum, the algorithm in ocamlgraph is not tail rec
<vincenzoml>
companion_cube: I treat images as graphs, so yes, increasing stack size is not an option :)
<companion_cube>
ouch :D
<companion_cube>
I see
<def`>
vincenzoml: may I ask what is this for? (out of curiosity)
<vincenzoml>
sure, it's a ... spatial model checker, that is, you specify properties of points via logic, and the model checker finds the points satisfying your properties
<vincenzoml>
properties are like "points that are close to points that are surrounded by red points"
<Drup>
I see
<vincenzoml>
but for image analysis we also need operators that deal with textures
<Drup>
this is cool
<vincenzoml>
yes I think so too :)
<def`>
oh cool :)
<vincenzoml>
now I'm in the process of studying an additional fragment of the logical language that deals with connected regions, and that's what led me here
<def`>
(I asked because I also worked with graph algorithms applied on images a long time ago, but in C++ at that time)
<vincenzoml>
def`: we considered that, but ocaml is really a blessing when you don't touch the code for long periods and then come back to it
<companion_cube>
you could have picked rust 0:-)
<Drup>
graphs in rust are a mess
<def`>
Actually... C++ was used for performance, but I like to think (maybe I am wrong) we would have been more efficient with OCaml combinators and good codegen (llvm)
<Drup>
you get lifetime issues in all directions due to the recursive nature of it
<def`>
rust didn't exist at that time. Neither did C++11
<Drup>
or you need up using Rc, and then everything is boxed everywhere, and it's horrible to use
<vincenzoml>
ocaml is good for our purposes performance-wise, but I use static bigarrays for everything. On the other hand, I see CPU usage never gets to 100% in our algorithm and I will soon or later need to find out why
<companion_cube>
Drup: well, not with this particular representation
<companion_cube>
it's encouraging you to use struct-of-arrays and vertices as integers
ryanartecona has joined #ocaml
ryanartecona has quit [Ping timeout: 255 seconds]
ziyourenxiang has joined #ocaml
spew has joined #ocaml
zpe has quit [Remote host closed the connection]
zpe has joined #ocaml
vincenzoml has quit [Quit: Page closed]
cdidd_ is now known as cdidd
freusque has quit [Quit: WeeChat 1.7]
freusque has joined #ocaml
moei has joined #ocaml
moei has quit [Client Quit]
moei has joined #ocaml
sh0t has joined #ocaml
johnelse_ has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 258 seconds]
johnelse has quit [Ping timeout: 240 seconds]
sepp2k has quit [Quit: Leaving.]
sepp2k has joined #ocaml
shinnya has joined #ocaml
sepp2k has quit [Client Quit]
freusque has quit [Quit: WeeChat 1.7]
freusque has joined #ocaml
dmi3y has joined #ocaml
kakadu has quit [Quit: Konversation terminated!]
spew_ has joined #ocaml
spew has quit [Ping timeout: 260 seconds]
spew_ is now known as spew
freusque has quit [Ping timeout: 260 seconds]
MercurialAlchemi has joined #ocaml
freusque has joined #ocaml
zpe has quit [Remote host closed the connection]
ryanartecona has joined #ocaml
ryanartecona has quit [Ping timeout: 260 seconds]
xmonader2 has quit [Quit: Leaving]
dmi3y has quit [Quit: dmi3y]
strykerkkd has joined #ocaml
freusque has quit [Quit: WeeChat 1.7]
shinnya has quit [Ping timeout: 260 seconds]
orbifx-m has quit [Ping timeout: 260 seconds]
alfredo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
psacrifice has quit [Remote host closed the connection]
psacrifice has joined #ocaml
hongbo_ has joined #ocaml
ryanartecona has joined #ocaml
john51 has quit [Write error: Broken pipe]
john51_ has joined #ocaml
al-damiri has joined #ocaml
clockish has quit [Quit: bye]
clockish has joined #ocaml
manizzle has quit [Remote host closed the connection]
jabroney has joined #ocaml
ryanartecona has quit [Quit: ryanartecona]
orbifx-m has joined #ocaml
ryanartecona has joined #ocaml
AltGr has left #ocaml [#ocaml]
g0d355__ has quit [Max SendQ exceeded]
hcarty has joined #ocaml
<hcarty>
Does opam have a way to say "install the dependencies list in this opam file/these opam files" without creating a pin?
alfredo has joined #ocaml
MK__ has quit [Ping timeout: 240 seconds]
orbifx-m has quit [Ping timeout: 260 seconds]
alfredo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
govg has joined #ocaml
copy` has joined #ocaml
maarhart has joined #ocaml
alfredo has joined #ocaml
alfredo is now known as alfredo[away]
alfredo[away] has quit [Client Quit]
alfredo has joined #ocaml
orbifx has joined #ocaml
dmi3y has joined #ocaml
psacrifice has quit [Remote host closed the connection]
freusque has joined #ocaml
freusque has quit [Ping timeout: 260 seconds]
SpiceGuid has joined #ocaml
maarhart has quit [Ping timeout: 240 seconds]
maarhart has joined #ocaml
maarhart has quit [Remote host closed the connection]
argent_smith has quit [Quit: Leaving.]
SpiceGuid has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.46/20161213183751]]
<hcarty>
orbifx: It makes sense to have it in opam too, in part because it would then be included in future compiler compatibility and regression testing
<hcarty>
orbifx: Even if that isn't your primary mode of distribution
<flux>
mrvn, doesn't sound like too difficult to implement, if one can parse the .opam file..
<orbifx>
hcarty: it will be in opam anyway, as a library