<adrien>
thelema: sorry to ask you direcly, in BatIMap, is there a way to get the range one point is a member of? say, if I store 42 in the 10..20 range, I'd like to recover "10" and "20" when giving "17"
<thelema>
adrien: not at the moment.
<adrien>
thelema: ok, or to know that 13 and 17 are in the same bin?
<thelema>
You can/should create a modified get (maybe get_range) that does this
<flux>
adrien, if you sure 10..15 and 16..20, would 15 give you 10..15 and 16 16..20?
<flux>
(would->should)
<adrien>
flux: yes, something like that
<flux>
I guess batIMap is not for that, then?
<flux>
maybe you can put the end points into the associated value?
<thelema>
flux: no, that wouldn't work
<adrien>
thelema: ok, at this point it's optimization so I'm not going to do it today but it's probably going to be done at some point during the week
<adrien>
(that can save thousands of calls to Cairo)
<flux>
thelema, well, you would need to post process the data to find if the range is still 'valid', but I guess it still problematic
<thelema>
adrien: ok.
<thelema>
flux: adding a single value to an imap can collapse two ranges that almost touch into a single range
<thelema>
s/value/mapping/
<flux>
oh, ok
<thelema>
that single mapping doesn't have to be part of either range, just adjacent to both
sebz has quit [Quit: Computer has gone to sleep.]
avsm has quit [Quit: Leaving.]
sebz has joined #ocaml
<flux>
there should be a custom range merging function?-)
<flux>
unfortunately functors cannot have optional module parameters, so it's difficult to extend them..
dnolen has quit [Quit: dnolen]
avsm has joined #ocaml
<adrien>
is there a function in the ocaml-shipped libraries to convert a float into milliseconds+seconds+minutes+hours?
<flux>
I doubt that. should be a matter of some division?
<flux>
(and modf)
<thelema>
adrien: Unix.gmtime and Unix.localtime, except you'll have to deal with the fractions of a second
<flux>
I was thinking he wanted that for intervals, not absolute time, but perhaps I was wrong?
<thelema>
flux: as long as the interval is less than a month, gmtime will give the right answer, just ignore year, month, date
<flux>
thelema, good idea :)
<flux>
I guess it works nevertheles?
<flux>
for those values
<thelema>
for x < 86400
<thelema>
probably still fine for x < 86400 * 31
<thelema>
more than that - divide, remainder, divide, remainder, etc.
<flux>
why would it break after a month?
<adrien>
that's what I had thought of at first but it didn't give me the miliseconds, so I'm probably not blind and it doesn't exist, thanks :-)
<flux>
or after any point in time, in fact
<flux>
adrien, you can handle milliseconds separately with modf
<qdl>
Hi, there. Since the syntax of this sprintf stiff is awful, I'd like to have a wrapper around it. I'd like to have aometinh like
<thelema>
flux: it would be nontrivial to convert months + days + hours back to hours
<thelema>
flux: days + hours is still prectical
<flux>
thelema, ah, right
<flux>
in any case, it's not a whole lot more difficult to divide etc :)
<qdl>
float_to_string x n which should work like Printf.sprintf "%.nf" x
<thelema>
qdl: let float_to_string x n = Printf.sprintf "%.*f" n x
eb4890 has joined #ocaml
<qdl>
Writing something like Printf.sprintf "%.5f" 0.0012344 makes me assume sprintf could have type string -> float -> string
<qdl>
Which isn't true.
<qdl>
# Printf.sprintf;;
<qdl>
- : ('a, unit, string) format -> 'a = <fun>
<flux>
it's maaaagiiic
sebz has quit [Quit: Computer has gone to sleep.]
<thelema>
qdl: printf format strings are magic; part of their type is the types and order of all following arguments
<flux>
it's sort of interesting mechanism. somehow it knows the type of the function and then knows it can do special handling of the string argument.
<qdl>
thelema: aha. I prefer proper type concepts. That's why i use OCaml and no nonsense language like C.
<flux>
those kind of decisions are not seen anywhere else
<qdl>
flux: Who or what is "it" in this context?
<flux>
but tranformation itself I believe is implemented with CPS. in principle you can do it yourself, but not with as neat syntax.
<flux>
qdl, the way it works
<flux>
oh, and latter, the compiler
<qdl>
Sounds a bit esoteric to me.
<flux>
maybe it is. but I guess it's a nod towards C coders. printf is just so darn nice ;).
<flux>
perhaps there's thinking like "we can do it too, but better!" (for some value of better)
<qdl>
"The way it works decides this or that ..." blablblubb "magic" Don't try to understand it. Omar tazatt.
Boscop has joined #ocaml
<flux>
there's a great white paper on how to do similar structures
<flux>
was it called unparsing something?
<qdl>
If this is nice, I don't wanna see ugly stuff.
<qdl>
I'll take a look at it after reading that paper.
<qdl>
Thanks so far.
<flux>
good luck :)
<thelema>
qdl: arguments of type format are written as literal strings. The connection between the type of a literal string and the format type it represents is in essence the meaning of that format string as a *printf argument
<qdl>
Aha.
<adrien>
also, is there a function to turn up to 4 bytes from a string into an int/Int32.t?
<flux>
batteries has Int32.unpack(_big)
<adrien>
so nothing in the standard library, and batteries' is pretty much like what I was doing with Char.code
<thelema>
adrien: yup, that's the way to do it.
<flux>
but if that's all you want from batteries, perhaps better go with let int32_of_string x = Int32.(of_int (Char.code x.[0]) + of_int (Char.code x.[1]) lsl 8 ..)
lopex has quit []
<adrien>
flux: well, I had to copy BatIMap and BatAvlTree too ;-)
* adrien
hates windows
<flux>
adrien, slowly but surely you'll be porting batteries to compile nicely for windows ;)
<adrien>
btw, I'm pretty pleased with BatIMap's performance :-)
<thelema>
adrien: on my todo list is producing a windows executable for a program I've written for batteries. I'm stuck at getting findlib to install.
<adrien>
flux: yeah, most probably ;-)
<adrien>
thelema: findlib? iirc it wasn't a problem
<adrien>
on the other hand, I've installed yypkg's dependencies with cp on windows
<thelema>
adrien: to be honest, you should thank the author of camomile, yoriyuki, for writing IMap (and ISet)
<adrien>
put them right next to the stdlib's .cm* files
<adrien>
ah, it's him? on thing that I'm trying to avoid with Batteries on windows is actually camomile :P
<thelema>
adrien: if that's all, use batteries v2 - it has no external dependencies
<adrien>
thelema: do you remember how BatIMap works? and how the ?eq parameter is used?
<thelema>
on findlib/win: "Fatal error: cannot load shared library dllunix ... cannot be found"
<thelema>
adrien: yes, I use batIMap a lot. ~eq is for deciding whether two ranges can be merged
<adrien>
thelema: that and the fact that I'll have to install one thing which means that 'cp' is _way_ easier for now unfortunately
<thelema>
to merge (0,5,a) (6,10,b), one must be able to tell whether a and be are the same
<thelema>
I've had the bad habit of using sets and other maps as the values in imap, so...
<thelema>
I've needed my own comparison function to merge properly
<adrien>
thelema: I've removed that in my application since I'm already doing it (I'm only appending), do you think that means I have to publish the changes? (they're really trivial)
<adrien>
hahaha :-)
<adrien>
strictly speaking, I have to, but these are _really_ trivial changes
<thelema>
adrien: by the letter of the license, you'll have to publish the modifications to IMap.
<thelema>
but I wouldn't worry about it.
<adrien>
ok, thanks
<thelema>
the person whose permission you should get is yoriyuki, though.
<adrien>
yes, of course
<thelema>
well, you'll have to make your modifications to IMap available to anyone who gets the resulting code.
<thelema>
that doesn't mean full publication.
<adrien>
getting licensing right is hard, and I'll have to mention which LGPL libraries are in use which is something I was about to forget
<thelema>
just that they have the right to ask for the source.
<adrien>
only modifications for LGPL? I thought it meant whole source
<thelema>
I don't think LGPL requires attribution.
<thelema>
I don't mean modifications like QPL, I mean you don't have to make your modified source any more pubilc than your executable that uses them
<adrien>
*DIE* seamonkey, *DIE*
<adrien>
ah, ok, as I thought then
<thelema>
i.e. if you only use the code internal to a company, you don't have to share the brilliant improvements to imap
<adrien>
no, I'll just put the whole sources along with it, I'm not going to try to do anything (now, the boss...)
<thelema>
as much as it's nice to keep the sources with the executable, it's sufficient to make the sources available.
<adrien>
I hope noone will ask for them thinking they'll discover terrific secrets when all I've done is assume eq always returns "false" (which meant some tests could be removed)
<thelema>
?? eq always returning false means no merging
<adrien>
I hope that for them because it'd take more time to ask for the sources, get them, read them
<adrien>
thelema: yes, I'm actually in a situation where there can be no merging because I'm only adding something once I know my data changes
<thelema>
i.e. if you have the imap: (1,4,a) and add the binding (5,a), you have (1,4,a) (5,5,a) instead of (1,5,a)
<adrien>
so I keep a counter and a value and add_range only when the value has to change
<thelema>
I'll trust you know what you're doing.
<adrien>
I'm adding in a linear fashion and that means I can delay the add until it is really needed (I get 5;5;5;5;8;8, so I remember that I'm currently at "5" and when I get to "8", I do the add)
<adrien>
it was like that in the code before and it's going to require way less operations
<thelema>
do you really need an interval map, then?
<thelema>
ah, you still need the ability to query (5,7) for 6
<thelema>
you might want to use a regular map and a funny compare function
<adrien>
right, that would work too
<adrien>
that also makes more sense :-)
<thelema>
let compare (a,b) (c,d) = if b < c then 1 else if c > b then -1 else 0
<adrien>
definitely thought of something too complicated ;-)
<adrien>
that includes mentionning the library is in-used
<adrien>
use*
<thelema>
adrien: okay then. I guess you have to put a note in the docs.
larhat has quit [Quit: Leaving.]
<adrien>
I should start doing that even for my GPL- and BSD-licensed stuff too
ankit9 has quit [Quit: Leaving]
bobry has quit [Quit: Leaving.]
Boscop has quit [Ping timeout: 250 seconds]
Boscop has joined #ocaml
Boscop has quit [Changing host]
Boscop has joined #ocaml
<thelema>
map3d: 'a -> ('a -> 'a -> 'a -> 'b) -> 'a list -> 'a list -> 'a list -> 'b list
avsm has quit [Read error: Operation timed out]
<thelema>
is there a more appropriate way to handle merging lists of uneven length? padding with default values seems ugly, but all the possible empty/non-empty cases for this function are also ugly
joewilliams_away is now known as joewilliams
<raphael-p>
thelema: function could take a [`Pad | `Cut] argument…
<raphael-p>
[`Pad | `Trunc] maybe
avsm has joined #ocaml
<thelema>
raphael-p: [`Pad x | `Trunc] - but this still requires implementing the 2^n ways that x can replace a missing entry among n lists
<thelema>
at some point, it's got to be more efficient to just pad the lists (i.e. 1000 lists merged = 2^1000 match cases = impossible)
<thelema>
raphael-p: and ?pad would suffice for this