vezenchio has quit [Read error: 110 (Connection timed out)]
CosmicRay has joined #ocaml
Hanji has joined #ocaml
gim has quit ["dnftt"]
Submarine has quit ["Leaving"]
wegzz has quit ["\o/ python _o--|_"]
CosmicRay has quit [Read error: 113 (No route to host)]
tautologico has joined #ocaml
CosmicRay has joined #ocaml
tyler has joined #ocaml
<tyler>
when doing a pattern match, is there any way to add a matching constraint without using a when?
<Smerdyakov>
What do you mean in particular?
<tyler>
say I've got two int * int tuples
<Smerdyakov>
Good heavens. You're rich!
<tyler>
i'd like to match against two tuples where the two first ints are equal
<Smerdyakov>
Nope, there's no way.
<tyler>
damn
<Smerdyakov>
What's wrong with 'when'?
<tyler>
May not sound like a big deal, but since I've got *5* two tuples I'm matching with, it's gonna get interesting
<tyler>
I'm working on a little video poker game ;
<tyler>
;)
<Smerdyakov>
Perhaps a single match isn't the best code for this case.
<tyler>
perhaps not
<tyler>
it would be ideal if you could reuse match params
<tyler>
something like (a,x),(b,x)
<tyler>
to match two tuples with the same 2nd element
<tyler>
but alas, not legal...
<tyler>
I might make a little counting function to make it a bit less tedius
<tyler>
since I'm generally interested in quality such as, "of these 5 two element tuples, do a least 3 share the same first field
<mfurr>
tyler: I recently wrote a poker program in ocaml, its really not too bad if you use lists to compute the hands
<tyler>
mfurr: hrmm, like a big ass list of all possible hands?
<mfurr>
no, as in representing your hand as a list
<tyler>
that's what I'm doing ;)
<tyler>
a list of type card = Card of value * suit;;
<tyler>
;)
<tyler>
then I've got a hand record that is basically a list of 5 of those, and a few mutable status flags
<tyler>
I'm also storing them in sorted order by value
<tyler>
so that simplfies things a bit
<mfurr>
oh, so you're hard-coding a 5 card hand?
<tyler>
it's not so much that I can't do it, I was just wondering if there was some elegant way ;)
<tyler>
yep
<tyler>
I'm just doing simple video poker this time, 5 card draw ;)
CosmicRay has quit ["Client exiting"]
<tyler>
this is much more a 'learn some o'caml by doing something kinda fun' rather than an attempt to make a serious program
<tyler>
sort of a fun 'afternoon or two' project
<mfurr>
sounds perfect
<tyler>
;)
<tyler>
I've got a fair bit of the backend stuff done
<tyler>
the hand identifier is probably the only tricky part
<tyler>
I'll probably do it as a tired case
<mfurr>
there's a few small optimizations you can use for that
<tyler>
like handle all the straight cases first, then the flush cases, etc
<mfurr>
for instance if you sum the (5) cards and its divisable by 5, then its a straight
DerDracle has joined #ocaml
<tyler>
oooh
<mfurr>
(I think, or something like that)
<monochrom>
2+4+6+8+10 is divisible by 5.
<tyler>
hrrm
<tyler>
well, checking that the first two cards are consecutive should fix that
<mfurr>
okay, then that's not quite it, but there are a few tricks I believe
<tyler>
just figured out a another way
<tyler>
do the addition thing, and the middle card * 5 is the sum
<tyler>
probably easier to write a few more functions
<mfurr>
but you still have to sort it in that case
<tyler>
true
<tyler>
but I'm sorting 'em anyway ;)
<tyler>
and the sorting is easy ;)
<mfurr>
looking at my implementation, I ended up not using those things anyway
<mfurr>
indeed
* tyler
gets the feeling he's going to be doing lots of folding and mapping ;)
<mfurr>
oh definately
<mfurr>
what are you using for the "video" part? Tk? SDL?
<tyler>
oh, nothign like that ;)
<tyler>
printf ;)
<tyler>
although a simple gui probably wouldn't be that tricky ;)
<tyler>
maybe for a future project ;)
<tyler>
this is basically my first program in caml over 20 lines or so
kinners has quit ["leaving"]
<tyler>
heh
<tyler>
I can remember when I though a foreach type statement was cool ;)
<tyler>
like in php or python
<tyler>
and it is cool compared to looping over arrays in c
<tyler>
but still...
<tautologico>
still, people are trapped with stone age tools :)
<tyler>
;)
<tyler>
I'm finding pattern matching in general to just be a really elegant way to approach stuff
<tautologico>
yes, and it avoids some runtime errors you get in languages like lisps
<tyler>
right
<tautologico>
like trying to get the tail of an empty list
<tyler>
I have very, very, few complaints about o'caml ;)
<tyler>
my biggest one is the way it handles numbers
<tautologico>
how so ? 31-bit integers ?
<tyler>
well, it'd be nice to have, eg ints the gracefully degrade to bignums
<tyler>
like in lisp or python
<tautologico>
ah
<tyler>
of course, I think that 1 + 2.5 is a perfectly logical expression too ;)
<tautologico>
like lisp you mean scheme ? I don't remember if this is true in common lisp
<tyler>
it's been a while
<tyler>
I didn't stick with lisp too long
<tyler>
got kinda disgusted with it
<tyler>
my lang of choice has traditionally been python
<tautologico>
well, I too think 1 + 2.5 could be valid
<tyler>
I think is was maybe haskell had a sort of type classing system that allowed that kind of stuff
<tyler>
sort of like inheritence for types
<tautologico>
type systems still have a way to go
<tyler>
python kinda handles it
<tyler>
in python 1 + 2.5 returns a float
<tyler>
which is logical to me
<tautologico>
hm... more like java interfaces, and it would still be incorrect
<tautologico>
or abstract base classes... haskell type classes are interesting indeed
<tyler>
I could live with a pusedo-polymorphic arith ops
<tautologico>
but much more powerful than abstract base classes
<tyler>
so basically 1.0 + 2.0 and 1 + 2 would be valid, but 1 + 2.5 would not be
<tyler>
it's really the extra . after the op that offends me
<tyler>
it's just kinda...ugly
<tyler>
but when that kind of stuff is my biggest beef with a language...
<tautologico>
this is valid in haskell
<tyler>
typing is the kicker
<tyler>
it works well in pyhton, which is strongly but dynamically typed
<tyler>
ugh, can't type
<tautologico>
+ is (Num a) a -> a -> a
<tautologico>
where a is any instance of type class Num
<tyler>
yep, that's what I mean
<tyler>
of course the problem with that level of OO is that performance sucks ;)
<tautologico>
it's not oo, really
<tyler>
well, true
<tautologico>
and the operations are especialized for specific types
<tyler>
ahh, gotcha
<tyler>
like templates sorta?
<tautologico>
well, it's an implementation detail
* tyler
has kinda dabbled in the funcitonal languages
<tyler>
ocaml is the one I know the most of
<tyler>
it's also nearly midnight and was just in the hospital for a few days
<tyler>
so I'm not at my sharpest ;)
<tautologico>
:)
<tautologico>
well, we're all learning
<tyler>
yep
<tyler>
I've been pleased so far
<tyler>
ocaml is the langauge out of the, oh, 15 or so that I've looked into to not really piss me off in some way
<tautologico>
but I think type systems have much to improve still
<tyler>
python would be killer...if it wasn't dog slow...
<tyler>
yep
<tyler>
sufficiently intelligent compilers...
<tyler>
I've called compilers lots of things...
<tyler>
rarely intelligent ;)
tyler has quit ["Lost terminal"]
<mfurr>
apparently he had some words for his IRC client too
<tautologico>
lol :)
tautologico has quit []
Lemmih has quit [Read error: 60 (Operation timed out)]
carm has joined #ocaml
<carm>
hello, anyone around?
<mfurr>
hello
<Riastradh>
Nope, sorry.
<carm>
hello guys. I have a difficult to answer question, but am going to throw it out anyway. For a program which performs a game tree type search, would there be a significant speed difference between OCAML and JAVA?
<mfurr>
in development time: definately. in run time: possibly
<carm>
well the development time would take a while for OCAML simply because I would need to write a network client and some simple game information datastructures first (these portions are already done in java)
<carm>
can you expand more on run time?
<Riastradh>
carm, in order to answer your question, many more details must be present.
<carm>
yeah I figured
<mfurr>
"it depends"
<Riastradh>
For example: what Java implementation you're using, how experienced you are with OCaml & Java efficiency, what algorithms you use, what idioms in either language you use, et cetera.
<carm>
well we are talking about a tree that with a branch factor of 3, at most 40 deep
<carm>
and most "evaluation" functions will be done using C wrappers
<mflux>
maybe you could write a benchmark in both languages to get some idea
<Riastradh>
Why use C?
<mfurr>
why?
<carm>
my OCAML experience is moderate, my java experience is excellent
<Smerdyakov>
carm, why are you writing this?
<carm>
Smerdyakov, hmmm..are you the cmu student I met here before?
<carm>
Riastradh: doing combinatorical analysis on large sets
<Smerdyakov>
carm, I'm Adam Chlipala. :-)
<carm>
Smerdyakov, yes I thought so. hehe
<Riastradh>
carm, yes...?
<carm>
Riastradh: there already exists useful libraries in C that do things I need very quickly (usings bit operations and whatnot)
<Smerdyakov>
You have bit operations in OCaml.
<carm>
ok I am not here to argue about using C
<Riastradh>
carm, if you're willing to write so much code in OCaml already, why not that, too?
<carm>
trust me that this is a valid circumstance
<carm>
I already wrote the wrapper!
<carm>
much less code to write the wrapper, and will perform faster
<Riastradh>
How are you certain it will perform faster?
<carm>
Riastradh, the C library I am referring is indisputable the fastest known of its kind, and I performing repeated operations in a tight loop with the library
<Smerdyakov>
carm, what are you working on this for?
<carm>
Smerdyakov: pet project
<carm>
Smerdyakov, you still at CMU?
<Smerdyakov>
carm, nope; Berkeley.
<mfurr>
If speed _really_ matters that much. Write the entire thing in OCaml to figure out all of the engineering problems, then reimplement the entire thing in C
<carm>
Smerdyakov, nice. I don't have the grades for that :)
<Smerdyakov>
mflux, or use SML, so you don't have to reimplement it in C! :D
<Riastradh>
carm, have you considered using a language for which a very highly optimizing whole-program compiler exists, such as Scheme (Stalin) or SML (MLton)?
<carm>
mfurr: ugh. I've broken up the parts that definitely need to be in C. but I am not certain if I can handle a brancing factor of 3, depth of 40 all that easily
<carm>
Riastradh, well according to some benchmarks I've seen, OCAML fares quite well compared to C
<mfurr>
3^40 is indeed a lot of nodes :)
<Smerdyakov>
MLton fares better.
<Riastradh>
OCaml does not provide a whole-program compiler, however, which prevents much optimization.
<Riastradh>
Stalin & MLton can both fare far better than OCaml in that regard.
<Smerdyakov>
carm, small benchmarks don't give much of a chance for whole-program compilers to shine.
<carm>
Smerdyakov, fair enough.
<carm>
basically I am worried that I'll finish the code in java, and find that it runs slow as hell. then I will cry
<Riastradh>
Furthermore, such benchmark comparisons either have _extremely_ narrow scopes or compare apples & oranges. It would require _gargantuan_ amounts of data & testing & effort to construct accurate & broadly applicable benchmarks. Even then, whole-program compilers wouldn't be represented well.
<carm>
Riastradh, point being, ocaml doesn't do bad with what weak analytical tools of performance that are available
<Riastradh>
I suggest that you write it in Scheme or SML and worry about performance when you get there, with the whole-program compilation tools readily available as necessary.
<carm>
Riastradh, ok. thank you for your advice.
<Smerdyakov>
I second the advice!
<carm>
haha, either way I have crapload of coding to do if I don't use java
<carm>
Smerdyakov, what are you doing at berkeley? Masters, PHD, research?
<Smerdyakov>
All 3!
<carm>
Smerdyakov, my goals are similar, although I have a more indirect appraoch to accomodate for my mediocre performance at CMU
<Smerdyakov>
What's the indirect approach?
<carm>
Smerdyakov: do research and take grad courses, apply later
<Smerdyakov>
Would anyone like us to continue this conversation here, or should we switch to private messages?
<carm>
its alright, I'm finished :)
<DerDracle>
..
<Smerdyakov>
DerDracle, do you have a PROBLEM with that?
<DerDracle>
Hehe :p
<DerDracle>
It's just been my experience that 90% of the speed of a programming comes a lot more from 'how' it is written, and not what it's written in.
<carm>
I love being in an OCAML channel and being recommmended mlTon
<DerDracle>
Ahem, a program.
<carm>
DerDracle: truth to that of course, but I am no fool when it comes to algorithms
<Smerdyakov>
DerDracle, that's your _heathen_ experience.
<DerDracle>
Ocaml really is incredibly fast :p
<DerDracle>
Heathen eh?
<DerDracle>
hehe.
<Riastradh>
I suggested Scheme & SML only on the basis that there exist highly optimizing whole-program compilers for them; otherwise -- had your application not depended on such high optimization as a whole-program compiler is necessary to provide -- I'd not suggest any over the others, although I have a preference for Scheme.
<carm>
Riastradh, I have a (recently met) friend who is a diehard ruby fan.
<DerDracle>
Hm.. What I've noticed with Ocaml really is program stability.
<DerDracle>
I've noticed this to a degree in Java too, but less so than in Ocaml.
<DerDracle>
I can be confident that an Ocaml program has few to no lose ends.
<carm>
DerDracle, you don't feel that way with SML?
<mflux>
that's why I too like ocaml (compared to c, c++, java). it gives you a feeling you can trust the program.
<DerDracle>
Hm, I feel that way with SML too.
<DerDracle>
I didn't exclude any other languages in that statement.
<mflux>
infact I could add to my comparison list perl and python too
<carm>
DerDracle, I know, but the comparison was with SML, and you excluded it from your statement
<mflux>
disclaimer: I still do work with c ;)
jao has quit ["ERC Version 4.0 $Revision: 1.703 $ (IRC client for Emacs)"]
<Riastradh>
carm, were you going to say something more about your diehard Ruby fan friend, or did you just feel like mentioning his existence?
monochrom has quit ["hello"]
<DerDracle>
I wasn't aware :p
<DerDracle>
O.o, I really like Ruby too.
<carm>
Riastradh, sorry. hehe. well he is butting heads with a professor about how ruby is levels beyond common lisp. one feature he seems to like is that everything is an object and can be referenced as such (i.e. you could write 1.toString()) or something like that
<Nutssh>
carm: Profiling is a friend. Run it and see what the profiler indicates to be the problem. It, eg, might not be the evaluation function, but the code that performes the moves.
<DerDracle>
I think the library is intuitive.
<DerDracle>
.. Why even compare Ruby and Lisp?
<Riastradh>
carm, has his professor corrected him about that frivolous matter?
<DerDracle>
carm: That is a neat feature--- but nothing new.
<Smerdyakov>
Haskell type classes do that better.
<carm>
Riastradh, well the proff has some sort of datamining software / knowledge base written in lisp and my friend thinks that lisp is inherently limiting the expressibility of the knowledge base
<DerDracle>
Hm, the point in Ruby though is 'everything' is an object.
<DerDracle>
I don't think you can do better than that, from that perspective.
<Smerdyakov>
DerDracle, so? What benefit are you claiming from that?
<DerDracle>
I mean, if you consider that a feature, I mean.
<carm>
I think people underestimate the importance of syntactic sugar
<DerDracle>
Smerdyakov: I didn't claim a benefit, I was saying if you assume that is a benefit :p
<carm>
in ruby you can easy overload any operator
<Smerdyakov>
DerDracle, I am going to assume false.
<Smerdyakov>
carm, you can do it better in Haskell.
<Riastradh>
carm, yes, people need to realize the importance of powerful Lisp-like macros.
<Nutssh>
Thats also one of the reasons I'm going for an ML over a LISP, is I love the stability of the typing system. Commonly, I make one change to a representation and just fix all of the typing errors. Lisp wouldn't help with that at all.
<DerDracle>
Hm.. Overloading operators is good, for certain things.
<carm>
Riastradh: I feel that LISP is somewhat outdated in the world of functional programming
<DerDracle>
The problem is when people use them for stupid crap like pipes.
<Riastradh>
Nutssh, what Lisp system were you using?
<Nutssh>
Lisp would be more powerful, but also, if you don't run it, you don't know if you just broke it with a type error.
<Nutssh>
I was using cmucl.
<DerDracle>
Lisp is beautiful in its simplicity.
<Riastradh>
carm, which Lisp are you referring to in specific there?
<DerDracle>
I would say Ruby is just a Cish smalltalk, it's outdated too.
<carm>
Riastradh, I suppose common lisp more than anything else
<Nutssh>
Lisp IMHO, has as much expressiveness as an ML, plus much more power than an ML, but also much more dangerous.
<Riastradh>
Common Lisp is generally not regarded as a functional language at all, so that's not a very meaningful comparison.
<DerDracle>
Nutssh: I wouldn't say it's more power.
<DerDracle>
Ahem, has.
<carm>
Riastradh, well there are obvious ties between LISP and say, SML.
<carm>
Riastradh, and when one is making the choice of picking a higher level language, its reasonable to compare the merits of LISP with functgional langauges
<Riastradh>
Nutssh, note that such type errors are frequently caught during the type of incremental development & testing customary in Lisp systems; furthermore, many Lisp systems (such as Scheme48) even provide simple static type analysis that catches many type errors.
<Nutssh>
Well, the macro system is something that nothing else has. PCL is an application. (PCL is an implementation of the the CL Object System). C++ and CAML need a whole seperate compiler implementation for the same functionality.
<Smerdyakov>
Nutssh, Lambda the Ultimate linked recently to a paper on doing OO in SML.
<Riastradh>
carm, note, by the way, that, when you say 'LISP,' most Lispers will think you're referring to McCarthy's original symbolic list processing language, not necessarily the language family under which CL & Scheme fall.
<Riastradh>
So yes, LISP is certainly outdated. But that's probably not what you meant.
<Nutssh>
Riastradh, I know. I was thinking where things are incrementally modified. Thats unsafe unless you know with a coverage suite that you're running every line of code to catch any incepent type errors.
<Smerdyakov>
Don't forget to join #sml, everyone.
<carm>
haha ok I've had enough theoretical discussion for this evening in which everyone in this channel knows more than me apparently :)
<carm>
talk to you later guys, going to do some coding
<Riastradh>
carm, anyhow: I was under the impression you were talking about Common Lisp as a functional language and then comparing it to other functional languages.
<carm>
Riastradh, yeah I was
<Nutssh>
Eg, my analysis program, I changed from using ocaml lists to ocaml array's as a core representation. Knowing it would work was just fixing type errors. Doing that change in a common lisp wouldn't have the same confidence I got it all right.
<Riastradh>
This doesn't make much sense, as few people regard CL as a functional language; Lisps tend to fall under their own category, Lisp, not so much into others such as functional.
<Nutssh>
carm, one bit of advice.. Write it, then profile. Youo never know where you find a runtime surprise. Array.sort and Randodm.int have frequently been bottlenecks for me.
<Riastradh>
Nutssh, more relevant than that is that your data structure wasn't adequately abstracted.
<carm>
Nutssh: good advice. I profiled some code on another project I had and found that 85% of the processor was in one function :)
<Smerdyakov>
Nutssh, good heavens. Why would you sort an array? ARE YOU MAD?
<Nutssh>
Hmmph?
<Riastradh>
Well, perhaps: I'm insufficiently familiar with your code to make such assertions particularly definitively, of course.
<Nutssh>
Smerdyakov, A copy&pasted Array.sort that was specialized for 'int array' is about 3 times faster than one with 'a array.
<Smerdyakov>
Nutssh, not in MLton.
<Smerdyakov>
Nutssh, it's funny how all your examples of "performance tuning" are made unnecessary for inlining. :D
<Smerdyakov>
s/for/by
<Riastradh>
(This sort of thing is where whole-program compilers shine.)
<Nutssh>
carm, I ruthlessly profile during development. Usually a few small tweaks cna make compile-test cycle go faster.
<Riastradh>
(No pun intended.)
<Nutssh>
Riastradh, I made a design choice to not abstract away whether a path was represented by a list of the node ID's or an array of the node ID's.
<Smerdyakov>
Abstraction doesn't hurt performance with whole-program optimization.
<Nutssh>
I've tried it that way, but it seemed that it can hurt clarity and ease of understanding from the sheer volume of wrappers.
<Smerdyakov>
I just think you should try using MLton before making any more remarks about how to go about writing ML code with performance in mind.
* Riastradh
is off to bed now.
<Nutssh>
Riastradh, I know. You mentioned mlton to me, and that may be enough motivation to switch from ocaml to sml. Some of my code may be helped with better compilers.
<Nutssh>
Smerdyakov, accepted, my examples come from ocaml's limitations. Its the process I go through that is more important than the result. I guess I wasn't clear where my emphasis is.
<Smerdyakov>
I'm pretty partial to results, myself.
<Nutssh>
And, this is #ocaml, so reamrks of where I found bottlenecks in ocaml are appropriate. :)
<Smerdyakov>
If there is no God, then everything is permitted.
<Nutssh>
I need to emphasise it more in the future: Write, profile, do any trivial rewrites with huge payoffs, profile, do additional rewrites only if the estimated payoff is worth it.
<Smerdyakov>
Nutssh, what's your research area? (I forgot.)
<Nutssh>
I'm a phd student in security, but I'm very much a PL weenie. (Heritage of two years of working with Robert Harper and Frank Pfenning.)
<Smerdyakov>
Are you coming to POPL'05?
<Smerdyakov>
[And Bob doesn't have you on his list of past undergrads, on his web site! :P]
<Nutssh>
Nope. I'm totally systems right now, despite that background.
* Nutssh
suffers from too many interests. "I had to pick one thing and stick with it."
mfurr has quit ["Client exiting"]
* Nutssh
nods and eh's.
<Nutssh>
Whats your area?
<Smerdyakov>
Language-based security
<Nutssh>
Interesting.. From what direction are you going? TAL? CQUAL? Java? I'd guess CQUAL if you're at berkeley.
<Smerdyakov>
Nah, though I share an office with some CQual people.
<Smerdyakov>
I spent a lot of time working with TAL in the last year or so. My master's thesis is on handling TAL in a foundational PCC framework.
zzorn has joined #ocaml
<Nutssh>
Ok.
<Nutssh>
Ah, I should have expected it with George Necula as an advisor.
oracle1 has quit [tolkien.freenode.net irc.freenode.net]
Excedrin has quit [tolkien.freenode.net irc.freenode.net]
Smerdyakov has quit [tolkien.freenode.net irc.freenode.net]
creichen has quit [tolkien.freenode.net irc.freenode.net]
creichen has joined #ocaml
creichen has quit [Killed by ballard.freenode.net (Nick collision)]
creichen has joined #ocaml
Smerdyakov has joined #ocaml
Excedrin has joined #ocaml
creichen_ has joined #ocaml
oracle1 has joined #ocaml
carm has quit ["Leaving"]
creichen has quit [Connection timed out]
Excedrin has quit [tolkien.freenode.net irc.freenode.net]
Smerdyakov has quit [tolkien.freenode.net irc.freenode.net]
Smerdyakov has joined #ocaml
Excedrin has joined #ocaml
zzorn is now known as zzorn_away
Excedrin has quit [tolkien.freenode.net irc.freenode.net]
Smerdyakov has quit [tolkien.freenode.net irc.freenode.net]
Smerdyakov has joined #ocaml
Excedrin has joined #ocaml
DerDracle has quit ["Client Exiting"]
mlh has joined #ocaml
mrsolo_ has joined #ocaml
mrsolo has quit [Read error: 54 (Connection reset by peer)]
srv has quit [Read error: 104 (Connection reset by peer)]
mattam has joined #ocaml
srv has joined #ocaml
pangoafk is now known as pango
smimou has joined #ocaml
pango has quit ["Client exiting"]
pango has joined #ocaml
smimou has quit ["?"]
karryall has joined #ocaml
dxlvi is now known as _
Submarine has joined #ocaml
_ is now known as dxlvi
Tristram has joined #ocaml
dxlvi has quit ["troll n. Nasty giants from the mountains to the north"]