Re: Interesting challenge
On Thu, Dec 30, 2010 at 9:03 AM, David Nolen wrote: > From the Qi mailing list: > http://groups.google.com/group/qilang/browse_thread/thread/e4a2f534fad5032a > "I contend that this kind of problem cannot be solved (efficiently) in any > pure functional programming language. You may disagree" > :D > David Has anyone looked at this yet? I wrote a Clojure program to solve the challenge, but I keep coming up with a count of 63,422 prime squares, not 35,953. I've posted a text file containing all the prime squares I found: https://docs.google.com/leaf?id=0B0JrHNwD7hNSZTBmMzg5ZGEtZWZmZC00ZWI3LTk4MWItMjU2MDljMDBjYjNm&hl=en I'd love to have another set of eyes on this. If you find the challenge interesting, but not enough to want to code the whole solver from scratch, maybe you could write a verifier to check and make sure that each of my prime squares satisfies the constraints of the problem and is unique with respect to isomorphism. I've verified it myself, but maybe there's some subtlety I'm missing. If 63422 is correct and I can get independent confirmation, it would be fun to go back to the author of the challenge and say "Your C++ solution may be fast, but in a functional programming language, at least we get the right answer :) " Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Interesting challenge
On 1 January 2011 13:53, Mark Engelberg wrote: > On Thu, Dec 30, 2010 at 9:03 AM, David Nolen wrote: >> From the Qi mailing list: >> http://groups.google.com/group/qilang/browse_thread/thread/e4a2f534fad5032a >> "I contend that this kind of problem cannot be solved (efficiently) in any >> pure functional programming language. You may disagree" >> :D >> David > > Has anyone looked at this yet? I wrote a Clojure program to solve the > challenge, but I keep coming up with a count of 63,422 prime squares, > not 35,953. > > I've posted a text file containing all the prime squares I found: > https://docs.google.com/leaf?id=0B0JrHNwD7hNSZTBmMzg5ZGEtZWZmZC00ZWI3LTk4MWItMjU2MDljMDBjYjNm&hl=en > > I'd love to have another set of eyes on this. If you find the > challenge interesting, but not enough to want to code the whole solver > from scratch, maybe you could write a verifier to check and make sure > that each of my prime squares satisfies the constraints of the problem As far as I can see each of your squares do indeed satisfy the constraints. > and is unique with respect to isomorphism. I've verified it myself, > but maybe there's some subtlety I'm missing. I'm not sure how best to test that they are unique wrt. isomorphism. > If 63422 is correct and I can get independent confirmation, it would > be fun to go back to the author of the challenge and say "Your C++ > solution may be fast, but in a functional programming language, at > least we get the right answer :) " :) -- Michael Wood -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Interesting challenge
On Sat, Jan 1, 2011 at 10:53 AM, Michael Wood wrote: > I'm not sure how best to test that they are unique wrt. isomorphism. (= (* 8 (count squares-seq)) (count (distinct (flatten (map generate-isomorphs squares-seq), of course. :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Gloss, a byte-format DSL
Hey,
I am trying Gloss for reading NBT [1] files.
First thing I did like is that it seems to make things real easy.
First thing I did not like is the weak separation between types
like :byte and extra data like :foo.
I think I'm nearly done with the NBT reader [2], but I ran into a
problem. Whatever I put in the header form, I get exceptions like
this:
java.lang.IllegalArgumentException: No implementation of
method: :sizeof of protocol: #'gloss.core.protocols/Writer found for
class: clojure.lang.PersistentVector
Only thing it mentions in the stacktrace [3] is methods on a reify,
which calls the same method again, or in the most recent case, just
return nil.
[1] http://www.minecraft.net/docs/NBT.txt
[2] https://gist.github.com/761997
[3] http://pastebin.com/AqrsbjuS
On Nov 28 2010, 8:14 pm, Zach Tellman wrote:
> You're right, that's an omission from the frame syntax. I'll add the
> ability for all or part of the frame to be scoped as (little-
> endian ...) and (big-endian ...), with big-endian as the default.
>
> Just as a side-note, though, Calx [1] is already handling little-
> endian data by using encode-to-buffer, where it's writing to a buffer
> whose endianness has been preset. This obviously isn't a general
> solution, but just thought I'd point it out.
>
> Zach
>
> [1]https://github.com/ztellman/calx
>
> On Nov 28, 8:50 am, zoka wrote:
>
>
>
>
>
>
>
> > If Gloss is to decode incoming packet (byte array) in little-endian
> > format it is straightforward:
> > Wrap byte array into ByteBuffer b, invoke b.order(LITTLE_ENDIAN) and
> > pass b to decode function that will return Clojure map of decoded
> > values.
>
> > However, when outgoing packet byte array is to be produced from map of
> > values, encode function will always return ByteBuffer in default big-
> > endian format, so resulting byte array extracted form ByteBuffer using
> > get() method will be incorrect.
>
> > If Gloss is to support little-endian frames, it seems that endianness
> > needs to be part of frame definition. In that case Gloss decode fun
> > would refuse to accept ByteBuffers with wrong order() and encode fun
> > will always generate the correct result.
>
> > Zoka
>
> > On Nov 25, 3:00 am, Zach Tellman wrote:
>
> > > ByteBuffers have an order() method which allows you to toggle the
> > > endianness. I haven't tested this, but since everything is built on
> > > top of Java's ByteBuffer functionality it should be fine as long as
> > > the ByteBuffers are correctly set and correctly ordered with respect
> > > to each other.
>
> > > Zach
>
> > > On Nov 23, 2:52 pm, zoka wrote:
>
> > > > JVM stores numbers in in big endian format - is there a way to process
> > > > binary stream containing little endian numbers?
>
> > > > Zoka
>
> > > > On Nov 24, 7:24 am, Zach Tellman wrote:
>
> > > > > Good question. The solution didn't make the cut for my initial
> > > > > release, but will be added soon. My plan is to have an (ordered-
> > > > > map ...) frame which encodes and decodes the keys in the given order.
> > > > > So for C interop, the frame would be
>
> > > > > (ordered-map :a :int16, :b :float32)
>
> > > > > An alternative would be to just turn any vector which is alternating
> > > > > keys and types into an ordered-map, but that seems a bit too magical.
>
> > > > > Zach
>
> > > > > On Nov 23, 12:12 pm, Chris Perkins wrote:
>
> > > > > > On Nov 23, 12:03 pm, Zach Tellman wrote:
>
> > > > > > > When writing Calx [1], I discovered it was a huge pain to deal
> > > > > > > with
> > > > > > > mixed C datatypes in Java. When writing Aleph [2], I discovered
> > > > > > > the
> > > > > > > problem increases by a factor of ten when dealing with streams of
> > > > > > > bytes. In an attempt to alleviate my own pain, and hopefully
> > > > > > > help a
> > > > > > > few other people out, I've written Gloss, which can transform a
> > > > > > > simple
> > > > > > > byte-format specification into an encoder and streaming decoder.
>
> > > > > > > A full writeup can be found
> > > > > > > athttps://github.com/ztellman/gloss/wiki.
>
> > > > > > > A few people have already asked me how this differs from protocol
> > > > > > > buffers, so I'll preemptively answer that protocol buffers are a
> > > > > > > fixed
> > > > > > > format that cannot be used to interface with external systems.
> > > > > > > Gloss
> > > > > > > is less performant than protocol buffers, but is also much less
> > > > > > > picky
> > > > > > > about formats.
>
> > > > > > > If anyone has any questions, I'd be happy to answer them.
>
> > > > > > Looks very useful, Zach. Thanks.
>
> > > > > > I have a question.
>
> > > > > > I have only taken a quick look, so maybe I'm misunderstanding the
> > > > > > intent, but it's not clear to me how you would use this for sending
> > > > > > and receiving structured data from, say, a C program.
>
> > > > > > Taking your example from the wiki:
>
> > > > > > (def fr (compile-frame {:a :int16, :b :float32}))
>
> > > > >
Re: Interesting challenge
According to my tests your squares both satisfy the conditions and are isomorphically unique. - Matjaz On Sat, Jan 1, 2011 at 12:53 PM, Mark Engelberg wrote: > On Thu, Dec 30, 2010 at 9:03 AM, David Nolen > wrote: > > From the Qi mailing list: > > > http://groups.google.com/group/qilang/browse_thread/thread/e4a2f534fad5032a > > "I contend that this kind of problem cannot be solved (efficiently) in > any > > pure functional programming language. You may disagree" > > :D > > David > > Has anyone looked at this yet? I wrote a Clojure program to solve the > challenge, but I keep coming up with a count of 63,422 prime squares, > not 35,953. > > I've posted a text file containing all the prime squares I found: > > https://docs.google.com/leaf?id=0B0JrHNwD7hNSZTBmMzg5ZGEtZWZmZC00ZWI3LTk4MWItMjU2MDljMDBjYjNm&hl=en > > I'd love to have another set of eyes on this. If you find the > challenge interesting, but not enough to want to code the whole solver > from scratch, maybe you could write a verifier to check and make sure > that each of my prime squares satisfies the constraints of the problem > and is unique with respect to isomorphism. I've verified it myself, > but maybe there's some subtlety I'm missing. > > If 63422 is correct and I can get independent confirmation, it would > be fun to go back to the author of the challenge and say "Your C++ > solution may be fast, but in a functional programming language, at > least we get the right answer :) " > > Thanks. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Interesting challenge
Thanks everyone! I'll go post my findings to the Qilang google group. I'll try to moderate the smugness I'm feeling right now :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Gloss, a byte-format DSL
The header->body function in (header ...) must return a codec, so you need to call compile-frame on the vector you're generating. Since you don't want to call compile-frame every time you decode a frame, you can memoize the function. A version that does both can be found at https://gist.github.com/762031. I agree that the way the enumeration and types are blurred in your code is a little confusing. You could create a stronger distinction by calling your enumerated types :tag-byte, :tag-int32, etc, and then defining a map from those tags onto :byte, :int32, and so on. Zach On Jan 1, 1:01 pm, "pepijn (aka fliebel)" wrote: > Hey, > > I am trying Gloss for reading NBT [1] files. > > First thing I did like is that it seems to make things real easy. > First thing I did not like is the weak separation between types > like :byte and extra data like :foo. > > I think I'm nearly done with the NBT reader [2], but I ran into a > problem. Whatever I put in the header form, I get exceptions like > this: > > java.lang.IllegalArgumentException: No implementation of > method: :sizeof of protocol: #'gloss.core.protocols/Writer found for > class: clojure.lang.PersistentVector > > Only thing it mentions in the stacktrace [3] is methods on a reify, > which calls the same method again, or in the most recent case, just > return nil. > > [1]http://www.minecraft.net/docs/NBT.txt > [2]https://gist.github.com/761997 > [3]http://pastebin.com/AqrsbjuS > > On Nov 28 2010, 8:14 pm, Zach Tellman wrote: > > > > > > > > > You're right, that's an omission from the frame syntax. I'll add the > > ability for all or part of the frame to be scoped as (little- > > endian ...) and (big-endian ...), with big-endian as the default. > > > Just as a side-note, though, Calx [1] is already handling little- > > endian data by using encode-to-buffer, where it's writing to a buffer > > whose endianness has been preset. This obviously isn't a general > > solution, but just thought I'd point it out. > > > Zach > > > [1]https://github.com/ztellman/calx > > > On Nov 28, 8:50 am, zoka wrote: > > > > If Gloss is to decode incoming packet (byte array) in little-endian > > > format it is straightforward: > > > Wrap byte array into ByteBuffer b, invoke b.order(LITTLE_ENDIAN) and > > > pass b to decode function that will return Clojure map of decoded > > > values. > > > > However, when outgoing packet byte array is to be produced from map of > > > values, encode function will always return ByteBuffer in default big- > > > endian format, so resulting byte array extracted form ByteBuffer using > > > get() method will be incorrect. > > > > If Gloss is to support little-endian frames, it seems that endianness > > > needs to be part of frame definition. In that case Gloss decode fun > > > would refuse to accept ByteBuffers with wrong order() and encode fun > > > will always generate the correct result. > > > > Zoka > > > > On Nov 25, 3:00 am, Zach Tellman wrote: > > > > > ByteBuffers have an order() method which allows you to toggle the > > > > endianness. I haven't tested this, but since everything is built on > > > > top of Java's ByteBuffer functionality it should be fine as long as > > > > the ByteBuffers are correctly set and correctly ordered with respect > > > > to each other. > > > > > Zach > > > > > On Nov 23, 2:52 pm, zoka wrote: > > > > > > JVM stores numbers in in big endian format - is there a way to process > > > > > binary stream containing little endian numbers? > > > > > > Zoka > > > > > > On Nov 24, 7:24 am, Zach Tellman wrote: > > > > > > > Good question. The solution didn't make the cut for my initial > > > > > > release, but will be added soon. My plan is to have an (ordered- > > > > > > map ...) frame which encodes and decodes the keys in the given > > > > > > order. > > > > > > So for C interop, the frame would be > > > > > > > (ordered-map :a :int16, :b :float32) > > > > > > > An alternative would be to just turn any vector which is alternating > > > > > > keys and types into an ordered-map, but that seems a bit too > > > > > > magical. > > > > > > > Zach > > > > > > > On Nov 23, 12:12 pm, Chris Perkins wrote: > > > > > > > > On Nov 23, 12:03 pm, Zach Tellman wrote: > > > > > > > > > When writing Calx [1], I discovered it was a huge pain to deal > > > > > > > > with > > > > > > > > mixed C datatypes in Java. When writing Aleph [2], I > > > > > > > > discovered the > > > > > > > > problem increases by a factor of ten when dealing with streams > > > > > > > > of > > > > > > > > bytes. In an attempt to alleviate my own pain, and hopefully > > > > > > > > help a > > > > > > > > few other people out, I've written Gloss, which can transform a > > > > > > > > simple > > > > > > > > byte-format specification into an encoder and streaming decoder. > > > > > > > > > A full writeup can be found > > > > > > > > athttps://github.com/ztellman/gloss/wiki. > > > > > > > > > A few people have already asked me how this differs from >
a loop gives boxing warning when it shouldn't
Hi all, I'd apreciate help on figuring out why a loop gets number boxing warnings, when it shouldn't: http://clojure.pastebin.com/9uLZqGhy I'm using clojure from: commit f30995c86056959abca53d0ca35dcb9cfa73e6e6 Author: Stuart Halloway Date: Fri Dec 17 15:17:20 2010 -0500 Thanks. Albert -- http://albert.rierol.net -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Compiling dynamically created namespaces, without on-disk source code?
the `(binding [*compile-files* true] ...)` trick does not seem to work for me. Still looking for something that does. What do you mean by "the bytecode is no longer accessible" ? Wouldn't it have to be in there somewhere in order to use the definition? thank you, --Robert McIntyre On Thu, Dec 30, 2010 at 8:45 PM, Stuart Sierra wrote: > You might try `(binding [*compile-files* true] ...)` around whatever code > creates the namespace. Can't promise that will work. > This still won't let you save definitions entered at the REPL. Once they're > compiled and loaded into the JVM, the bytecode is no longer accessible. > > -Stuart Sierra > clojure.com > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
can I force the JIT to be called immediately for certain pieces of code after it starts executing with out waiting for the JVM realize it is necessary....
Hello Everybody, can I force the JIT to be called immediately for certain pieces of code after it starts executing with out waiting for the JVM realize it is necessary? I would not mind jitting the whole code .. Actually I don't mind waiting a few extra seconds at the start since actual run-time for the program could be a couple of hundred minutes... Is startup time the only reason why the whole code is not jitted immediately.. ? Is there a way to find out which piece of code is getting jitted .. and when? thanks, Sunil. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: can I force the JIT to be called immediately for certain pieces of code after it starts executing with out waiting for the JVM realize it is necessary....
On Jan 1, 8:29 pm, Sunil S Nandihalli wrote: > Hello Everybody, > can I force the JIT to be called immediately for certain pieces of code > after it starts executing with out waiting for the JVM realize it is > necessary? I would not mind jitting the whole code .. Actually I don't > mind waiting a few extra seconds at the start since actual run-time for the > program could be a couple of hundred minutes... If the program is going to be running for that long anyways, why do you care? > Is startup time the only reason why the whole code is not jitted > immediately.. ? Even if the JVM put the code through the compiler right away, the resulting code wouldn't be very good because it will have not had time to profile code to apply the more powerful optimizations. It would be throwing all of that code away once it has had time to profile the code, so any time spent JITing the code before then is most likely not worth it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: can I force the JIT to be called immediately for certain pieces of code after it starts executing with out waiting for the JVM realize it is necessary....
> > > Even if the JVM put the code through the compiler right away, the > resulting code wouldn't be very good because it will have not had time > to profile code to apply the more powerful optimizations. It would be > throwing all of that code away once it has had time to profile the > code, so any time spent JITing the code before then is most likely not > worth it. Exactly. You can't apply Just-In-Time techniques Ahead-Of-Time. Pretty much by definition. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
