buluca has quit [Read error: 113 (No route to host)]
P_1 has joined #ocaml
<P_1>
hey, I have a slight problem with my recursive code
<P_1>
can I pm anyone for help?
<Smerdyakov>
No. You should explain your problem here. Never ask to ask; but also don't paste many lines of code or otherwise take up too much space. Best is to post a URL to pertinent information.
<P_1>
let rec sep_concat slist =
<P_1>
match slist with [] -> ""
<P_1>
| (x::xs) -> x ^ " " ^ sep_concat xs;;
<P_1>
well the problem here
<P_1>
is that i get an extra " " at the end
<P_1>
and i dont know how in ocaml to detect if its at the end of the list
<Smerdyakov>
Please don't split sentences across lines needlessly.
<P_1>
so i can leave out the " " at the end
<P_1>
sorry about splitting the sentences
<Smerdyakov>
Can you clarify what you mean by "detect if its at the end of the list"?
<P_1>
meaning if i input a list ["this";"is";"a";"test"] it will give me "this is a test " so I need to detect if its at "test" which is at the end of the list
<P_1>
Ideally I would want the output "this is a test"
<Smerdyakov>
Can you write a recursive function in pseudocode that does what you want?
<P_1>
I can write it in c/c++
<P_1>
would that do?
<Smerdyakov>
If you know how to do it, that's good enough.
<Smerdyakov>
Can you name the precise piece of your C++ code that you don't know how to translate to OCaml?
<P_1>
the part where I detect that I am at the end of the list
<P_1>
because when i am at the end I will with hold the extra " "
<Smerdyakov>
What does that mean in terms of the recursive C++ function?
<P_1>
meaning I can check the length of an array for example and if it is at the end I will not append a " " to it
<Smerdyakov>
I guess you understand that a recursive function over lists, even in C++, will have no concept of "current position"?
<P_1>
in a list i will know which is the tail and which is the head
<P_1>
by a simple check
<P_1>
the structure of a list will have a head and a tail and nodes inbetween
<Smerdyakov>
No.
<Smerdyakov>
That's not the way you do things in OCaml, at least.
<P_1>
well thats why im confused
<Smerdyakov>
You consider each list anew.
<P_1>
yea which is a huge problem
<Smerdyakov>
No, it's not at all.
<Smerdyakov>
It's a much nicer way to doing things.
<Smerdyakov>
Makes for much simpler definitions.
<P_1>
i didnt say it wasn't nicer, Im just making a transition and its tough
<P_1>
infact I think ocaml and haskell are beautiful languages
<P_1>
Its just very tough for a beginner to do this
<Smerdyakov>
Instead of thinking about "what to do at a certain position," you need to think in terms of just examining the list you have in front of you.
<Smerdyakov>
You can't figure out how to omit the final space from that perspective?
<P_1>
Ive tried for an hour
<P_1>
Then I gave up and googled up this irc channel
<Smerdyakov>
I recommend this: Pick a couple of example lists.
<Smerdyakov>
Look at the recursive call structure of your definition for each example list.
<Smerdyakov>
Ask yourself what you could do at some predictable point in that structure to solve your problem.
<P_1>
well it would be to check if its an empty list after the element but I dont know how to check for that
<P_1>
I have tried this: if (x::[]) then etc
<Smerdyakov>
Ah, good, now we're getting warm.
<P_1>
but that doesnt work
<P_1>
i already thought of this
<Smerdyakov>
But that code snippet you just gave is complete nonsense. Don't try to make up syntax. :P
<P_1>
I just don't know how to do it in ocaml
<Smerdyakov>
What tools have you learned for examining lists?
<P_1>
I am not supposed to use built in functions to do this
<P_1>
this is an excercise for a class of mine
<Smerdyakov>
That's sort of a non-answer to the question.
<P_1>
I don't know how to answer then
<Smerdyakov>
What tools are you _allowed_ to use that you've learned?
<P_1>
pattern matching?
<Smerdyakov>
That sounds like one.
<Smerdyakov>
Do you know how to use pattern matching to test if a list ends after the current node?
<P_1>
no
<P_1>
thats what im trying to ask here
<Smerdyakov>
That's very strange.
<Smerdyakov>
Can you summarize what you know about how to use pattern matching?
<P_1>
not really, the teacher just gives examples and we have to learn through experimentation
<P_1>
I'll send you a link to the website
<Smerdyakov>
Ah, then step one is to find a good text.
<P_1>
but can you teach me how to use pattern matching to test if the list ends after the current node?
<Smerdyakov>
I don't think it's in anyone's interests to try to learn a programming language that haphazardly. You should have a clear textual exposition, not someone asking you to learn from examples alone.
<Smerdyakov>
I'll just throw you this bone: you tried to use pattern matching with 'if', but did your teacher show you any example that used pattern matching with 'if'?
<P_1>
no the teacher did not
<P_1>
I had to experiment with it a lot before i got it
<Smerdyakov>
Why not try something closer to the examples that you _do_ have available?
<P_1>
because I don't think its possible with those examples
<P_1>
can you please look through the stuff, I am sure you will get what I mean once you see the material
[azoic] has left #ocaml []
<Smerdyakov>
I know exactly what code solves your problem. I just don't think it's helpful to just give you the answer.
<Smerdyakov>
I mean, do you understand that 'match', not 'if', introduces pattern matching?
<P_1>
yes
seafoodX has quit [Connection timed out]
<P_1>
I am using match
<P_1>
have you see the code I pasted before?
<Smerdyakov>
I'm talking about in testing if a list is one element long.
<Smerdyakov>
You gave an attempt with 'if' before.
<P_1>
yes, and the main part of my code does not use if
<P_1>
i have even tried this
<P_1>
| (x::[])
<P_1>
as one of the cases
<P_1>
but that does not work
<Smerdyakov>
Do you understand that case order matters?
<P_1>
yes I do
<P_1>
If i put that case under the main case I have
<P_1>
it will not even go through
<Smerdyakov>
Can you paste the code with that change made, so I can see what you are saying doesn't work?
<P_1>
oh shit i just noticed i put a double semi colon in ther eby mistake
<P_1>
ok but i still get the same error
<P_1>
it highlights the - on the -> before the ^ x and says syntax error
<Smerdyakov>
I can't think of a less direct way to say it than this: something foul is going on to the _right_ of the arrow in that case.
<P_1>
well i have it now
<P_1>
let rec sep_concat slist =
<P_1>
match slist with [] -> ""
<P_1>
| (x::[]) -> x ^ ""
<P_1>
| (x::xs) -> x ^ " " ^ sep_concat xs;;
<P_1>
well i can even leave out the ^ ""
<Smerdyakov>
OK, so you knew how to do it all along. :)
<P_1>
i did like i said its just syntax issues
<P_1>
lol
<P_1>
and if you look at my teachers slides, i had to deeply deeply infer from them to get how to do this
<Smerdyakov>
Yes, you should read the book I linked cover to cover, if you want to avoid further pain during a semester-long course.
<P_1>
But anyway I love functional programming in terms of how powerful it can be
<P_1>
however it is a huge huge pain transitioning from an imperative language to a functional one
<Smerdyakov>
Probably some portion of this can be blamed on an instructor not handling it all properly.
<P_1>
I'm wondering though can I directly relate my experience from ocaml to haskell
<P_1>
because I hear haskell is even more powerful than ocaml
<Smerdyakov>
I don't know what meaning of "powerful" you're using.
<P_1>
as in it can do more than ocaml and its also faster
<Smerdyakov>
All of these languages are Turing complete, so "do more" is a weird thing to say.
<Smerdyakov>
As for "it's also faster," compiled OCaml programs tend to outperform compiled Haskell programs.
<P_1>
really? I thought haskell performed faster
<Smerdyakov>
Haskell has multiple compilers, so you can't talk about "Haskell's performance," but all of the Haskell compilers underperform the OCaml native code compiler.
<Smerdyakov>
On programs written naturally, at least
<P_1>
"Haskell is more feature-full (with unique laziness semantics and advanced features like type classes and monads)"
netx has quit ["Leaving"]
<P_1>
that was what i was referring to
CRathman_ has joined #ocaml
<Smerdyakov>
Haskell with GHC extensions has more features than anything, sure.
<Smerdyakov>
Often doesn't lead to practical benefit, though.
<mbishop>
they do ok with the mllib dll, but if you want full compatability, go with OCamIK
<mbishop>
er
<mbishop>
OCamIL*
<P_1>
well i was just answering msingh's question
<P_1>
meaning he could just compile his stuff in ocaml instead of f#
<msingh>
P_1, thats cool .. cheers :)
<msingh>
otoh i dont understand why F# is being pushed for scientific computing
<msingh>
what qualities of it make it apppropriate for such tasks?
<P_1>
err i guess it is because ocaml is as well
<P_1>
ms just wants to provide an alternative
<P_1>
to ocaml and haskell
<P_1>
the syntax is nearly the same from what im reading
<msingh>
hmm
<msingh>
it doesn't follow though that if ocaml is suitable for scientific computing then so is F#
<P_1>
the reason ocaml is touted as suitable for scientific computing is because of its functional programming style
gmh33 has quit ["Leaving"]
<P_1>
where you can just define things as equations and etc
<msingh>
oooh
<msingh>
i see
<msingh>
so a similar thing could be said about Erlang?
<mbishop>
well that and the fact that it's "fast as C++"
<msingh>
mbishop, that's not true of F# though :P
<mbishop>
microsoft marketing? :P
<P_1>
its faster than c++ and c isnt it?
<P_1>
speaking of ocaml that is
ktne has joined #ocaml
<mbishop>
ocaml is typically just as fast as C++ (I've seen examples of it being faster), not sure about C, I think I remember Xavier saying 50% on average?
<P_1>
50% faster or 50% of c code speed
<mbishop>
50% speed, which is pretty good for an average
<mbishop>
SML (using mlton) probably gets you a little more speed
<P_1>
but Haskell is usually faster then most c code
<P_1>
and if ocaml is faster than haskell
<P_1>
it would be logical that ocaml is faster than most c code
<mbishop>
Doubtful, people might like to CLAIM haskell is faster than C, and there are all kinds of blog posts about it, but those are usually just special cases
<mbishop>
or very small benchmarks
<mbishop>
But ocaml is generally faster than haskell
<P_1>
there was a darpa paper or something on it
<ktne>
haskell is slow afauk
<ktne>
afaik
<msingh>
is ocaml a small language, do you think?
<P_1>
if c code is pretty much supreme
<P_1>
why look at haskell and ocaml at all
<P_1>
c is easier to program in and faster if what you guys say is true
<msingh>
programmer convenience?
<P_1>
c is more convenient for me
<P_1>
lol
<msingh>
wow, really? :)
<P_1>
its a lot easier to do things iteratively
<P_1>
recursion is beautiful but if it slows things down
<P_1>
why do it
<ktne>
P_1 you don't have to use recursion
<ktne>
P_1 also tail recursive recursion is a fast as iteration
<P_1>
i understand that its not necessary to use recursion, but its a lot more attractive to use recursion in a functional programming language
<P_1>
and yes i understand that tail recursion is just as fast as iteration
<ktne>
yes but for performance reasons you can also use iteration
<P_1>
but what im saying is that it sucks since recursion is so beautiful but its slower in a few cases
<P_1>
what im saying is that it would be nice to have nice performance coupled with the beauty of recursion
<ktne>
i just tried to say that you don't necesarly have to use C because you can use recursion in ocaml too :)
<ktne>
err, iteration
seafoodX has joined #ocaml
<P_1>
yes but what I'm saying is, its faster to think it out in C than in ocaml and if C produces faster code on average
<P_1>
why not just code stuff in C
<ktne>
hmm
<ktne>
c doesn't necesarly produce much better code
<ktne>
then you get a lot more features in ocaml
<ktne>
that you don't have in C
<P_1>
well the features comes with a heavy price in syntax
<ktne>
it's not that bad, i've got used to it :)
<ktne>
it's just different :)
<P_1>
from an old presentation made by tim sweeney of epic games
<flux>
definitely, if you can write faster code in a faster fashion in C, and the code is better maintainable to boot, it makes sense to use C
<P_1>
he was talking about haskell and c
<flux>
however, many people feel that more expressive languages allow to write complex code that is still readable, with less effort
<P_1>
and how haskell and c are both non options to the future of programming in terms of multithreading and data parallelism
<P_1>
the reason he says haskell isnt viable is because of the hard syntax, and the reason that c isnt is because it doesnt have really good support to make threading easy
<ktne>
P_1 do you have a link to the presentation?
<ktne>
hard syntax?
<P_1>
yea hold on ill try to find it
<ktne>
that's one weird reason :)
<P_1>
let me phrase it the way he wrote it
<ktne>
it has a syntax optimised for the way it works
<flux>
the presentation has been quite much around programming.reddit and other sites.. should be easy to find.
<ktne>
not for the way C works
<P_1>
"Learning a functional language will scare off a lot of programmers"
<flux>
I don't think haskell was criticized for its syntax
<P_1>
hold on ill just get a link to it
<ktne>
so you don't want to learn a functional programming language because it would scare other programmers? :)
<flux>
I think he didn't like global type-inference (or rather, the error messages) and perhaps lazy evaluation was also in the list
<flux>
global type inference, I think local one was ok. and I believe the problem was the error messages, which I admit, can sometimes be difficult to penetrate for the unexperienced.
<ktne>
it makes things so easy
<mbishop>
C has lots of problems, I think they've all been said before however
<ktne>
but those are all fluffy arguments
<flux>
not anywhere near as impenetrable as c++ template errors, though..
<P_1>
go to page 58
<P_1>
it talks about the haskell syntax right there
<ktne>
i can't see any serious argument against
<P_1>
i was right, he talks about the syntax scaring off programmers
<ktne>
i agree that the syntax could be improved, i would like a C-like syntax too, but the syntax is not that bad
<ktne>
and it's efficient too, good for it's purpose
<ktne>
it's just different from C
<mbishop>
I hate C syntax
<msingh>
C syntax is fine for that kind of programming
<msingh>
but i wouldnt like a FP language with C syntax
<flux>
for starters, every block would need to be an expression
<P_1>
well anyway the point with sweeney and haskell is that the syntax scares programmers off, but it could enable easy programming for multiple cores compared to c
<P_1>
which is what got me interested into functional programming
<P_1>
i wouldnt mind swallowing the syntax if it allowed for better performance
<P_1>
but from what you guys said its opposite of what i was expecting
<msingh>
what kind of programmer gets scared of a bit of syntax?
<P_1>
read above
<P_1>
i wouldnt, but if it doesnt provide extra performance why learn it
<ktne>
P_1 in what way different from what you expected?
<P_1>
i was thinking that haskell would produce code that runs much faster than c code
<mbishop>
languages aren't just about looks
<ktne>
no, usually haskell produces much slower code
<P_1>
yea which is a bad thing
<ktne>
P_1 but that's because of bad implementation
<P_1>
well how does proper haskell implementation look like
<mbishop>
Haskell probably COULD, in theory produce faster code, since you (and the compiler) can reason about the code a lot more
<mbishop>
C has major problems with aliasing and such, so you can't really reason about the code
<ktne>
P_1 the point is that haskell has a lot of barriers to optimisation removed
<ktne>
P_1 while C has a lot of problems, so other imperative programming languages
<ktne>
P_1 but that doesn't mean anyone actually implemented a good optimiser :)
<P_1>
well i want to know how proper haskell implementation would look, is it all done in recursions, or tail recursions, or iteration?
<ktne>
haskell people will usually spend time discussing the new fashionable metaconcepts, rather than work on the compiler :)
<P_1>
lol
<mbishop>
optimizing compilers are hard
<P_1>
well some guy did it
<mbishop>
the more you optimize, the less helpful your error messages are heh
<P_1>
and apparently made some code run faster than c code
<P_1>
with this guys "supero" compiler hes able to produce compiled code working faster than c code
rutlov has left #ocaml []
<P_1>
"The reason for this is an advanced optimisation that has managed to remove <i>all</i> the intermediate lists. In a normal Haskell program, <tt>getContents</tt> would build a list of characters, <tt>lines</tt> would take that list, and build a list of strings, then <tt>length</tt> would take that list and consume it. With my optimisation, no intermediate lists are created at all.<br /><br />While in the previous benchmark it was easy to examine and understa
seafoodX_ has joined #ocaml
<mbishop>
you can optimize stuff away until you're faster than C, but most people prefer the code to be helpful (with bounds checking, etc) and correct rather than super fast