JosephRivers has quit [Read error: 110 (Connection timed out)]
Skal has quit [Remote closed the connection]
<pengo>
mikeX: i think you could just make the result plain GPL but i'm not sure. let me know if you work it out
<mikeX>
hmm, ok, it's really the first time I release something with other peoples code, so i'm a bit lost
<pengo>
if you can keep the gpl and lgpl bits seperate (at least in different files) that would be ideal
<pengo>
then they can keep their respective licenses
<mikeX>
hmm, that shouldn't be much of a problem I guess
<mikeX>
guess i'll do that :)
smimou has quit ["bli"]
univac has joined #ocaml
<rillig>
mikeX: The Internet Software Consortium has an MD5 implementation with very permissive license.
<rillig>
download bind8 or bind9 to get it. :)
<rillig>
it's in lib/isc/md5.c
<mikeX>
rillig: i see, well I have no problem with releasing my project as gpl/lgpl, I was just wondering as to what the combination of the two would produce
<mikeX>
I suppose the more restricting one prevails (gpl)
<rillig>
but then you would take some permissions off the LGPL stuff. (Anyway, I'm not sure.)
<mikeX>
well, if I keep the two files separate, as pengo indicated, I can keep both licenses
rillig has quit ["exit(EXIT_SUCCESS)"]
pango__ has joined #ocaml
piggy_ has joined #ocaml
pango_ has quit [Read error: 110 (Connection timed out)]
pengo has quit [Read error: 104 (Connection reset by peer)]
Anarchos has joined #ocaml
mikeX has quit [""zzz""]
<Anarchos>
yeah it's compiling !!! i just wanted to share that with you
Anarchos has quit ["Vision[0.8.5-0418]: i've been blurred!"]
descender has quit ["XML is like violence, if it doesn't solve the problem, just use more."]
skylan_ is now known as skylan
bzzbzz has quit ["leaving"]
bzzbzz has joined #ocaml
__DL__ has joined #ocaml
<lispy>
many of the links in the caml hump are broken
* lispy
thinks an automated link checker would be a good idea
Smerdyakov has quit ["Leaving"]
slipstream has joined #ocaml
slipstream-- has quit [Read error: 110 (Connection timed out)]
_JusSx_ has joined #ocaml
rillig has joined #ocaml
gim has joined #ocaml
_JusSx_ has quit ["leaving"]
Revision17 has quit [Read error: 110 (Connection timed out)]
<twobitsprit1>
this is for finding the neighboring positions on a Go board ("goban")
<mikeX>
go, nice :)
<twobitsprit1>
i.e. in the comment, the neighbors of position 20 are 1, 19, 21 and 39
<twobitsprit1>
but the neighbors of position 19 are only 0, 20 and 38
<twobitsprit1>
the goban is going to be stored in a 1d array for speed, etc. which is why I need the ugly neighbors function...
Skal has joined #ocaml
<Smerdyakov>
It looks like you want an idea of functions with limited domains.
<Smerdyakov>
Then you want a function to apply a list of these functions, keeping only the results that are defined.
<twobitsprit1>
i guess... I'm not sure I understand what you mean
<Smerdyakov>
What do you understand?
<twobitsprit1>
you mean, have a function that computes only the four corner positions, a function that computes only side positions, and then a function that computes center positions with one master function determining which one to call?
<Smerdyakov>
Your first case is represented adequately by (fun _ -> pos mod goban.size = 18, fun _ -> pos + 1). You shouldn't have to type more for it.
<Smerdyakov>
You want a generic function that deals with inputs of this type.
<Smerdyakov>
And I guess you don't even need to make those tuple elements functions.
<twobitsprit1>
hmm
<twobitsprit1>
I wonder if it would just be easier to generate the full set of pos -> neighbors mappings on the outset, and the just loop them up in a hash table...
<twobitsprit1>
s/loop/look
kral has quit [""In girum imus nocte et consumimur igni.""]
<twobitsprit1>
is there a quick way to generate a range? a la python's range(start, end) function?
<pango__>
depends how you represent ranges... if you represent them as a tuple, the function to generate them is short ;)
<Smerdyakov>
twobitsprit1, obviously it's trivial to write a range function that admits that exact syntax.
<twobitsprit1>
pango__: you mean fun x, y -> (x, y) ? :P
<pango__>
right
<pango__>
without the first ,
<twobitsprit1>
heh... I mean, to expand a range to include it's full whole-number set
<Smerdyakov>
twobitsprit1, obviously it's trivial to write a range function that admits that exact syntax.
<twobitsprit1>
Smerdyakov: I know, I was just thinking there might be some syntactic short cut like in haskell, i.e. 4..10
<twobitsprit1>
or something in the stdlib
<pango__>
# let rec range a b = if a > b then [] else a :: range (a+1) b ;;
Anarchos has joined #ocaml
<pango__>
given ranges are not standard types, there's no syntactic sugar for them either
<twobitsprit1>
pango__: I'm sure I could have come up with that... I just didn't want to reinvent the wheel in case there was a standard way of doing it...
<pango__>
btw, using int list may become quickly inefficient
Revision17 has joined #ocaml
<twobitsprit1>
well... functional programming wasn't designed to be efficient, which is why you always end up doing things imperatively anyways when you need efficiency
<pango__>
mmmh
<zmdkrbou>
mmmmmmmmmmmmh
<twobitsprit1>
mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmh?
<zmdkrbou>
functional programming can be efficient
<twobitsprit1>
provided your algorithm can be expressed tail-recursively...
<zmdkrbou>
tail-recursive functions are as efficient as loops
<Smerdyakov>
twobitsprit1, functional programming supports generation of efficient binaries much better than imperative programming.
<twobitsprit1>
Smerdyakov: right, but in a purely functional style, not all loops can be expressed recursively...
<twobitsprit1>
also, randomly indexing lists is much more inefficient than arrays
<twobitsprit1>
I've seen the ocaml code on the shootout, its all imperative...
<twobitsprit1>
well, mostly
<Smerdyakov>
twobitsprit1, Haskell is the current leader.
<twobitsprit1>
in terms of speed?
<twobitsprit1>
ohh, but I hate monads
<Smerdyakov>
No, but close. 3rd place
<Anarchos>
twobitsprit1 you can't compare a paradigm of programamtion (imperative or functional) with a language (C/OCAML) and their implementations (gcc/ocamlc.opt)
<Anarchos>
if you are so interested in efficiency, just stay stuck with your old assembly
<twobitsprit1>
Anarchos: if I was really concerned with speed I wouldn't be in this channel talking about it... :P
<Anarchos>
twobitsprit1 anyway you have also to consider the speed of developing an application ; i have never developed complex data types so fast as in ocaml
<twobitsprit1>
Anarchos: I'm not argueing at all against FP, I'm just saying that I've been under the impression that the focus of FP is not CPU efficiency, but merely programmer efficiency...
<Smerdyakov>
twobitsprit1, you're wrong.
<Anarchos>
sure but for the cpu it depends only on the implementation of the compiler ; nothing to do with the language by itself
<Smerdyakov>
twobitsprit1, I don't think it's long now before no imperative compiler produces faster code than the best few FP compilers.
<twobitsprit1>
you still have the problem that something just don't express well as tail-recursive functions...
<twobitsprit1>
somethings...
<Smerdyakov>
Such as?
<twobitsprit1>
if everything expessed fine as a tail-call, why are there functions in the ocaml stdlib that aren't?
<Smerdyakov>
There is no problem with functions that aren't tail recursive.
<Smerdyakov>
The problem is when the default representation you get with storing partial results on the call stack is less efficient than you could achieve otherwiswe.
<Smerdyakov>
You also have issues with arbitrary decisions in runtime environments to provide much less stack space than heap space.
<twobitsprit1>
you're saying the problem is the current memory model?
<Anarchos>
Smerdyakov i personnaly really miss a concurrent GC !
<pango__>
Anarchos: use caml light ;)
<Smerdyakov>
twobitsprit1, "memory model" usually means something deeper than this.
<Smerdyakov>
twobitsprit1, I encourage you to suggest cases of functions that you think aren't naturally tail recursive and that need to be tail recursive for efficiency reasons.
<Anarchos>
pango__ i know it but too old for me, cause i am interfacing the API of BeOS with the class model of ocaml 3.09 :)
<twobitsprit1>
Smerdyakov: I feel like you're nit-picking at my every choice of words
<Smerdyakov>
twobitsprit1, if so, only because I don't understand your point in a way that leads me to agree with you.
<twobitsprit1>
Smerdyakov: I'll restate... it sounded to me like you were saying the problem would be solved, as long as we had more stack space
<Smerdyakov>
twobitsprit1, no, I'm saying that non-tail-recursive functions have fine behavior in that setting.
<Smerdyakov>
twobitsprit1, I'm asking you to tell me about the cases that you think wouldn't be fine.
<Smerdyakov>
(Make that _some_ non-tail-recursive functions have fine behavior.)
<twobitsprit1>
I've always been under the impression that the burden of proof lies with he who is asserting the universal... I'm merely saying that I'm sure somewhere out there there is an algorithm that does not express well as a tail-call
<Smerdyakov>
twobitsprit1, what does it matter if you can't even think of one with practical importance?
<twobitsprit1>
and even then, at times a tail-call is just a way of shifting the burden from the standard provided stack to a stack that you're creating and passing along in your calls
<Smerdyakov>
twobitsprit1, the win is in the compactness of your custom accumulator.
<twobitsprit1>
i.e. several sorting algorithms which require at most double the size of the thing being sorted
<twobitsprit1>
(when expressed recursively)
<twobitsprit1>
also the problem with algorithms that result in reversed lists, which have to be again reversed to get the desired result
<Smerdyakov>
Of course, there is no asymptotic effect of having to reverse an accumulator.
<twobitsprit1>
asymptotic? excuse my lack of vocabulary
<Smerdyakov>
Are you a CS student?
<Smerdyakov>
(Or have been in the past?)
<twobitsprit1>
ah... I get your point now... I was noticing the "symptom" part, and not the "asymptote" :P
<twobitsprit1>
misread
<twobitsprit1>
but, no I'm not a CS student...
<twobitsprit1>
but, I just feel there are certain situations and algorithms that are best solved imperatively... I'm not against FP, I think it expresses it's own domain very well, but I don't think it's the end-all-be-all of computing that a lot of advocates claim it to be
<pango__>
btw did you notice that ocaml is an unpure functional language ?
<twobitsprit1>
pango__: yes I did
<twobitsprit1>
did I say anything about Ocaml?
<pango__>
that's why I wonder why you immediately mentionned FP to justify poor performance choices
<pango__>
(even not mentionning it is a poor argument in itself)
<twobitsprit1>
scrolling back, this all started when _you_ mentioned that using int lists can be inefficient
<pango__>
because you insisted in not using pairs
<twobitsprit1>
and I was merely acknowledging that a lot of FP habits can be a bit lacking
<twobitsprit1>
when did I insist on not using pairs?
<pango__>
I'm convinced that below syntactic sugar, Python, Perl, etc. represent ranges as pairs
<pango__>
<twobitsprit1> heh... I mean, to expand a range to include it's full whole-number set
<twobitsprit1>
pango__: j;laskdjfl;askjdf;laskjf
<twobitsprit1>
I was pondering aloud, I never said "PYTHON IS BETTER!@#!@#!@#$" or anything... you seem to have a bit of a knee-jerk defense about that kind of stuff...
<pango__>
where ?
<twobitsprit1>
never mind, this is getting out of hand
<twobitsprit1>
text based communication is lame, one can never fully express sarcasm, or playfulness, or any of that... everyone gets all offended and takes you too seriously
<twobitsprit1>
</conversation>
<pango__>
you can try using int lists, for ranges in 0..18 or even 0..360 it should be acceptable
<pango__>
if not, use pairs, or at least lazy lists (not sure about later efficiency...)
<Smerdyakov>
Or often it becomes clear that it is a mistake to use ranges at all, in any representation.
<Smerdyakov>
What you really want are the appropriate higher-order functions.
<pango__>
yup
Anarchos has quit ["Vision[0.8.5-0418]: i've been blurred!"]
<twobitsprit1>
yeah... I'll just hack on it a bit and see what comes up
<twobitsprit1>
I think I'll stick with the method of precomputing all neighbors and storing in a hashtable... if that bottle-necks I'll come up with a better way...
mikeX has quit ["Reconnecting"]
mikeX has joined #ocaml
<pango__>
# let range a b =
<pango__>
let rec aux a b l =
<pango__>
if a > b then l
<pango__>
else aux a (b-1) (b :: l) in
<pango__>
aux a b [] ;;
<Smerdyakov>
pango__, I don't think that helps anyone....
<pango__>
eheh
vodka-goo has quit ["Connection reset by by pear"]
mdales has joined #ocaml
<twobitsprit1>
I find it confusing that the type constructor for tuples is * but the constructor for literal tuples is ,
<twobitsprit1>
I always end up either writing actual tuples with '*' or tuple types with ','...
<mikeX>
twobitsprit1: you rarely need to use the first form
<ski>
i find it good that those use different syntax
<flux__>
twobitsprit1, doesn't it strike you any strange to enter a tuple as (4 * 3) ?-)
<twobitsprit1>
mikeX: I do when defining types
<twobitsprit1>
flux__: heh, yeah... but I find it stranger to write (int * int)...
<mikeX>
exactly twobitsprit1, that shouldn't be very often :P
<flux__>
twobitsprit1, well, I think it comes from the mathematical notation of cartesian product
<twobitsprit1>
mikeX: right, but it still gets me
<flux__>
s/notation/idea/
<mikeX>
twobitsprit1: you'll get used to it :)
<twobitsprit1>
flux__: ahh... I still don't get it :P
<twobitsprit1>
<-- not a math major
<twobitsprit1>
(and I'm not looking for an explanation either, might just confuse me more :P)
<mikeX>
hehe
<mikeX>
true
<twobitsprit1>
the type signature for references is the same as the value constructor? i.e. "int ref" and "4 ref", right?
<twobitsprit1>
or is it, "ref 4"?
<pango__>
ref 4 is an int ref
<twobitsprit1>
thx
univac is now known as antoszka
antoszka is now known as univac
<ski>
if one used ',' for product types, then how would the type "(t0,t1) t2" be parsed ?
<ski>
a type constructor 't2' applied to the product type of 't0' and 't1' ?
<ski>
or a type constructor 't2' applied to the pair of types 't0' and 't1' ?
<ski>
(those are different)
<Smerdyakov>
ski, Haskel solves this problem by using uniform parsing for types and values.
<ski>
?
<Smerdyakov>
ski, MyType a b instead of (a, b) MyType.
<ski>
i thought haskell solved this by not having type tuples (instead using currying for multiple args)
<ski>
yes
<Smerdyakov>
Nope.
<Smerdyakov>
Or I guess I read that as "tuple types" instead of "type tuples."
<Smerdyakov>
But ML doesn't have type tuples, either. It's just syntax.
<ski>
right
<ski>
but it would fit better with any possible extension
<Smerdyakov>
What would?
<ski>
not using "(... , ...)" notation for product types
<Smerdyakov>
OK, I agree.
<ski>
(so that you could use that for type tuples instead, i.e.)
<JosephRivers>
I want a version of "not equals" where that will evaluate to false.
<smimou>
<> then
<mikeX>
= goes with <>, == goes with !=
<JosephRivers>
Ah, okay. Thanks
<Smerdyakov>
JosephRivers, perhaps the problem is that you assume 64-bit integers are unboxed?
kral has joined #ocaml
<Smerdyakov>
JosephRivers, it is possible for int64's to be = but not ==.
<JosephRivers>
I see. Thanks for the help.
JosephRivers has quit [Remote closed the connection]
<mdales>
Possibly dumb question of the day, but do I need to do more that have a module in `ocamlc -where`/lib/ocaml for ocaml to pick it up? I did make install on a module and it seems to be there, but when I try and use it ocaml gives me an undefined global error
<mikeX>
mdales: where/how do you try to use it?
<mikeX>
e.g. you have to do 'ocamlc modulename.cma file.ml -o file' if you want to use it in file.ml
<mdales>
well, I installed xml-lite, and tried their example of just "let x = Xml.parse_string..." in the interpreter
<mikeX>
in the toploop, you have to write '#load "modulename.cma"' before you can use it
<mdales>
ah
<mikeX>
furthermore, it may require a -I +path_to_module flag
<mdales>
cool
<mdales>
that worked
<mdales>
thanks for helping reduce the set of things I'm ignorant about
<mikeX>
:)
<twobitsprit1>
do you ever feel like you're reinventing a database when you program?
<Smerdyakov>
When I do, I switch to using Postgres.
<twobitsprit1>
I'm trying to implement a legal move analyser (for a Go program) and instead of find every touching string of stones for every move to see if they live or die, I'm trying to keep all that information around and just incrementally adjusting it, and it a strings set of liberties becomes empty, it's captured... but this is becoming a very messy relational problem...
_JusSx_ has joined #ocaml
<twobitsprit1>
Smerdyakov: right well... I don't want to have a full db backend to my little go program... that and I've had my fill of SQL code
<Smerdyakov>
SQL is awesome.
<pango>
could union-find algorithm help to implement chains ?
<Smerdyakov>
The best mainstream computer language ever.
<twobitsprit1>
I know there's like sqlite or something, but I still hate having long strings of SQL code embedded in my code
<Smerdyakov>
twobitsprit1, I'm working on integrating SQL with ML-style static typing.
<twobitsprit1>
pango: I don't know, could it? (I'm not familiar)
<twobitsprit1>
Smerdyakov: that still doesn't help me not have to set up an SQL server just to determine if a move is legal or not
<twobitsprit1>
keep in mind, these games probably aren't going to last much longer than a few minutes