News aggregator

Looking for feedback - emulating a 1-bit register with a Neural Network

Haskell on Reddit - Tue, 01/27/2015 - 6:39pm

I wrote a bit of background about the project over at /r/compsci: http://www.reddit.com/r/compsci/comments/2tw5vc/emulating_a_1bit_register_with_a_neural_network/

I'm pretty new to Haskell so I'm sure there are lot's of problems. The repo can be found here: https://bitbucket.org/rickdzekman/memnet

I was hoping to get some feedback on my Haskell implementation. Though if you have any general comments about the concept I'm keen to hear them.

Some things that I think are weaknesses:

  • I don't encapsulate the non-termination aspect at all. I've looked at IterT as well as Pipes, but I settled on writing a simple loop.
  • I also wrote my own Semaphores using MVars instead of using something like Pipes.
  • The way inputs/outputs are passed to/from the network is a bit haphazard. I basically take a number, convert it to bits, map those bits to node IDs in the network, and then do the inverse for outputs. It might have been easier to actually use bits, where as I used Bools.
  • I've been told I should look into Vectors rather than Arrays for my mutable state.This proof of concept is so basic that I didn't look at performance at all. But my Node type is so simple, that apparently I should be able to use Unboxed Vectors.

I'm aware the GUI is terrible! I'm on Windows and had heaps of trouble with GTK. When I finally did get it up and running the non-termination of my main program caused GTK to crash. Gloss on the other hand was really simple to setup.

I've had a few raised eyebrows about the way I mix IO and ST. Perhaps it's my imperative background coming through here. But I use an STArray to avoid copying the entire network of Node's each time they pass a message between each other (considering the network is cyclic, it also avoids passing the knot). I then thread the state within an IO loop, extracting output information via runSTArray. That particular bit is here: https://bitbucket.org/rickdzekman/memnet/src/6f3006e39405f91d53dc278dd4d2bc4e2c4a5756/src/AI/MemNet/RunMemNet.hs?at=master

As a Haskell newbie (who also isn't a professional programmer) I would really appreciate some feedback from the more knowledgeable people out there.

submitted by rick_dz
[link] [2 comments]
Categories: Incoming News

The GHC Team: GHC Weekly News - 2015/01/27

Planet Haskell - Tue, 01/27/2015 - 3:03pm

Hi *,

It's time for some GHC Weekly news!

  • Austin took the time the past week to check `./validate --slow` failures, and is planning on filing bugs and fixes for the remaining failures soon. Afterwords, we'll immediately begin enabling --slow on Phabricator, so developers get their patches tested more thoroughly.
  • The 7.10 release looks like it will likely not have a 3rd Release Candidate, and will be released in late Feburary of 2015, as we originally expected.
  • The 7.10 branch currently has two showstopping bugs we plan on hitting before the final release. And we'd really like for users to test so we can catch more!
  • Austin Seipp will likely be gone for the coming week in a trip to New York City from the 28th to the 4th, meaning (much to the dismay of cheering crowds) you'd better catch him beforehand if you need him! (Alternatively Austin will be held back due to an intense snowstorm developing in NYC. So, we'll see!)
  • Austin is planning on helping the LLVM support in HEAD soon; after coordinating with Ben Gamari, we're hoping to ship GHC 7.12 with (at least) LLVM 3.6 as an officially supported backend, based on the documentation described in ​https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend - lots of thanks to Ben for working with upstream to file bugs and improve things!

And in other news, through chatter on the mailing list and Phabricator, we have:

  • Peter Trommler posted his first version of a native Linux/PowerPC 64bit code generator! There's still a lot more work to do, but this is a significantly improved situation over the unregisterised C backend. Curious developers can see the patch at ​Phab:D629.
  • A long, ongoing thread started by Richard Eisenberg about the long-term plans for the vectorisation code have been posted. The worry is that the vectoriser as well as DPH have stagnated in development, which costs other developers any time they need to build GHC, make larger changes, or keep code clean. There have been a lot of varied proposals in the thread from removing the code to commenting it out, to keeping it. It's unclear what the future holds, but the discussion still rages on. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html
  • Alexander Vershilov made a proposal to the GHC team: can we remove the transformers dependency? It turns out to be a rather painful dependency for users of the GHC API and of packages depending on transformers, as you cannot link against any version other than the one GHC ships, causing pain. The alternative proposal involves splitting off the transformers dependency into a package of Orphan instances. The final decision isn't yet clear, nor is a winner in clear sight yet! ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008058.html
  • Simon Marlow has started a long thread about the fate of records in future GHC versions. Previously, Adam Gundry had worked on OverloadedRecordFields. And now Nikita Volkov has introduced his records library which sits in a slightly different spot in the design space. But now the question is - how do we proceed? Despite all prior historical precedent, it looks like there's finally some convergence on a reasonable design that can hit GHC in the future. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008049.html

Closed tickets the past two weeks include: #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, #9836, #10008, #9856, #9975, #10013, #9949, #9953, #9856, #9955, #9867, #10015, #9961, #5364, #9928, and #10028.

Categories: Offsite Blogs

The GHC Team: weekly20150127

Planet Haskell - Tue, 01/27/2015 - 3:01pm

Hi *,

It's time for some GHC Weekly news! <Insert funny Austin-ish blurb>

  • Austin took the time the past week to check `./validate --slow` failures, and is planning on filing bugs and fixes for the remaining failures soon. Afterwords, we'll immediately begin enabling --slow on Phabricator, so developers get their patches tested more thoroughly.
  • The 7.10 release looks like it will likely not have a 3rd Release Candidate, and will be released in late Feburary of 2015, as we originally expected.
  • The 7.10 branch currently has two showstopping bugs we plan on hitting before the final release. And we'd really like for users to test so we can catch more!
  • Austin Seipp will likely be gone for the coming week in a trip to New York City from the 28th to the 4th, meaning (much to the dismay of cheering crowds) you'd better catch him beforehand if you need him! (Alternatively Austin will be held back due to an intense snowstorm developing in NYC. So, we'll see!)
  • Austin is planning on helping the LLVM support in HEAD soon; after coordinating with Ben Gamari, we're hoping to ship GHC 7.12 with (at least) LLVM 3.6 as an officially supported backend, based on the documentation described in ​https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend - lots of thanks to Ben for working with upstream to file bugs and improve things!

And in other news, through chatter on the mailing list and Phabricator, we have:

  • Peter Trommler posted his first version of a native Linux/PowerPC 64bit code generator! There's still a lot more work to do, but this is a significantly improved situation over the unregisterised C backend. Curious developers can see the patch at ​Phab:D629.
  • A long, ongoing thread started by Richard Eisenberg about the long-term plans for the vectorisation code have been posted. The worry is that the vectoriser as well as DPH have stagnated in development, which costs other developers any time they need to build GHC, make larger changes, or keep code clean. There have been a lot of varied proposals in the thread from removing the code to commenting it out, to keeping it. It's unclear what the future holds, but the discussion still rages on. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html
  • Alexander Vershilov made a proposal to the GHC team: can we remove the transformers dependency? It turns out to be a rather painful dependency for users of the GHC API and of packages depending on transformers, as you cannot link against any version other than the one GHC ships, causing pain. The alternative proposal involves splitting off the transformers dependency into a package of Orphan instances. The final decision isn't yet clear, nor is a winner in clear sight yet! ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008058.html
  • Simon Marlow has started a long thread about the fate of records in future GHC versions. Previously, Adam Gundry had worked on OverloadedRecordFields. And now Nikita Volkov has introduced his records library which sits in a slightly different spot in the design space. But now the question is - how do we proceed? Despite all prior historical precedent, it looks like there's finally some convergence on a reasonable design that can hit GHC in the future. ​https://www.haskell.org/pipermail/ghc-devs/2015-January/008049.html

Closed tickets the past two weeks include: #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, #9836, #10008, #9856, #10009, #10011, #9975, #10013, #9949, #9953, #9856, #9955, #9867, #10015, #9961, #5364, #9928, and #10028.

Categories: Offsite Blogs

Multi-pattern LambdaCase?

haskell-cafe - Tue, 01/27/2015 - 2:38pm
Is there a particular reason that LambdaCase does not support muliple patterns? Specifically I am suggesting that \case { pA1 pA2 pA3 -> eA, ... } be sugar for \freshName1 freshName2 freshName3 -> case freshName1 freshName2 freshName3 of { pA1 pA2 pA3 -> eA, ... } Is there some technical reason that prevents it? Tom
Categories: Offsite Discussion

Drastic Prelude changes imminent

General haskell list - Tue, 01/27/2015 - 12:52pm
If you didn't know that, e.g., the type of foldr is changing, check out the thread https://www.haskell.org/pipermail/libraries/2015-January/024777.html. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utili
Categories: Incoming News

Drastic Prelude changes imminent

libraries list - Tue, 01/27/2015 - 12:32pm
The next version (7.10) of GHC is slated to have a drastically changed Prelude. This message is very late in the release process, but I would urge caution before changing. The changes are (aptly) named the Burning Bridges Proposal (BBP). Even though the work has been going on for a while, it seems that this change is coming as a surprise to many people (including Simon Peyton Jones). In summary, it generalizes many list operation, e.g., foldr, to be overloaded. There is much to welcome in BBP, but changing the Prelude cannot be done lightly since it really is like changing the language. So I think it's really important for a large number of people to be able to try out such changes before they come into effect, and to have time to let the changes stabilize (you rarely get it right the first time). I've discussed this with a number of people, including Simon PJ, and we have concrete proposals. Proposal 1: * Add a new pragma {-# LANGUAGE Prelude=AlternativePrelude #-} * This is a new fe
Categories: Offsite Discussion

Why don't all new languages use (functor,monad,etc) abstractions in there main libraries?

Haskell on Reddit - Tue, 01/27/2015 - 12:05pm

It always bother me. Even if language have side effects and doesn't really need IO, almost every language will have Maybe, List, Cont, etc so they need map, bind, etc. Why don't they use well known abstractions?

submitted by dotneter
[link] [40 comments]
Categories: Incoming News

How to force James Cook (author of dependent-map)evaluation?

haskell-cafe - Tue, 01/27/2015 - 12:01pm
Hello people. There is a pull request https://github.com/mokus0/dependent-map/pull/2 which I need to be on hackage. I have sent a email to mokus< at >deepbondi.net but nothing happened. Does anyone can contact with James and tell him about my problem? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

sinelaw/inferno · GitHub

del.icio.us/haskell - Tue, 01/27/2015 - 11:09am
Categories: Offsite Blogs

Is Haskell` (Haskell Prime) Defunct?

Haskell on Reddit - Tue, 01/27/2015 - 6:59am

With all these changes in GHC[1], such as the BBP and AMP proposals, I wonder why there hasn't been any visible movement in the Haskell` committee. As this subreddit thread poignantly notices, we haven't seen a new standard since the 2010 standard. Also note that the thread was started almost two years ago with no movement.

So, my questions are as follows:

  • If new standards aren't being written [2], what is the point of the committee existing?

  • Are the same individuals who are (or in 2015 will be) a part of the committee the same ones driving GHC changes? If so, I wonder if implementing things directly in GHC is viewed as a way to side step the issue of having a feature evaluated by the committee (assuming again, I understand the point of such a committee to begin with).

[1] While GHC is only an implementation of Haskell, that it's distributed with the Hskell Platform and that there hasn't been a lot of (public) news related to other implementations (such as JHC), it could be argued that it's the Haskell implementation.

[2] I don't mean to trivialize the work involved in writing a new standard, but rather to say that if new standards haven't been written in so long, it seems misleading to have a committee who's sole purpose seems to be to update said standard. Especially given that the original motivation of the committee (as I understand it) was to motivate the updating of such a standard.

submitted by emarshall85
[link] [24 comments]
Categories: Incoming News