Loading ...
Sorry, an error occurred while loading the content.
 

Re: "ocaml_beginners"::[] Request for commentary / grilling

Expand Messages
  • Richard Jones
    ... At the end of the day, it s a programming language for getting stuff done in, so I wouldn t be too precious about avoiding while loops. There s a periodic
    Message 1 of 9 , Apr 21, 2008
      On Mon, Apr 21, 2008 at 04:01:30PM -0400, Michael DiBernardo wrote:
      > Yes, I was trying to avoid while loops / other iterative constructs,
      > but I find that extremely difficult to do when dealing with I/O. Glad
      > to know this is a common idiom, thanks for that.

      At the end of the day, it's a programming language for getting stuff
      done in, so I wouldn't be too precious about avoiding while loops.

      There's a periodic discussion that happens on the lists about how to
      read all lines from a file:

      http://caml.inria.fr/pub/ml-archives/ocaml-beginners/2003/04/1f84bc1aa990459f9da2721e399dfcde.en.html
      http://caml.inria.fr/pub/ml-archives/caml-list/2003/05/79e940406a290a4ae25b18228cd70133.en.html
      http://caml.inria.fr/pub/ml-archives/caml-list/2004/04/5814f3200c451a4983ffb0111e7767c1.en.html
      http://caml.inria.fr/pub/ml-archives/caml-list/2007/10/cb1c2bd7a37c8daf5a02672af2c2bf13.en.html

      The answer is to use a while loop!

      Rich.

      --
      Richard Jones
      Red Hat
    • Michael DiBernardo
      ... Ah, I see now. I tend to think of streams in a much more general sense, without necessarily associating them with particular processes such as parsing or
      Message 2 of 9 , Apr 22, 2008
        On 21-Apr-08, at 5:16 PM, Ashish Agarwal wrote:

        >> I'm sure there's a good reason that the 'Stream.empty' function
        >> does not
        >> return a boolean value, but the fact that it returns unit or
        >> throws an
        >> exception baffles the heck out of me.
        >
        > I believe this is because Stream.empty is being thought of as a
        > parser.
        > Presumably this will be used in a context where you are expecting
        > end-of-file. The behavior is consistent with Stream.next.

        Ah, I see now. I tend to think of streams in a much more general
        sense, without necessarily associating them with particular processes
        such as parsing or reading from a file. But this makes sense. Thanks
        for the clarification.

        -Mike

        > On Mon, Apr 21, 2008 at 4:07 PM, Michael DiBernardo
        > <mikedebo@...>
        > wrote:
        >>
        >>
        >>
        >>
        >>
        >>
        >>
        >>
        >> On 19-Apr-08, at 1:31 PM, Richard Jones wrote:
        >>
        >>> On Fri, Apr 18, 2008 at 03:04:07PM -0400, Michael DiBernardo wrote:
        >>>> 2. Rotating an array to the left
        >>>> http://ocaml.pastebin.com/m79557fdf
        >>>
        >>> For the rotate function it's probably going to be a bit quicker
        >>> to use
        >>> Array.blit isn't it? (Although that takes a bit of extra space).
        >>
        >> Almost certainly :) The idea was to do the reversal in-place. If I
        >> was doing this 'for real', I'd probably use blit. Plus, I have to
        >> admit that I think the 3-reversal trick is just plain cool :)
        >>
        >>
        >>>
        >>>> 3. Finding and grouping anagrams
        >>>> (c) http://ocaml.pastebin.com/m6103b23f
        >>>
        >>> As a general comment you might find some of the functions in Extlib
        >>> useful when handling strings. Extlib fills in a lot of the missing
        >>> functions in the stdlib List and String modules.
        >>
        >> Extlib is truly awesome. I've used it before. When I'm working on
        >> these exercises, though, I try to stick to the core OCaml language so
        >> that friends/readers can just grab the source and compile without
        >> worrying about dependencies.
        >>
        >>
        >>> Exploding the string into an array is likely to be slow, yet strings
        >>> are really byte arrays already. I wonder if you can't use the string
        >>> directly in this algorithm, thus avoiding all the copying? Also I
        >>> don't know how much you care about UTF-8, but this function is
        >>> fundamentally not going to work with UTF-8 strings, because byte !=
        >>> character in such strings.
        >>
        >> Yes, I was aware of the UTF8 issue. I was thinking instead of using a
        >> hash function that maps bags of characters to unique ints, but the
        >> sorted-letter signature is what the book uses, and so I stuck with
        >> that.
        >>
        >>
        >>>
        >>> If we assume that words are [a-z]{1-15} then perhaps a better
        >>> representation of the signature is to count the frequency of each
        >>> character. There are various representations, from a 26 entry Array
        >>> (which will consume 27 * wordsize bytes), to a 13 byte string (each
        >>> nybble encodes the count for one character, consuming 20 bytes
        >>> exactly
        >>> for each signature). You can also share signatures.
        >>
        >> Yes, but if I was to try to generalize this in all dimensions, then I
        >> don't think that would work with any non-English encoding either :)
        >>
        >>
        >>> Another approach to look at is whether it's quicker to build a
        >>> tree of
        >>> the signatures as you create the signatures, rather than sorting
        >>> them
        >>> afterwards. Essentially doing an insertion sort. You'll have to
        >>> measure which is quicker for the particular file size of interest.
        >>
        >> That's a good idea! I am going to start playing with recursive data
        >> structures next, so this might be the perfect segue into it. Thanks
        >> for the suggestion!
        >>
        >>
        >>>
        >>> Some ideas anyway ... As for the code it seems like natural OCaml to
        >>> me, except that I'd avoid using Stream.
        >>
        >> Yeah, reliance on streams is something I picked up from python and
        >> scheme. As you've noted, I'm not particularly good at handling them
        >> elegantly in OCaml, so I think I might have to untrain myself in this
        >> respect.
        >>
        >> Thanks again for the tips!
        >>
        >> -Mike
        >>
        >>
        >>>
        >>> Rich.
        >>>
        >>> --
        >>> Richard Jones
        >>> Red Hat
        >>>
        >>> ------------------------------------
        >>
        >>>
        >>> Archives up to December 31, 2007 are also downloadable at http://
        >>> www.connettivo.net/cntprojects/ocaml_beginners/
        >>> The archives of the very official ocaml list (the seniors' one) can
        >>> be found at http://caml.inria.fr
        >>> Attachments are banned and you're asked to be polite, avoid flames
        >>> etc.Yahoo! Groups Links
        >>>
        >>>
        >>>
        >>
        >>
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        > ------------------------------------
        >
        > Archives up to December 31, 2007 are also downloadable at http://
        > www.connettivo.net/cntprojects/ocaml_beginners/
        > The archives of the very official ocaml list (the seniors' one) can
        > be found at http://caml.inria.fr
        > Attachments are banned and you're asked to be polite, avoid flames
        > etc.Yahoo! Groups Links
        >
        >
        >
      • Michael DiBernardo
        ... Good call. ... The evidence is overwhelming :) Thanks! The interesting thing about my tinkering recently is that I m doing it in a place where I have
        Message 3 of 9 , Apr 22, 2008
          On 21-Apr-08, at 6:32 PM, Richard Jones wrote:

          > On Mon, Apr 21, 2008 at 04:01:30PM -0400, Michael DiBernardo wrote:
          >> Yes, I was trying to avoid while loops / other iterative constructs,
          >> but I find that extremely difficult to do when dealing with I/O. Glad
          >> to know this is a common idiom, thanks for that.
          >
          > At the end of the day, it's a programming language for getting stuff
          > done in, so I wouldn't be too precious about avoiding while loops.

          Good call.

          > There's a periodic discussion that happens on the lists about how to
          > read all lines from a file:
          >
          > http://caml.inria.fr/pub/ml-archives/ocaml-beginners/
          > 2003/04/1f84bc1aa990459f9da2721e399dfcde.en.html
          > http://caml.inria.fr/pub/ml-archives/caml-list/
          > 2003/05/79e940406a290a4ae25b18228cd70133.en.html
          > http://caml.inria.fr/pub/ml-archives/caml-list/
          > 2004/04/5814f3200c451a4983ffb0111e7767c1.en.html
          > http://caml.inria.fr/pub/ml-archives/caml-list/2007/10/
          > cb1c2bd7a37c8daf5a02672af2c2bf13.en.html
          >
          > The answer is to use a while loop!

          The evidence is overwhelming :) Thanks!

          The interesting thing about my tinkering recently is that I'm doing
          it in a place where I have absolutely no internet connectivity. So
          when I hit a problem like this, I basically am left with a couple of
          PDFs, the OCaml standard library mli's, and my own limited ingenuity
          to decide how to proceed. It's quite a lot of fun!

          -Mike

          >
          > Rich.
          >
          > --
          > Richard Jones
          > Red Hat
          >
          > ------------------------------------
          >
          > Archives up to December 31, 2007 are also downloadable at http://
          > www.connettivo.net/cntprojects/ocaml_beginners/
          > The archives of the very official ocaml list (the seniors' one) can
          > be found at http://caml.inria.fr
          > Attachments are banned and you're asked to be polite, avoid flames
          > etc.Yahoo! Groups Links
          >
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.