Re: [Haskell-cafe] Re: Implementing unionAll
BTW, I notice that your merges, like mine, are left-biased. This is a useful property (my callers require it), and doesn't seem to cost anything to implement, so maybe you could commit to it in the documentation? By left-biased I mean that when elements compare equal, pick the leftmost one, e.g. mergeOn fst [(0, 'a')] [(0, 'b')] == [(0, 'a'), (0, 'b')]. And BTW again, here's something I've occasionally found useful: -- | Handy to merge or sort a descending list. reverse_compare :: (Ord a) = a - a - Ordering reverse_compare a b = case compare a b of LT - GT EQ - EQ GT - LT ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Fwd: Re: [Haskell-cafe] Category Theory woes]
As well as books and reading material online, nowadays you can also find video lectures...for example, the following was at the top of Googling category theory video: http://golem.ph.utexas.edu/category/2007/09/the_catsters_on_youtube.html Cheers, Mike. Nick Rudnick wrote: I haven't seen anybody mentioning «Joy of Cats» by Adámek, Herrlich Strecker: It is available online, and is very well-equipped with thorough explanations, examples, exercises funny illustrations, I would say best of university lecture style: http://katmat.math.uni-bremen.de/acc/. (Actually, the name of the book is a joke on the set theorists' book «Joy of Set», which again is a joke on «Joy of Sex», which I once found in my parents' bookshelf... ;-)) Another alternative: Personally, I had difficulties with the somewhat arbitrary terminology, at times a hindrance to intuitive understanding - and found intuitive access by programming examples, and the book was «Computational Category Theory» by Rydeheart Burstall, also now available online at http://www.cs.man.ac.uk/~david/categories/book/, done with the functional language ML. Later I translated parts of it to Haskell which was great fun, and the books content is more beginner level than any other book I've seen yet. The is also a programming language project dedicated to category theory, «Charity», at the university of Calgary: http://pll.cpsc.ucalgary.ca/charity1/www/home.html. Any volunteers in doing a RENAME REFACTORING of category theory together with me?? ;-)) Cheers, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Thu, Feb 18, 2010 at 04:27, Nick Rudnick wrote: I haven't seen anybody mentioning «Joy of Cats» by Adámek, Herrlich Strecker: It is available online, and is very well-equipped with thorough explanations, examples, exercises funny illustrations, I would say best of university lecture style: http://katmat.math.uni-bremen.de/acc/. (Actually, the name of the book is a joke on the set theorists' book «Joy of Set», which again is a joke on «Joy of Sex», which I once found in my parents' bookshelf... ;-)) This book reads quite nicely! I love the illustrations that pervade the technical description, providing comedic relief. I might have to go back a re-learn CT... again. Excellent recommendation! For those looking for resources on category theory, here are my collected references: http://www.citeulike.org/user/spl/tag/category-theory Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Implementing unionAll
Leon Smith wrote: On Wed, Feb 17, 2010 at 6:58 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Ah, I meant to use the union' from your previous message, but I think that doesn't work because it doesn't have the crucial property that the case union (VIP x xs) ys = ... does not pattern match on the second argument. Ahh yes, my original union' has a bit that looks like this union' (VIP x xs) (VIP y ys) = case cmp x y of LT - VIP x (union' xs (VIP y ys)) EQ - VIP x (union' xs ys) GT - error Data.List.Ordered.unionAll: assumption violated! union' (VIP x xs) (Crowd ys) = VIP x (union' xs (Crowd ys)) For whatever reason, this works in the case of an infinite number of lists with my original version, but not the simplified version. By applying a standard transformation to make this lazier, we can rewrite these clauses as union' (VIP x xs) ys = VIP x $ case ys of Crowd _ - union' xs ys VIP y yt - case cmp x y of LT - union' xs ys EQ - union' xs yt GT - error msg Oops, I missed this simple rewrite, mainly because the GT case did not start with the VIP x constructor. :D Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linear programming in Haskell
I've no idea about the GLPK system. But, isn't it the case that you can transform any linear inequality into a linear equality and a slack (or excess) variable? That's actually what you *need to do* to turn the problem into the canonical form, so that simplex can handle it. 2010/2/17 Daniel Peebles pumpkin...@gmail.com Interesting. Do you have any details on this? It seems like it would be hard to express system of linear inequalities as a finite system of linear equations. Thanks, Dan 2010/2/17 Matthias Görgens matthias.goerg...@googlemail.com As far as I can see, you'd use that for systems of linear equalities, but for systems of linear inequalities with a linear objective function, it's not suitable. I may be wrong though :) There's a linear [1] reduction from one problem to the other and vice versa. [1] The transformation itself is a linear function, and it takes O(n) time, too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Friedberg numberings.
Hello! The question is not about Haskell, but I don't know where else to ask. In the book Computable functions by Vereshchagin and Shen it is said that it is possible to invent a programming language such that each programming problem has a unique solution in it. The author claims that this statement is a rewording of the theorem, that there is a universal computable function, such that any computable function has exactly one number. I wonder has such language been actually constructed? the book itself (look at the bottom of p 30 for the statement): http://books.google.ru/books?id=A6uvsks0abgCpg=PA30#v=onepageq=f=false ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re : Friedberg numberings
Hi,
In fact it is not quite hard to see that such a numbering exists : just take
any numbering of all Turing machines, say {\phi_i}, then remove all indices i
such that there is ji such that \phi_j = \phi_i (equality is mathematically
correctly defined between functions from N to N).
Ah, and also, notice that what you call a programming language is nothing
else than an enumeration of all Turing machines.
However, if by construction you meant recursive construction, i.e. for
another enumeration (\psi_i), find a Turing machine computing for any i, the
index j such that \phi_j=\psi_i, then it is clear that it is not possible : it
would allow to decide the equality problem for Turing machines.
Hope this helps...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: iteratee-parsec 0.0.1
Iteratee-parsec is a library which allows to have a parsec (3) parser in IterateeG monad. It contains 2 implementations: - John Lato's on public domain. It is based on monoid and design with short parsers in mind. - Mine on MIT. It is based on single-linked mutable list. It seems to be significantly faster for larger parsers - at least in some cases - but it requires a monad with references (such as for example IO or ST). Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? In this case, I would regard it as desirable to -- in best refactoring manner -- to identify a wording in this language instead of the abuse of terminology quite common in maths, e.g. * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), or * the abuse of abandoning imaginary notions in favour person's last names in tribute to successful mathematicians... Actually, that pupils get to know a certain lemma as «Zorn's lemma» does not raise public conciousness of Mr. Zorn (even among mathematicians, I am afraid) very much, does it? * 'folkloristic' dropping of terminology -- even in Germany, where the term «ring» seems to originate from, since at least a century nowbody has the least idea it once had an alternative meaning «gang,band,group», which still seems unsatisfactory... Here computing science has explored ways to do much better than this, and it might be time category theory is claimed by computer scientists in this regard. Once such a project has succeeded, I bet, mathematicians will pick up themselves these work to get into category theory... ;-) As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term * is very general, * reflects well dual asymmetry, * does harmoniously transcend the atomary/structured object perspective -- a an object may be in reference to another *by* substructure (in the beginning, I was quite confused lack of explicit explicatation in this regard, as «arrow/morphism» at least to me impled objekt mapping XOR collection mapping). Categories: In every day's language, a category is a completely different thing, without the least association with a reference system that has a composition which is reflective and associative. To identify a more intuitive term, we can ponder its properties, * reflexivity: This I would interpret as «the references of a category may be regarded as a certain generalization of id», saying that references inside a category represent some kind of similarity (which in the most restrictive cases is equality). * associativity: This I would interpret as «you can *fold* it», i.e. the behaviour is invariant to the order of composing references to composite references -- leading to «the behaviour is completely determined by the lower level reference structure» and therefore «derivations from lower level are possible» Here, finding an appropriate term seems more delicate; maybe a neologism would do good work. Here one proposal: * consequence/?consequentiality? : Pro: Reflects well reflexivity, associativity and duality; describing categories as «structures of (inner) consequence» seems to fit exceptionally well. The pictorial meaning of a «con-sequence» may well reflect the graphical structure. Gives a fine picture of the «intermediating forces» in observation and the «psychologism» becoming possible (- cf. CCCs, Toposes). Con: Personalized meaning has an association with somewhat unfriendly behaviour. Anybody to drop a comment on this? Cheers, Nick Sean Leather wrote: On Thu, Feb 18, 2010 at 04:27, Nick Rudnick wrote: I haven't seen anybody mentioning «Joy of Cats» by Adámek, Herrlich Strecker: It is available online, and is very well-equipped with thorough explanations, examples, exercises funny illustrations, I would say best of university lecture style: http://katmat.math.uni-bremen.de/acc/. (Actually, the name of the book is a joke on the set theorists' book «Joy of Set», which again is a joke on «Joy of Sex», which I once found in my parents' bookshelf... ;-)) This book reads quite nicely! I love the illustrations that pervade the technical description, providing comedic relief. I might have to go back a re-learn CT... again. Excellent recommendation! For those looking for resources on category theory, here are my collected references: http://www.citeulike.org/user/spl/tag/category-theory Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___
Re: [Haskell-cafe] The Related monad and constant values in type classes
I've needed something similar in the past.
I used it in the reflection library, and its present on its own on hackage
as 'tagged'.
http://hackage.haskell.org/packages/archive/tagged/0.0/doc/html/Data-Tagged.html
I talked a bit about using it here:
http://comonad.com/reader/2009/clearer-reflection/
-Edward Kmett
2010/2/17 Jonas Almström Duregård jonas.dureg...@gmail.com
Hi,
This literate haskell file was intended to be a quick question about a
problem i have been pondering, but it developed into a short
presentation instead. What i want to know is if there is already
something like this (and suggestions for improvement of course).
{-#LANGUAGE GeneralizedNewtypeDeriving#-}
Sometimes i find myself needing to associate a constant with a type
or, more precisely, with a type class instance. Something like this
would be nice:
class Sized a where
size :: Int
instance Sized Int where
size = 32
Of course this will not work since there is no way of knowing which
instance i refer to when i use size. A common work-around is to use
a dummy parameter:
class SizedDummy a where
sizeDummy :: a - Int
instance SizedDummy Int where
sizeDummy = const 32
The size function is typically passed an undefined value. This is not
very pretty, and somewhat unsafe. Another workaround is to define a
newtype with a type parameter.
newtype SizeOf a = MkSize {toInt :: Int}
class SizedNewType a where
sizeNewType :: SizeOf a
instance SizedNewType Int where
sizeNewType = MkSize 32
If we want the size of a pair to be the sum of it's components,
something like this is needed:
instance (SizedNewType a, SizedNewType b) = SizedNewType (a,b) where
sizeNewType = sizeNewType' sizeNewType sizeNewType where
sizeNewType' :: SizeOf a - SizeOf b - SizeOf (a,b)
sizeNewType' a b = MkSize $ toInt a + toInt b
This is way to much code say that size = size a + size b. A more
general solution can be achieved by making Int another type variable
of SizeOf. I call the resulting type Related:
newtype Related a b = Related {unrelated :: b} deriving
(Eq,Ord,Show,Read,Bounded,Enum,Fractional,Num,
Real,Integral,RealFrac,Floating,RealFloat)
This type is highly reusable and the GeneralizedNewtypeDeriving
language extension is very practical (although the instances could be
written manually). It can also be used as an Identity monad:
instance Functor (Related a) where
fmap f (Related a) = Related $ f a
instance Monad (Related a) where
return = Related
(Related a) = f = f a
This allows the Sized class and instances to be specified in a slim
fashion using a familiar monadic interface:
class Sized a where
size :: Related a Int
instance Sized Int where
size = return 32
instance (Sized a, Sized b) = Sized (a,b) where
size = do
a - return size :: Sized a = Related (a,b) (Related a Int)
b - return size :: Sized b = Related (a,b) (Related b Int)
return $ unrelated a + unrelated b
This still requires a lot of type signatures, some additional magic is
required. It is possible to write general versions of the type
signatures above, which allows the following instance definition for
(,,):
instance (Sized a, Sized b, Sized c) = Sized (a,b,c) where
size = do
a - on3 size
b - on2 size
c - on1 size
return $ a + b + c
With the derivation of Num, this can be done even more compact:
instance (Sized a, Sized b, Sized c, Sized d) = Sized (a,b,c,d) where
size = on1 size + on2 size + on3 size + on4 size
The code for the onN functions:
rerelate :: Related a b - Related c b
rerelate = return . unrelated
on1 :: Related a v - Related (x a) v
on1 = rerelate
on2 :: Related a v - Related (x a x0) v
on2 = rerelate
on3 :: Related a v - Related (x a x0 x1) v
on3 = rerelate
on4 :: Related a v - Related (x a x0 x1 x2) v
on4 = rerelate
Regards,
Jonas Almström Duregård
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On 18 Feb 2010, at 14:48, Nick Rudnick wrote: * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), I take closed as coming from being closed under limit operations - the origin from analysis. A closure operation c is defined by the property c(c(x)) = c(x). If one takes c(X) = the set of limit points of X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Am Donnerstag 18 Februar 2010 14:48:08 schrieb Nick Rudnick: even in Germany, where the term «ring» seems to originate from, since at least a century nowbody has the least idea it once had an alternative meaning «gang,band,group», Wrong. The term Ring is still in use with that meaning in composites like Schmugglerring, Autoschieberring, ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: sendfile leaking descriptors on Linux?
Excerpts from Bardur Arantsson's message of Wed Feb 17 21:27:07 +0200 2010: For sendfile, a timeout of 1 second would probably be fine. The *ONLY* purpose of threadWaitWrite in the sendfile code is to avoid busy-waiting on EAGAIN from the native sendfile. Of course this will kill connections for all clients that may have a two second network hickup. How so? As a user I expect sendfile to work and not semi-randomly block threads indefinitely. If you want sending something to terminate you will add a timeout to it. A nasty client may e.g. take one byte each minute and sending your file may take a few years. - Taru Karttunen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
On Thu, Feb 18, 2010 at 8:07 AM, Evan Laforge qdun...@gmail.com wrote: And BTW again, here's something I've occasionally found useful: -- | Handy to merge or sort a descending list. reverse_compare :: (Ord a) = a - a - Ordering reverse_compare a b = case compare a b of LT - GT EQ - EQ GT - LT I wondered why there wasn't one of these in the standard library until someone pointed out to me that reverse_compare = flip compare which actually takes fewer characters to type :P ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Related monad and constant values in type classes
Hi Edward Does Tagged have a common synonym as its the 'opposite' of Const? I thought I'd seen the same construction used with Strafunski / StrategyLib, but if I did I can no longer find the examples. Thanks Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hi Daniel,
;-)) agreed, but is the word «Ring» itself in use? The same about the
English language... de.wikipedia says:
« Die Namensgebung /Ring/ bezieht sich nicht auf etwas anschaulich
Ringförmiges, sondern auf einen organisierten Zusammenschluss von
Elementen zu einem Ganzen. Diese Wortbedeutung ist in der deutschen
Sprache ansonsten weitgehend verloren gegangen. Einige
ältereVereinsbezeichnungen /wiki/Verein (wie z. B. Deutscher Ring
/wiki/Deutscher_Ring, Weißer Ring /wiki/Wei%C3%9Fer_Ring_e._V.) oder
Ausdrücke wie „Verbrecherring“ weisen noch auf diese Bedeutung hin. Das
Konzept des Ringes geht auf Richard Dedekind
/wiki/Richard_Dedekind zurück; die Bezeichnung /Ring/ wurde allerdings
von David Hilbert /wiki/David_Hilbert eingeführt.»
(http://de.wikipedia.org/wiki/Ringtheorie)
How many students are wondering confused about what is «the hollow» in a
ring every year worlwide, since Hilbert made this unreflected wording,
by just picking another term around «collection»? Although not a
mathematician, I've visited several maths lectures, for interest, having
the same problem. Then I began asking everybody I could reach -- and
even maths professors could not tell me why this thing is called a «ring».
Thanks for your examples: A «gang» {of smugglers|car thieves} shows even
the original meaning -- once knowed -- does not reflect the
characteristics of the mathematical structure.
Cheers,
Nick
Daniel Fischer wrote:
Am Donnerstag 18 Februar 2010 14:48:08 schrieb Nick Rudnick:
even in Germany, where the
term «ring» seems to originate from, since at least a century nowbody
has the least idea it once had an alternative meaning «gang,band,group»,
Wrong. The term Ring is still in use with that meaning in composites like
Schmugglerring, Autoschieberring, ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CURL and threads
Hi, Your code forks off N threads to do HTTP response checking, then waits for the reply (invokeThreads). Each thread (runHTTPThread) calls curlGetResponse and *immediately* sends the answer back down the channel to invokeThreads (checkAuthResponse) -- then waits for half a second before terminating. As soon as the original process (invokeThreads) has all N responses, it forks off N threads again. So if your code manages to process the N requests such that it can do them all in, say, 0.05 seconds, you'll have about ten times as many threads in your system as you intended (because they all hang around for 0.5 seconds after completing their work). I suspect what you intended to do was put that threadDelay call *before* sending back the response, which would prevent this leaking of threads. Some quick style suggestions: your recursion pattern in dumpChannel is easily replaced with replicateM, and your infinite recursion in invokeThreads could easily become the function forever. Never recurse directly if a combinator can remove the need :-) Your code could easily be accomplished in CHP (http://hackage.haskell.org/package/chp). runParMapM would solve your exact problem easily; you could replace your code with: module NTLMTest where import Control.Monad.Trans (liftIO) import Control.Applicative (($)) import System.IO import Network.Curl import Control.Concurrent.CHP type ResponseState = Either Bool String isResponseOk :: String - CurlResponse - ResponseState isResponseOk username response = case respCurlCode response of CurlOK - Left True _ - Right $ username ++ = ++ respStatusLine response ++ :: ++ (show . respStatus $ response) -- Note: I re-ordered the parameters to this function checkAuthResponse :: String - String - String - IO ResponseState checkAuthResponse url user passwd = isResponseOk user $ curlGetResponse_ url [CurlHttpAuth [HttpAuthAny], CurlUserPwd $ user ++ : ++ passwd] url = http://localhost:8082/; credentials = map (\i - (user ++ show i,123456)) [1..21] main = runCHP_ $ runParMapM (liftIO . uncurry (checkAuthResponse url)) credentials = mapM (liftIO . either (const $ return ()) putStrLn) That above version will get all the responses in parallel and print them out once they are all done, and is quite short. This isn't what your original code did though -- that read the responses from a channel and printed them as they arrived. The below version is probably the closest CHP version to your original code: module NTLMTest where import Control.Monad (replicateM_, (=)) import Control.Monad.Trans (liftIO) import Control.Applicative (($)) import System.IO import Network.Curl import Control.Concurrent.CHP type ResponseState = Either Bool String isResponseOk :: String - CurlResponse - ResponseState isResponseOk username response = case respCurlCode response of CurlOK - Left True _ - Right $ username ++ = ++ respStatusLine response ++ :: ++ (show . respStatus $ response) -- Note: I re-ordered the parameters to this function checkAuthResponse :: String - String - String - IO ResponseState checkAuthResponse url user passwd = isResponseOk user $ curlGetResponse_ url [CurlHttpAuth [HttpAuthAny], CurlUserPwd $ user ++ : ++ passwd] url = http://localhost:8082/; credentials = map (\i - (user ++ show i,123456)) [1..21] main = runCHP_ $ do chan - anyToOneChannel runParallel_ $ dumpChannel (reader chan) : map (claim (writer chan) . writeValue = liftIO . uncurry (checkAuthResponse url)) credentials where dumpChannel :: Chanin ResponseState - CHP () dumpChannel c = replicateM_ (length credentials) (readChannel c = liftIO . either (const $ return ()) putStrLn) This version runs the dumpChannel procedure in parallel with a thread for each credential that writes the result to a shared channel (claiming it as it does so). Neither of my versions checks the credentials repeatedly like yours does, but you can easily add that in. If you're not a point-free fan (I find it irresistible these days), I can break those solutions down a bit into more functions. Hope that helps, Neil. Eugeny N Dzhurinsky wrote: On Wed, Feb 17, 2010 at 07:34:07PM +0200, Eugene Dzhurinsky wrote: Hopefully, someone could help me in overcoming my ignorance :) I realized that I can share the same Chan instance over all invocations in main, and wrap internal function into withCurlDo to ensure only one IO action gets executed with this library. Finally I've come with the following code, which however still has some memory leaks. May be someone will get an idea what's wrong below? = module NTLMTest where import System.IO import Network.Curl import
Re: [Haskell-cafe] Linear programming in Haskell
The trick is to use only non-negative variables for the equations. (That's considered OK in linear programming. Though you may consider it cheating.) By the way, linear programming over rational numbers is in P. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linear programming in Haskell
But, isn't it the case that you can transform any linear inequality into a linear equality and a slack (or excess) variable? That's actually what you *need to do* to turn the problem into the canonical form, so that simplex can handle it. Yes. The simplex is usually implemented in this form. If you just want to play around with linear programming in Haskell, you could try write an FFI wrapper aruond SCIP (http://scip.zib.de/). (Though the licence of scip is probably not what you want. But there are other solvers available, too.) The domain specific language (and compiler of the same name) ZIMPL may be worth a look for linear programming. (http://zimpl.zib.de/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Am Donnerstag 18 Februar 2010 17:10:08 schrieb Nick Rudnick:
Hi Daniel,
;-)) agreed, but is the word «Ring» itself in use?
Of course, many people wear rings on their fingers.
Oh - you meant in the sense of gang/group?
It still appears as part of the name of some groups as a word of its own,
otherwise, I can at the moment only recall its use in compounds.
The same about the
English language... de.wikipedia says:
« Die Namensgebung /Ring/ bezieht sich nicht auf etwas anschaulich
Ringförmiges, sondern auf einen organisierten Zusammenschluss von
Elementen zu einem Ganzen.
I don't know whether that's correct.
It may be, but then the french anneau is a horrible mistranslation.
Diese Wortbedeutung ist in der deutschen
Sprache ansonsten weitgehend verloren gegangen. Einige
ältereVereinsbezeichnungen /wiki/Verein (wie z. B. Deutscher Ring
/wiki/Deutscher_Ring, Weißer Ring /wiki/Wei%C3%9Fer_Ring_e._V.) oder
Ausdrücke wie „Verbrecherring“ weisen noch auf diese Bedeutung hin. Das
Konzept des Ringes geht auf Richard Dedekind
/wiki/Richard_Dedekind zurück; die Bezeichnung /Ring/ wurde allerdings
von David Hilbert /wiki/David_Hilbert eingeführt.»
(http://de.wikipedia.org/wiki/Ringtheorie)
How many students are wondering confused about what is «the hollow» in a
ring every year worlwide, since Hilbert made this unreflected wording,
You know, a field is a Körper in german, (corps in french), a Ring
is a Körper with a hole in it (no division in general).
by just picking another term around «collection»? Although not a
mathematician, I've visited several maths lectures, for interest, having
the same problem. Then I began asking everybody I could reach -- and
even maths professors could not tell me why this thing is called a
«ring».
That's often a problem with things that were named by Germans in the
nineteenth or early twentieth century. They had pretty undecipherable ways
of choosing metaphors and coming up with weird associations.
Thanks for your examples: A «gang» {of smugglers|car thieves} shows even
the original meaning -- once knowed -- does not reflect the
characteristics of the mathematical structure.
Cheers,
Nick
Daniel Fischer wrote:
Am Donnerstag 18 Februar 2010 14:48:08 schrieb Nick Rudnick:
even in Germany, where the
term «ring» seems to originate from, since at least a century nowbody
has the least idea it once had an alternative meaning
«gang,band,group»,
Wrong. The term Ring is still in use with that meaning in composites
like Schmugglerring, Autoschieberring, ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.dewrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) If memory serves, MacLane says somewhere that he and Eilenberg picked the term category as an explicit play on the same term in philosophy. In general I find mathematical terminology well-chosen and revealing, if one takes the trouble to do a little digging. If you want to know what terminological chaos really looks like try linguistics. -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can i run darcs in ghci?
On Tue, Feb 16, 2010 at 12:17 AM, Marc Weber marco-owe...@gmx.de wrote: Any help on how to load the .h is greatly appreciated. I tried -i with path to the src directory but it didn't work (should it?). Try -I -i is used for .hs files only (?). This seems like a missing feature in cabal or ghci. In the past darcs used a makefile and it was possible to type, 'make ghci' and you'd be dumped at the ghci prompt with everything ready. Perhaps the right way to get this feature is to write a plugin for ghci to add this. I'm thinking the plugin would use the cabal library to understand a .cabal file and then instruct ghci in how to load each module that is requested (making sure CPP and flags are dealt with correctly and dependency order is respected). When a .cabal file provides all the modules as a library (as is the case with darcs), you can install the library and then instruct ghci to load the right package. From inside ghci you can then :m + the modules you want to use. The downside to this is that only things exported from the modules are visible and every time you change the source you have to reinstall and restart ghci. So, something like this: cabal install foo-1.2 ghci -package foo-1.2 :m + Data.Foo I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Related monad and constant values in type classes
Hi Edward,
Nothing new under the sun it would seem :).
Perhaps these functions could be useful in the Tagged library?
on1 :: Tagged a v - Tagged (x a) v
on1 = retag
on2 :: Tagged a v - Tagged (x a x0) v
on2 = retag
on3 :: Tagged a v - Tagged (x a x0 x1) v
on3 = retag
on4 :: Tagged a v - Tagged (x a x0 x1 x2) v
on4 = retag
They allow the user to perform operations on the type parameters of an
instantiated type without adding a lot of additional type signatures
etc., e.g.
instance SomeClass a = SomeClass [a] where
someFunction = on1 someFunction
/Jonas
2010/2/18 Edward Kmett ekm...@gmail.com:
I've needed something similar in the past.
I used it in the reflection library, and its present on its own on hackage
as 'tagged'.
http://hackage.haskell.org/packages/archive/tagged/0.0/doc/html/Data-Tagged.html
I talked a bit about using it here:
http://comonad.com/reader/2009/clearer-reflection/
-Edward Kmett
2010/2/17 Jonas Almström Duregård jonas.dureg...@gmail.com
Hi,
This literate haskell file was intended to be a quick question about a
problem i have been pondering, but it developed into a short
presentation instead. What i want to know is if there is already
something like this (and suggestions for improvement of course).
{-#LANGUAGE GeneralizedNewtypeDeriving#-}
Sometimes i find myself needing to associate a constant with a type
or, more precisely, with a type class instance. Something like this
would be nice:
class Sized a where
size :: Int
instance Sized Int where
size = 32
Of course this will not work since there is no way of knowing which
instance i refer to when i use size. A common work-around is to use
a dummy parameter:
class SizedDummy a where
sizeDummy :: a - Int
instance SizedDummy Int where
sizeDummy = const 32
The size function is typically passed an undefined value. This is not
very pretty, and somewhat unsafe. Another workaround is to define a
newtype with a type parameter.
newtype SizeOf a = MkSize {toInt :: Int}
class SizedNewType a where
sizeNewType :: SizeOf a
instance SizedNewType Int where
sizeNewType = MkSize 32
If we want the size of a pair to be the sum of it's components,
something like this is needed:
instance (SizedNewType a, SizedNewType b) = SizedNewType (a,b) where
sizeNewType = sizeNewType' sizeNewType sizeNewType where
sizeNewType' :: SizeOf a - SizeOf b - SizeOf (a,b)
sizeNewType' a b = MkSize $ toInt a + toInt b
This is way to much code say that size = size a + size b. A more
general solution can be achieved by making Int another type variable
of SizeOf. I call the resulting type Related:
newtype Related a b = Related {unrelated :: b} deriving
(Eq,Ord,Show,Read,Bounded,Enum,Fractional,Num,
Real,Integral,RealFrac,Floating,RealFloat)
This type is highly reusable and the GeneralizedNewtypeDeriving
language extension is very practical (although the instances could be
written manually). It can also be used as an Identity monad:
instance Functor (Related a) where
fmap f (Related a) = Related $ f a
instance Monad (Related a) where
return = Related
(Related a) = f = f a
This allows the Sized class and instances to be specified in a slim
fashion using a familiar monadic interface:
class Sized a where
size :: Related a Int
instance Sized Int where
size = return 32
instance (Sized a, Sized b) = Sized (a,b) where
size = do
a - return size :: Sized a = Related (a,b) (Related a Int)
b - return size :: Sized b = Related (a,b) (Related b Int)
return $ unrelated a + unrelated b
This still requires a lot of type signatures, some additional magic is
required. It is possible to write general versions of the type
signatures above, which allows the following instance definition for
(,,):
instance (Sized a, Sized b, Sized c) = Sized (a,b,c) where
size = do
a - on3 size
b - on2 size
c - on1 size
return $ a + b + c
With the derivation of Num, this can be done even more compact:
instance (Sized a, Sized b, Sized c, Sized d) = Sized (a,b,c,d) where
size = on1 size + on2 size + on3 size + on4 size
The code for the onN functions:
rerelate :: Related a b - Related c b
rerelate = return . unrelated
on1 :: Related a v - Related (x a) v
on1 = rerelate
on2 :: Related a v - Related (x a x0) v
on2 = rerelate
on3 :: Related a v - Related (x a x0 x1) v
on3 = rerelate
on4 :: Related a v - Related (x a x0 x1 x2) v
on4 = rerelate
Regards,
Jonas Almström Duregård
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hi Hans, agreed, but, in my eyes, you directly point to the problem: * doesn't this just delegate the problem to the topic of limit operations, i.e., in how far is the term «closed» here more perspicuous? * that's (for a very simple concept) the way that maths prescribes: + historical background: «I take closed as coming from being closed under limit operations - the origin from analysis.» + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). If one takes c(X) = the set of limit points of X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed.» 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? The most fundamentalist justification I heard in this regard is: «It keeps people off from thinking the could go without the definition...» Meanwhile, we backtrack definition trees filling books, no, even more... In my eyes, this comes equal to claiming: «You have nothing to understand this beyond the provided authoritative definitions -- your understanding is done by strictly following these.» Back to the case of open/closed, given we have an idea about sets -- we in most cases are able to derive the concept of two disjunct sets facing each other ourselves, don't we? The only lore missing is just a Bool: Which term fits which idea? With a reliable terminology using «bordered/unbordered», there is no ambiguity, and we can pass on reading, without any additional effort. Picking such an opportunity thus may save a lot of time and even error -- allowing you to utilize your individual knowledge and experience. I have hope that this approach would be of great help in learning category theory. All the best, Nick Hans Aberg wrote: On 18 Feb 2010, at 14:48, Nick Rudnick wrote: * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), I take closed as coming from being closed under limit operations - the origin from analysis. A closure operation c is defined by the property c(c(x)) = c(x). If one takes c(X) = the set of limit points of X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Heterogeneous Data Structures - Nested Pairs and functional references
Hi Alexander, sry for being a bit thick, but how would this code be used? I'm unable to figure out the application yet. Could you give some examples how you use it? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de mailto:joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) Are you sure...?? See http://en.wikipedia.org/wiki/Categories_(Aristotle) ... If memory serves, MacLane says somewhere that he and Eilenberg picked the term category as an explicit play on the same term in philosophy. In general I find mathematical terminology well-chosen and revealing, if one takes the trouble to do a little digging. If you want to know what terminological chaos really looks like try linguistics. ;-) For linguistics, granted... In regard of «a little digging», don't you think terminology work takes a great share, especially at interdisciplinary efforts? Wouldn't it be great to be able to drop, say 20% or even more, of such efforts and be able to progress more fluidly ? -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Category Theory woes
- Forwarded Message - From: Michael Matsko msmat...@comcast.net To: Nick Rudnick joerg.rudn...@t-online.de Sent: Thursday, February 18, 2010 2:16:18 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg, Topologically speaking, the border of an open set is called the boundary of the set. The boundary is defined as the closure of the set minus the set itself. As an example consider the open interval (0,1) on the real line. The closure of the set is [0,1], the closed interval on 0, 1. The boundary would be the points 0 and 1. Mike Matsko - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Gregg Reynolds d...@mobileink.com Cc: Haskell Café List haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 1:55:31 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) Are you sure...?? See http://en.wikipedia.org/wiki/Categories_(Aristotle) ... If memory serves, MacLane says somewhere that he and Eilenberg picked the term category as an explicit play on the same term in philosophy. In general I find mathematical terminology well-chosen and revealing, if one takes the trouble to do a little digging. If you want to know what terminological chaos really looks like try linguistics. ;-) For linguistics, granted... In regard of «a little digging», don't you think terminology work takes a great share, especially at interdisciplinary efforts? Wouldn't it be great to be able to drop, say 20% or even more, of such efforts and be able to progress more fluidly ? -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Am Donnerstag 18 Februar 2010 19:19:36 schrieb Nick Rudnick: Hi Hans, agreed, but, in my eyes, you directly point to the problem: * doesn't this just delegate the problem to the topic of limit operations, i.e., in how far is the term «closed» here more perspicuous? It's fairly natural in German, abgeschlossen: closed, finished, complete; offen: open, ongoing. * that's (for a very simple concept) That concept (open and closed sets, topology more generally) is *not* very simple. It has many surprising aspects. the way that maths prescribes: + historical background: «I take closed as coming from being closed under limit operations - the origin from analysis.» + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). Actually, that's incomplete, missing are - c(x) contains x - c(x) is minimal among the sets containing x with y = c(y). If one takes c(X) = the set of limit points of Not limit points, Berührpunkte (touching points). X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed.» 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? The most fundamentalist justification I heard in this regard is: «It keeps people off from thinking the could go without the definition...» Meanwhile, we backtrack definition trees filling books, no, even more... In my eyes, this comes equal to claiming: «You have nothing to understand this beyond the provided authoritative definitions -- your understanding is done by strictly following these.» But you can't understand it except by familiarising yourself with the definitions and investigating their consequences. The name of a concept can only help you remembering what the definition was. Choosing obvious names tends to be misleading, because there usually are things satisfying the definition which do not behave like the obvious name implies. Back to the case of open/closed, given we have an idea about sets -- we in most cases are able to derive the concept of two disjunct sets facing each other ourselves, don't we? The only lore missing is just a Bool: Which term fits which idea? With a reliable terminology using «bordered/unbordered», there is no ambiguity, and we can pass on reading, without any additional effort. And we'd be very wrong. There are sets which are simultaneously open and closed. It is bad enough with the terminology as is, throwing in the boundary (which is an even more difficult concept than open/closed) would only make things worse. Picking such an opportunity thus may save a lot of time and even error -- allowing you to utilize your individual knowledge and experience. I When learning a formal theory, individual knowledge and experience (except coming from similar enough disciplines) tend to be misleading more than helpful. have hope that this approach would be of great help in learning category theory. All the best, Nick Hans Aberg wrote: On 18 Feb 2010, at 14:48, Nick Rudnick wrote: * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), I take closed as coming from being closed under limit operations - the origin from analysis. A closure operation c is defined by the property c(c(x)) = c(x). If one takes c(X) = the set of limit points of X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Am Donnerstag 18 Februar 2010 19:55:31 schrieb Nick Rudnick: Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de mailto:joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... Doesn't work. You need a lot of training in abstraction to learn very abstract concepts. Joe Sixpack's common sense isn't prepared for that. But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? The boundary of an open set is the boundary of its complement. The boundary may be empty (happens if and only if the set is simultaneously open and closed, clopen, as some say). As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Doesn't work for me. Not in Ens (sets, maps), Grp (groups, homomorphisms), Top (topological spaces, continuous mappings), Diff (differential manifolds, smooth mappings), ... . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Heterogeneous Data Structures - Nested Pairs and functional references
sry for being a bit thick, but how would this code be used? I'm unable to figure out the application yet. Could you give some examples how you use it? Günther So, the type (View view) -- ignoring class instances -- is basically isomorphic to this (slightly simpler) type: data View = EmptyView | TextView String | ConcatView View View | NestViews View View View | ... instance Monoid View where ... Now, consider the problem of generic programming on the simpler type: you quantify over the data constructors generically, and in doing so you gain traversals for the type.[1] You gain the same things by turning View into (View view) -- a functor, a foldable functor, and so on. When it comes time to render a format for a View (for example, a bit of Html from Text.XHtml.Strict), I use some higher order functions I'm already familiar with. Something like renderXHtml :: (View view) - Html renderXHtml (ConcatViews l r) = fold $ renderXHtml (ConcatViews l r) renderXHtml (NestViews l m r) = fold $ renderXHtml (NestViews l m r) renderXHtml (TextView string) = stringToHtml string renderXHtml (PageView v_title, v_heading, v_header, v_footer, v_contents) = (the_title (renderXHtml v_title)) +++ -- (We assume v_title is a TextView String) (body ( renderXHtml v_header ) +++ (render_page_contents v_contents v_heading) +++ (renderXHtml v_footer) ) where render_page_contents contents heading = undefined -- takes a View and uses the page's heading View -- so I guess we assume v_heading is a function -- into a TextView ... You could potentially use (=) for this, directly. And if you were using the simpler type, you could do the same thing with Uniplate, for example. It's going to construct an automorphism for you. [1] Actually, it's the other way around. But the container/ contained adjunction makes them equivalent.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Category Theory woes
Hi Mike, so an open set does not contain elements constituting a border/boundary of it, does it? But a closed set does, doesn't it? Cheers, Nick Michael Matsko wrote: - Forwarded Message - From: Michael Matsko msmat...@comcast.net To: Nick Rudnick joerg.rudn...@t-online.de Sent: Thursday, February 18, 2010 2:16:18 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg, Topologically speaking, the border of an open set is called the boundary of the set. The boundary is defined as the closure of the set minus the set itself. As an example consider the open interval (0,1) on the real line. The closure of the set is [0,1], the closed interval on 0, 1. The boundary would be the points 0 and 1. Mike Matsko - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Gregg Reynolds d...@mobileink.com Cc: Haskell Café List haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 1:55:31 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de mailto:joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) Are you sure...?? See http://en.wikipedia.org/wiki/Categories_(Aristotle) ... If memory serves, MacLane says somewhere that he and Eilenberg picked the term category as an explicit play on the same term in philosophy. In general I find mathematical terminology well-chosen and revealing, if one takes the trouble to do a little digging. If you want to know what terminological chaos really looks like try linguistics. ;-) For linguistics, granted... In regard of «a little digging», don't you think terminology work takes a great share, especially at interdisciplinary efforts? Wouldn't it be great to be able to drop, say 20% or even more, of such efforts and be able to progress more fluidly ? -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Feb 18, 2010, at 10:19 AM, Nick Rudnick wrote: Back to the case of open/closed, given we have an idea about sets -- we in most cases are able to derive the concept of two disjunct sets facing each other ourselves, don't we? The only lore missing is just a Bool: Which term fits which idea? With a reliable terminology using «bordered/unbordered», there is no ambiguity, and we can pass on reading, without any additional effort. There are sets that only partially contain their boundary. They are neither open nor closed, in the usual topology. Consider (0,1] in the Real number line. It contains 1, a boundary point. It does not contain 0. It is not an open set OR a closed set in the usual topology for R.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On 18 Feb 2010, at 20:20, Daniel Fischer wrote: + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). Actually, that's incomplete, ... That's right, it is just the idempotency relation. ...missing are - c(x) contains x - c(x) is minimal among the sets containing x with y = c(y). It suffices*) with a lattice L with relation = (inclusion in the case of sets) satifying i. x = y implies c(x) = c(y) ii. x = c(x) for all x in L. iii. c(c(x)) = x. Hans *) The definition in a book on lattice theory by Balbes Dwinger. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On 18 Feb 2010, at 19:19, Nick Rudnick wrote: agreed, but, in my eyes, you directly point to the problem: * doesn't this just delegate the problem to the topic of limit operations, i.e., in how far is the term «closed» here more perspicuous? * that's (for a very simple concept) the way that maths prescribes: + historical background: «I take closed as coming from being closed under limit operations - the origin from analysis.» + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). If one takes c(X) = the set of limit points of X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed.» 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? Yes, it is efficient conceptually. The idea of closed sets let to topology, and in combination with abstractions of differential geometry led to cohomology theory which needed category theory solving problems in number theory, used in a computer language called Haskell using a feature called Currying, named after a logician and mathematician, though only one person. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re[2]: Threading and FFI
Yves Parès wrote: But there are two things that remain obscure: First, there is my situation: int the main thread, I call to some C functions binded through FFI. All of them are marked 'unsafe', except one, which is internally supposed to make pauses with 'usleep'. I then execute in another haskell thread (with forkIO) some pure haskell actions. I then compile with the threaded RTS, and let at run the default behaviour which is to use one core. Question 1) What happens to the unsafe C functions? I that simply that the threaded RTS is unable to prevent them from blocking haskell threads (which in my case is a problem only for the function which pauses, since other C calls are fast)? Yes. unsafe FFI calls are executed just as a Haskell function. Thta means the underlying OS thread that happens to run the Haskell thread which contains the unsafe FFI call will block and thus all other activity that is scheduled to be run by this OS thread. Note: With unbound threads (those created by forkIO) it might happen at any time that the RTS choses to reschedule your Haskell thread onto another OS thread. Or they could provoke a hazardous issue, so I have to mark all the C functions as safe (which will be much slower) because ? You can leave them unsafe if you are sure that 1) they do not call (back) any function in your program 2) they do not block (or not long enough that it bothers you) Otherwise they are no less safe that the safe calls. If (1) is not fulfilled bad things might (that is, probably will) happen. Thus, if you are not sure, chose safe. Question 2) In the Control.Concurrent documentation, I understood that forkIO creates unbound threads whereas forkOS creates bound threads, but what is not very clear is: when does GHC threaded runtime launches as bound instead of unbound if this one has been started with forkIO? Never. Bound thread are ONLY needed if you (that is, some foreign functions you use) rely on thread-local storage. When it detects the thread calls to a C function? When it detects it calls to a safe C function (*)? When it detects another thread calls to a (safe) C function (which is my case)? In no case will forkIO create a bounded thread. Period. Bound threads are created with forkOS. If runtime is threaded and FFI call is marked safe and Haskell thread is unbound, then calls to such a function will be executed from SOME extra OS thread that is managed completely behind the scenes. (*) according to documentation it would be this case. However as I said my C calls are done in the MAIN thread. This doesn't make a difference. Main thread in Haskell is treated as any other thread (except with regard to program termination; imagine it has an invisible exit() call at the end). The other thread just executes casual haskell operations, however it is not blocked, which makes me think that even if I launch it with forkIO, it is launched as an bound thread. No. Bound thread means something different. It means that Haskell (green) thread is BOUND (fixed) to an OS thread. This is very bad for performance and only serves one purpose: to enable interoperation with broken C libraries (i.e. those which use thread local storage, a bad, bad, bad thing IMVHO). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Am Donnerstag 18 Februar 2010 21:47:02 schrieb Hans Aberg: On 18 Feb 2010, at 20:20, Daniel Fischer wrote: + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). Actually, that's incomplete, ... That's right, it is just the idempotency relation. ...missing are - c(x) contains x - c(x) is minimal among the sets containing x with y = c(y). It suffices*) with a lattice L with relation = (inclusion in the case of sets) satifying i. x = y implies c(x) = c(y) ii. x = c(x) for all x in L. iii. c(c(x)) = x. Typo, iii. c(c(x)) = c(x), of course. If we replace set by lattice element and contains by =, the definitions are equivalent. The one you quoted is better, though. Hans *) The definition in a book on lattice theory by Balbes Dwinger. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree composition for higher arity
On Wed, Feb 17, 2010 at 10:23 PM, Sean Leather leat...@cs.uu.nl wrote: -- oo :: (c - d) - (a - b - c) - a - b - d oo :: (Category cat) = cat c d - (a - cat b c) - a - cat b d oo = (.) . (.) I think at NL-FP day 2008 at Utrecht somebody called '(.) . (.)' the 'boob' operator... it was late and we had a few beers... oh wel, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] darcs 2.4 release candidate 2
Hi all, The darcs team would like to announce the immediate availability of darcs 2.4 release candidate 2. darcs 2.4 will contain many improvements and bugfixes compared to darcs 2.3.1. Highlights are the faster operation of record, revert and related commands, and the experimental interactive hunk editing. This beta is your chance to test-drive these improvements and make darcs even better. Compared to darcs 2.4 beta 3, the performance of darcs check and darcs repair has been brought up to the level of darcs 2.3.1.` The easiest way to install darcs is using the Haskell Platform [1]. If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install --reinstall darcs-beta Alternatively, you can download the tarball from http://darcs.net/releases/darcs-beta-2.3.99.2.tar.gz , and build it by hand as explained in the README file. Interactive hunk editing To try out interactive hunk editing, press 'e' when you are prompted with a hunk patch by 'darcs record'. You will then be shown an editor screen in which you can edit the state you want to record between the last two ruler lines. You can find more information about the hunk editing feature on http://wiki.darcs.net/HunkEditor . Reporting bugs -- If you have an issue with darcs 2.4 release candidate 2, you can report it via the web on http://bugs.darcs.net/ . You can also report bugs by email to b...@darcs.net. What's New -- A list of important changes since 2.3.1 is as follows (please let me know if there's something you miss!): * Use fast index-based diffing everywhere (Petr) * Interactive patch splitting (Ganesh) * An 'optimize --upgrade' option to convert to hashed format in-place (Eric) * Hunk matching (Kamil Dworakowski, tat.wright) * Progress reporting is no longer deceptive (Roman) * A 'remove --recursive' option to remove a directory tree from revision control (Roman) * 'show files' accepts arguments to show a subset of tracked files (Luca) * A '--remote-darcs' flag for pushing to a host where darcs isn't called darcs * Many miscellaneous Windows improvements (Salvatore, Petr and others) * 'darcs send' now mentions the repository name in the email body (Joachim) * Handle files with boring names in the repository correctly (Petr) * Fix parsing of .authorspellings file (Tomáš) * Various sane new command-line option names (Florent) * Remove the '--checkpoint' option (Petr) * Use external libraries for all UTF-8 handling (Eric, Reinier) * Use the Haskell zlib package exclusively for compression (Petr) A list of issues resolved since 2.3.1: * 183: do not sort changes --summary output * 223: add --remote-darcs flag to specify name of remote darcs executable * 291: provide (basic) interactive patch splitting * 540: darcs remove --recursive * 835: 'show files' with arguments * 1122: get --complete should not offer to create a lazy repository * 1216: list Match section in ToC * 1224: refuse to convert a repo that's already in darcs-2 format * 1300: logfile deleted on unsucessful record * 1308: push should warn about unpulled patches before patch-selection * 1336: sane error message on --last (empty string to numbers parser) * 1362: mention repo name in mail send body * 1377: getProgname for local darcs instances * 1392: use parsec to parse .authorspelling * 1424: darcs get wrongly reports using lazy repository if you ctrl-c old-fashioned get * 1447: different online help for send/apply --cc * 1488: fix crash in whatsnew when invoked in non-tracked directory * 1548: show contents requires at least one argument * 1554: allow opt-out of -threaded (fix ARM builds) * 1563: official thank-you page * 1578: don't put newlines in the Haskeline prompts * 1583: on darcs get, suggest upgrading source repo to hashed * 1584: provide optimize --upgrade command * 1588: add --skip-conflicts option * 1594: define PREPROCHTML in makefile * 1620: make amend leave a log file when it should * 1636: hunk matching * 1643: optimize --upgrade should do optimize * 1652: suggest cabal update before cabal install * 1659: make restrictBoring take recorded state into account * 1677: create correct hashes for empty directories in index * 1681: preserve log on amend failure * 1709: fix short version of progress reporting * 1712: correctly report number of patches to pull * 1720: fix cabal haddock problem * 1731: fix performance regression in check and repair * 1741: fix --list-options when option has multiple names Kind Regards, the darcs release manager, Reinier Lamers [1]: You can download the Haskell platform from http://hackage.haskell.org/platform/ signature.asc Description: This is a digitally signed message part.
Re: [Haskell-cafe] Category Theory woes
On Thu, Feb 18, 2010 at 1:31 PM, Daniel Fischer daniel.is.fisc...@web.dewrote: Am Donnerstag 18 Februar 2010 19:55:31 schrieb Nick Rudnick: Gregg Reynolds wrote: -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... Doesn't work. You need a lot of training in abstraction to learn very abstract concepts. Joe Sixpack's common sense isn't prepared for that. True enough, but I also tend to think that with a little imagination even many of the most abstract concepts can be illustrated with intuitive, concrete examples, and it's a fun (to me) challenge to try come up with them. For example, associativity can be nicely illustrated in terms of donning socks and shoes - it's not hard to imagine putting socks into shoes before putting feet into socks. A little weird, but easily understandable. My guess is that with a little effort one could find good concrete examples of at least category, functor, and natural transformation. Hmm, how is a cake-mixer like a cement-mixer? They're structurally and functionally isomorphic. Objects in the category Mixer? Both have a border, just in different places. Which elements form the border of an open set?? The boundary of an open set is the boundary of its complement. The boundary may be empty (happens if and only if the set is simultaneously open and closed, clopen, as some say). Right, that was what I meant; the point being that boundary (or border, or periphery or whatever) is not sufficient to capture the idea of closed v. open. -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Nick, That is correct. An open set contains no point on its boundary. A closed set contains its boundary, i.e. for a closed set c, Closure(c) = c. Note that for a general set, which is neither closed or open (say the half closed interval (0,1]), may contain points on its boundary. Every set contains its interior, which is the part of the set without its boundary and is contained in its closure - for a given set x, Interior(x) is a subset of x is a subset of Closure(x). Mike - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Michael Matsko msmat...@comcast.net Cc: haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 3:15:49 PM GMT -05:00 US/Canada Eastern Subject: Re: Fwd: [Haskell-cafe] Category Theory woes Hi Mike, so an open set does not contain elements constituting a border/boundary of it, does it? But a closed set does, doesn't it? Cheers, Nick Michael Matsko wrote: - Forwarded Message - From: Michael Matsko msmat...@comcast.net To: Nick Rudnick joerg.rudn...@t-online.de Sent: Thursday, February 18, 2010 2:16:18 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg, Topologically speaking, the border of an open set is called the boundary of the set. The boundary is defined as the closure of the set minus the set itself. As an example consider the open interval (0,1) on the real line. The closure of the set is [0,1], the closed interval on 0, 1. The boundary would be the points 0 and 1. Mike Matsko - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Gregg Reynolds d...@mobileink.com Cc: Haskell Café List haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 1:55:31 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) Are you sure...?? See http://en.wikipedia.org/wiki/Categories_(Aristotle) ... If memory serves, MacLane says somewhere that he and Eilenberg picked the term category as an explicit play on the same term in philosophy. In general I find mathematical terminology well-chosen and revealing, if one takes the trouble to do a little digging. If you want to know what terminological chaos really looks like try linguistics. ;-) For linguistics, granted... In regard of «a little digging», don't you think terminology work takes a great share, especially at interdisciplinary efforts? Wouldn't it be great to be able to drop, say 20% or even more, of such efforts and be able to progress more fluidly ? -g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On 18 Feb 2010, at 22:06, Daniel Fischer wrote: ...missing are - c(x) contains x - c(x) is minimal among the sets containing x with y = c(y). It suffices*) with a lattice L with relation = (inclusion in the case of sets) satifying i. x = y implies c(x) = c(y) ii. x = c(x) for all x in L. iii. c(c(x)) = x. Typo, iii. c(c(x)) = c(x), of course. Sure. If we replace set by lattice element and contains by =, the definitions are equivalent. Right. The one you quoted is better, though. It is a powerful concept. I think of a function closure as what one gets when adding all an expression binds to, though I'm not sure that is why it is called a closure. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hi Mike, of course... But in the same spirit, one could introduce a straightforward extension, «partially bordered», which would be as least as good as «clopen»... ;-) I must admit we've come a little off the topic -- how to introduce to category theory. The intent was to present some examples that mathematical terminology culture is not that exemplary as one should expect, but to motivate an open discussion about how one might «rename refactor» category theory (of 2:48 PM). I would be very interested in other people's proposals... :-) Michael Matsko wrote: Nick, That is correct. An open set contains no point on its boundary. A closed set contains its boundary, i.e. for a closed set c, Closure(c) = c. Note that for a general set, which is neither closed or open (say the half closed interval (0,1]), may contain points on its boundary. Every set contains its interior, which is the part of the set without its boundary and is contained in its closure - for a given set x, Interior(x) is a subset of x is a subset of Closure(x). Mike - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Michael Matsko msmat...@comcast.net Cc: haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 3:15:49 PM GMT -05:00 US/Canada Eastern Subject: Re: Fwd: [Haskell-cafe] Category Theory woes Hi Mike, so an open set does not contain elements constituting a border/boundary of it, does it? But a closed set does, doesn't it? Cheers, Nick Michael Matsko wrote: - Forwarded Message - From: Michael Matsko msmat...@comcast.net To: Nick Rudnick joerg.rudn...@t-online.de Sent: Thursday, February 18, 2010 2:16:18 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg, Topologically speaking, the border of an open set is called the boundary of the set. The boundary is defined as the closure of the set minus the set itself. As an example consider the open interval (0,1) on the real line. The closure of the set is [0,1], the closed interval on 0, 1. The boundary would be the points 0 and 1. Mike Matsko - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Gregg Reynolds d...@mobileink.com Cc: Haskell Café List haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 1:55:31 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de mailto:joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) Are you sure...?? See http://en.wikipedia.org/wiki/Categories_(Aristotle) ... If memory serves, MacLane says somewhere that he and Eilenberg picked the term category as an explicit play on the same term in philosophy. In general I find mathematical
Re: [Haskell-cafe] Category Theory woes
On Feb 18, 2010, at 1:28 PM, Hans Aberg wrote: It is a powerful concept. I think of a function closure as what one gets when adding all an expression binds to, though I'm not sure that is why it is called a closure. Its because a monadic morphism into the same type carrying around data is a closure operator on the type. It's basically a direct sum of the inner type, and the data type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hans Aberg wrote: On 18 Feb 2010, at 19:19, Nick Rudnick wrote: agreed, but, in my eyes, you directly point to the problem: * doesn't this just delegate the problem to the topic of limit operations, i.e., in how far is the term «closed» here more perspicuous? * that's (for a very simple concept) the way that maths prescribes: + historical background: «I take closed as coming from being closed under limit operations - the origin from analysis.» + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). If one takes c(X) = the set of limit points of X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed.» 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? Yes, it is efficient conceptually. The idea of closed sets let to topology, and in combination with abstractions of differential geometry led to cohomology theory which needed category theory solving problems in number theory, used in a computer language called Haskell using a feature called Currying, named after a logician and mathematician, though only one person. It is SUCCESSFUL, NO MATTER... :-) But I spoke about efficiency, in the Pareto sense (http://en.wikipedia.org/wiki/Pareto_efficiency)... Can we say that the way in which things are done now cannot be improved?? Hans, you were the most specific response to my actual intention -- could I clear up the reference thing for you? All the best, Nick Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hi Alexander, my actual posting was about rename refactoring category theory; closed/open was just presented as an example for suboptimal terminology in maths. But of course, bordered/unbordered would be extended by e.g. «partially bordered» and the same holds. Cheers, Nick Alexander Solla wrote: On Feb 18, 2010, at 10:19 AM, Nick Rudnick wrote: Back to the case of open/closed, given we have an idea about sets -- we in most cases are able to derive the concept of two disjunct sets facing each other ourselves, don't we? The only lore missing is just a Bool: Which term fits which idea? With a reliable terminology using «bordered/unbordered», there is no ambiguity, and we can pass on reading, without any additional effort. There are sets that only partially contain their boundary. They are neither open nor closed, in the usual topology. Consider (0,1] in the Real number line. It contains 1, a boundary point. It does not contain 0. It is not an open set OR a closed set in the usual topology for R. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On 18 Feb 2010, at 23:02, Nick Rudnick wrote: 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? Yes, it is efficient conceptually. The idea of closed sets let to topology, and in combination with abstractions of differential geometry led to cohomology theory which needed category theory solving problems in number theory, used in a computer language called Haskell using a feature called Currying, named after a logician and mathematician, though only one person. It is SUCCESSFUL, NO MATTER... :-) But I spoke about efficiency, in the Pareto sense (http://en.wikipedia.org/wiki/Pareto_efficiency )... Can we say that the way in which things are done now cannot be improved?? Hans, you were the most specific response to my actual intention -- could I clear up the reference thing for you? That seems to be an economic theory version of utilitarianism - the problem is that when dealing with concepts there may be no optimizing function to agree upon. There is an Occam's razor one may try to apply in the case of axiomatic systems, but one then finds it may be more practical with one that is not minimal. As for the naming problem, it is more of a linguistic problem: the names were somehow handed by tradition, and it may be difficult to change them. For example, there is a rumor that kangaroo means I do not understand in a native language; assuming this to be true, it might be difficult to change it. Mathematicians though stick to their own concepts and definitions individually. For example, I had conversations with one who calls monads triads, and then one has to cope with that. Hans ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 1:31 PM, Daniel Fischer daniel.is.fisc...@web.de mailto:daniel.is.fisc...@web.de wrote: Am Donnerstag 18 Februar 2010 19:55:31 schrieb Nick Rudnick: Gregg Reynolds wrote: -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... Doesn't work. You need a lot of training in abstraction to learn very abstract concepts. Joe Sixpack's common sense isn't prepared for that. True enough, but I also tend to think that with a little imagination even many of the most abstract concepts can be illustrated with intuitive, concrete examples, and it's a fun (to me) challenge to try come up with them. For example, associativity can be nicely illustrated in terms of donning socks and shoes - it's not hard to imagine putting socks into shoes before putting feet into socks. A little weird, but easily understandable. My guess is that with a little effort one could find good concrete examples of at least category, functor, and natural transformation. Hmm, how is a cake-mixer like a cement-mixer? They're structurally and functionally isomorphic. Objects in the category Mixer? :-) This comes close to what I mean -- the beauty of category theory does not end at the borders of mathematical subjects... IMHO we are just beginning to discovery of the categorical world beyond mathematics, and I think many findings original to computer science, but less to maths may be of value then. And I am definitely more optimistic on «Joe Sixpack's common sense», which still surpasses a good lot of things possible with AI -- no categories at all there?? I can't believe... Both have a border, just in different places. Which elements form the border of an open set?? The boundary of an open set is the boundary of its complement. The boundary may be empty (happens if and only if the set is simultaneously open and closed, clopen, as some say). Right, that was what I meant; the point being that boundary (or border, or periphery or whatever) is not sufficient to capture the idea of closed v. open. ;-)) I did not claim «bordered» is the best choice, I just said closed/open is NOT... IMHO this also does not affect what I understand as a refactoring -- just imagine Coq had a refactoring browser; all combinations of terms are possible as before, aren't they? But it was not my aim to begin enumerating all variations of «bordered», «unbordered», «partially ordered» and STOP... Should I come QUICKLY with a pendant to «clopen» now? This would be «MATHS STYLE»...! I neither say finding an appropriate word here is a quickshot, nor I claim trying so is ridiculous, as it is impossible. I think it is WORK, which is to be done in OPEN DISCUSSION -- and that, at the long end, the result might be rewarding, similar as the effort put into a rename refactoring will reveal rewarding. ;-)) Trying a refactored category theory (with a dictionary in the appendix...) might open access to many interesting people and subjects otherwise out of reach. And deeply contemplating terminology cannot hurt, at the least... All the best, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Feb 18, 2010, at 2:08 PM, Nick Rudnick wrote: my actual posting was about rename refactoring category theory; closed/open was just presented as an example for suboptimal terminology in maths. But of course, bordered/unbordered would be extended by e.g. «partially bordered» and the same holds. And my point was that your terminology was suboptimal for just the same reasons. The difficulty of mathematics is hardly the funny names. Perhaps you're not familiar with the development of Category theory. Hans Aberg gave a brief development. Basically, Category theory is the RESULT of the refactoring you're asking about. Category theory's beginnings are found in work on differential topology (where functors and higher order constructs took on a life of their own), and the unification of topology, lattice theory, and universal algebra (in order to ground that higher order stuff). Distinct models and notions of computation were unified, using arrows and objects. Now, you could have a legitimate gripe about current category theory terminology. But I am not so sure. We can simplify lots of things. Morphisms can become arrows or functions. Auto- can become self-. Homo- can become same-. Functors can become Category arrows. Does it help? You tell me. But if we're ever going to do anything interesting with Category theory, we're going to have to go into the realm of dealing with SOME kind of algebra. We need examples, and the mathematically tractable ones have names like group, monoid, ring, field, sigma- algebras, lattices, logics, topologies, geometries. They are arbitrary names, grounded in history. Any other choice is just as arbitrary, if not more so. The closest thing algebras have to a unique name is their signature -- basically their axiomatization -- or a long descriptive name in terms of arbitrary names and adjectives (the Cartesian product of a Cartesian closed category and a groupoid with groupoid addition induced by). The case for Pareto efficiency is here: is changing the name of these kinds of structures wholesale a win for efficiency? The answer is no. Everybody would have to learn the new, arbitrary names, instead of just some people having to learn the old arbitrary names. Let's compare this to the monad fallacy. It is said every beginner Haskell programmer write a monad tutorial, and often falls into the monad fallacy of thinking that there is only one interpretation for monadism. Monads are relatively straightforward. Their power comes from the fact that many different kinds of things are monadic -- sequencing, state, function application. What name should we use for monads instead? Which interpretation must we favor, despite the fact that others will find it counter-intuitive? Or should we choose to not favor one, and just pick a new arbitrary name?___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] [2]: Threading and FFI
Ben Franksen wrote: You can leave them unsafe if you are sure that 1) they do not call (back) any function in your program 2) they do not block (or not long enough that it bothers you) Otherwise they are no less safe that the safe calls. If (1) is not fulfilled bad things might (that is, probably will) happen. Thus, if you are not sure, chose safe. Okay. Since I know which functions call back to haskell code and which make pauses, I know what need to be safe and what can be let safely unsafe (^^). Bound thread are ONLY needed if you (that is, some foreign functions you use) rely on thread-local storage. Yes, but since the main thread (if I understood well) is bound, if I call to C functions which rely on thread-local storage (like OpenGL functions, according to GHC Control.Concurrent doc) in this thread I should have no problem, shouldn't I? And if I choose to call these functions from outside the main thread it'll have to be from a thread launched with forkOS? (The C functions I call in my real code actually use OpenGL internally) If runtime is threaded and FFI call is marked safe and Haskell thread is unbound, then calls to such a function will be executed from SOME extra OS thread that is managed completely behind the scenes. Okay, that's what I didn't understand! Only the call to my safe function will be done in an external bound thread, not the whole thread in which the call is done. So, to sum up, my program will run this way (not necessarily in this order): My main is launched in a bound thread. My casual haskell I/O operations (read and print from and to the terminal) are launched in an unbound thread. Whenever my main thread reaches the call to my safe C function which 'sleeps', it launches it in another bound thread. Am I right or is it no that easy to foresee the behaviour of my program? - Yves Parès Live long and prosper -- View this message in context: http://old.nabble.com/Threading-and-FFI-tp27611528p27647126.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Nick, Actually, clopen is a set that is both closed and open. Not one that is neither. Except in the case of half-open intervals, I can't remember talking much in topology about sets with a partial boundary. Category theory-wise. No one seems to have mentioned MacLane's Categories for the Working Mathematician. Although, I don't seem to recall instant enlightenment when I picked it up. Mike - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Michael Matsko msmat...@comcast.net Cc: haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 4:54:03 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Hi Mike, of course... But in the same spirit, one could introduce a straightforward extension, «partially bordered», which would be as least as good as «clopen»... ;-) I must admit we've come a little off the topic -- how to introduce to category theory. The intent was to present some examples that mathematical terminology culture is not that exemplary as one should expect, but to motivate an open discussion about how one might «rename refactor» category theory (of 2:48 PM). I would be very interested in other people's proposals... :-) Michael Matsko wrote: Nick, That is correct. An open set contains no point on its boundary. A closed set contains its boundary, i.e. for a closed set c, Closure(c) = c. Note that for a general set, which is neither closed or open (say the half closed interval (0,1]), may contain points on its boundary. Every set contains its interior, which is the part of the set without its boundary and is contained in its closure - for a given set x, Interior(x) is a subset of x is a subset of Closure(x). Mike - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Michael Matsko msmat...@comcast.net Cc: haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 3:15:49 PM GMT -05:00 US/Canada Eastern Subject: Re: Fwd: [Haskell-cafe] Category Theory woes Hi Mike, so an open set does not contain elements constituting a border/boundary of it, does it? But a closed set does, doesn't it? Cheers, Nick Michael Matsko wrote: - Forwarded Message - From: Michael Matsko msmat...@comcast.net To: Nick Rudnick joerg.rudn...@t-online.de Sent: Thursday, February 18, 2010 2:16:18 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg, Topologically speaking, the border of an open set is called the boundary of the set. The boundary is defined as the closure of the set minus the set itself. As an example consider the open interval (0,1) on the real line. The closure of the set is [0,1], the closed interval on 0, 1. The boundary would be the points 0 and 1. Mike Matsko - Original Message - From: Nick Rudnick joerg.rudn...@t-online.de To: Gregg Reynolds d...@mobileink.com Cc: Haskell Café List haskell-cafe@haskell.org Sent: Thursday, February 18, 2010 1:55:31 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Category Theory woes Gregg Reynolds wrote: On Thu, Feb 18, 2010 at 7:48 AM, Nick Rudnick joerg.rudn...@t-online.de wrote: IM(H??)O, a really introductive book on category theory still is to be written -- if category theory is really that fundamental (what I believe, due to its lifting of restrictions usually implicit at 'orthodox maths'), than it should find a reflection in our every day's common sense, shouldn't it? Goldblatt works for me. Accidentially, I have Goldblatt here, although I didn't read it before -- you agree with me it's far away from every day's common sense, even for a hobby coder?? I mean, this is not «Head first categories», is it? ;-)) With «every day's common sense» I did not mean «a mathematician's every day's common sense», but that of, e.g., a housewife or a child... But I have became curious now for Goldblatt... * the definition of open/closed sets in topology with the boundary elements of a closed set to considerable extent regardable as facing to an «outside» (so that reversing these terms could even appear more intuitive, or «bordered» instead of closed and «unbordered» instead of open), Both have a border, just in different places. Which elements form the border of an open set?? As an example, let's play a little: Arrows: Arrows are more fundamental than objects, in fact, categories may be defined with arrows only. Although I like the term arrow (more than 'morphism'), I intuitively would find the term «reference» less contradictive with the actual intention, as this term Arrows don't refer. A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Categories: In every day's language, a category is a completely different thing, without the least Not necesssarily (for Kantians, Aristoteleans?) Are you sure...?? See
Re: [Haskell-cafe] Category Theory woes
Hans Aberg wrote: On 18 Feb 2010, at 23:02, Nick Rudnick wrote: 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? Yes, it is efficient conceptually. The idea of closed sets let to topology, and in combination with abstractions of differential geometry led to cohomology theory which needed category theory solving problems in number theory, used in a computer language called Haskell using a feature called Currying, named after a logician and mathematician, though only one person. It is SUCCESSFUL, NO MATTER... :-) But I spoke about efficiency, in the Pareto sense (http://en.wikipedia.org/wiki/Pareto_efficiency)... Can we say that the way in which things are done now cannot be improved?? Hans, you were the most specific response to my actual intention -- could I clear up the reference thing for you? That seems to be an economic theory version of utilitarianism - the problem is that when dealing with concepts there may be no optimizing function to agree upon. There is an Occam's razor one may try to apply in the case of axiomatic systems, but one then finds it may be more practical with one that is not minimal. Exactly. By this I justify my questioning of inviolability of the state of art of maths terminology -- an open discussion should be allowed at any time... As for the naming problem, it is more of a linguistic problem: the names were somehow handed by tradition, and it may be difficult to change them. For example, there is a rumor that kangaroo means I do not understand in a native language; assuming this to be true, it might be difficult to change it. Completely d'accord. This is indeed a strong problem, and I fully agree if you say that, for maths, trying this is for people with fondness for speaker's corner... :-)) But for category theory, a subject (too!) many people are complaining about, blind for its beauty, a such book -- ideally in children's language and illustrations, of course with a dictionary to original terminology in the appendix! -- could be of great positive influence on category theory itself. And the deep contemplation encompassing the *collective* creation should be most rewarding in itself -- a journey without haste into the depths of the subject. Mathematicians though stick to their own concepts and definitions individually. For example, I had conversations with one who calls monads triads, and then one has to cope with that. Yes. But isn't it also an enrichment by some way? All the best, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Feb 19, 2010, at 3:55 AM, Daniel Fischer wrote: Am Donnerstag 18 Februar 2010 14:48:08 schrieb Nick Rudnick: even in Germany, where the term «ring» seems to originate from, since at least a century nowbody has the least idea it once had an alternative meaning «gang,band,group», Wrong. The term Ring is still in use with that meaning in composites like Schmugglerring, Autoschieberring, ... The mathematical ring is OED ring n1 sense 12. The group of people sense is sense 11, immediately above it. Drug ring is still in use. I'd always assumed ring was generalised from Z[n]. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Alexander Solla wrote: On Feb 18, 2010, at 2:08 PM, Nick Rudnick wrote: my actual posting was about rename refactoring category theory; closed/open was just presented as an example for suboptimal terminology in maths. But of course, bordered/unbordered would be extended by e.g. «partially bordered» and the same holds. And my point was that your terminology was suboptimal for just the same reasons. The difficulty of mathematics is hardly the funny names. :-) Criticism... Criticism is good at this place... Opens up things... Perhaps you're not familiar with the development of Category theory. Hans Aberg gave a brief development. Basically, Category theory is the RESULT of the refactoring you're asking about. Category theory's beginnings are found in work on differential topology (where functors and higher order constructs took on a life of their own), and the unification of topology, lattice theory, and universal algebra (in order to ground that higher order stuff). Distinct models and notions of computation were unified, using arrows and objects. Now, you could have a legitimate gripe about current category theory terminology. But I am not so sure. We can simplify lots of things. Morphisms can become arrows or functions. Auto- can become self-. Homo- can become same-. Functors can become Category arrows. Does it help? You tell me. I think I understand what you mean and completely agree... The project in my imagination is different, I read on... But if we're ever going to do anything interesting with Category theory, we're going to have to go into the realm of dealing with SOME kind of algebra. We need examples, and the mathematically tractable ones have names like group, monoid, ring, field, sigma-algebras, lattices, logics, topologies, geometries. They are arbitrary names, grounded in history. Any other choice is just as arbitrary, if not more so. The closest thing algebras have to a unique name is their signature -- basically their axiomatization -- or a long descriptive name in terms of arbitrary names and adjectives (the Cartesian product of a Cartesian closed category and a groupoid with groupoid addition induced by). The case for Pareto efficiency is here: is changing the name of these kinds of structures wholesale a win for efficiency? The answer is no. Everybody would have to learn the new, arbitrary names, instead of just some people having to learn the old arbitrary names. Ok... Let's compare this to the monad fallacy. It is said every beginner Haskell programmer write a monad tutorial, and often falls into the monad fallacy of thinking that there is only one interpretation for monadism. Monads are relatively straightforward. Their power comes from the fact that many different kinds of things are monadic -- sequencing, state, function application. What name should we use for monads instead? Which interpretation must we favor, despite the fact that others will find it counter-intuitive? Or should we choose to not favor one, and just pick a new arbitrary name? The short answer: If the work I imagine would be done by exchanging here a word and there on the quick -- it would be again maths style, with difference only in justifying it with naivity instead of resignation. The idea I have is different: DEEP CONTEMPLATION stands in the beginning, gathering the constructive criticism of the sharpest minds possible, hard discussions and debates full of temperament -- all of this already rewarding in itself. The participants are united in the spirit to create a masterpiece, and to explore details in depths for which time was missing before. It could be great fun for everybody to improve one's deep intuition of category theory. This book might be comparable to a programming language, hypertext like a wikibook and maybe in development forever. It will have an appendix (or later a special mode) with a translation of all new termini into the original ones. I do believe deeply that this is possible. By all criticism on Bourbaki -- I was among the generation of pupils taught set theory in elementary school; looking back, I regard it as a rewarding effort. Why should category theory not be able to achieve the same, maybe with other means than plastic chips? All the best, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Feb 19, 2010, at 11:22 AM, Hans Aberg wrote: As for the naming problem, it is more of a linguistic problem: the names were somehow handed by tradition, and it may be difficult to change them. For example, there is a rumor that kangaroo means I do not understand in a native language; assuming this to be true, it might be difficult to change it. OED entry for kangaroo, n; etymology: [Stated to have been the name in a native Australian language. Cook and Banks believed it to be the name given to the animal by the natives at Endeavour River, Queensland, and there is later affirmation of its use elsewhere. On the other hand, there are express statements to the contrary (see quotations below), showing that the word, if ever current in this sense, was merely local, or had become obsolete. The common assertion that it really means ‘I don't understand’ (the supposed reply of the native to his questioner) seems to be of recent origin and lacks confirmation. ...] Turning to the Wikipedia article, we find The word kangaroo derives from the Guugu Yimidhirr word gangurru, referring to a grey kangaroo and A common myth about the kangaroo's English name is that 'kangaroo' was a Guugu Yimidhirr phrase for I don't understand you. According to this legend, Captain James Cook and naturalist Sir Joseph Banks were exploring the area when they happened upon the animal. They asked a nearby local what the creatures were called. The local responded Kangaroo, meaning I don't understand you, which Cook took to be the name of the creature. The Kangaroo myth was debunked in the 1970s by linguist John B. Haviland in his research with the Guugu Yimidhirr people. See the wikipedia page for references, especially Haviland's article. It's time this urban legend was forgotten. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Am Freitag 19 Februar 2010 00:24:23 schrieb Richard O'Keefe: On Feb 19, 2010, at 3:55 AM, Daniel Fischer wrote: Am Donnerstag 18 Februar 2010 14:48:08 schrieb Nick Rudnick: even in Germany, where the term «ring» seems to originate from, since at least a century nowbody has the least idea it once had an alternative meaning «gang,band,group», Wrong. The term Ring is still in use with that meaning in composites like Schmugglerring, Autoschieberring, ... The mathematical ring is OED ring n1 sense 12. The group of people sense is sense 11, immediately above it. Drug ring is still in use. I'd always assumed ring was generalised from Z[n]. As in cyclic group, arrange the numbers in a ring like on a clockface? Maybe. As far as I know, the term ring (in the mathematical sense) first appears in chapter 9 - Die Zahlringe des Körpers - of Hilbert's Die Theorie der algebraischen Zahlkörper. Unfortunately, Hilbert gives no hint why he chose that name (Dedekind, who coined the term Körper, called these structures Ordnung [order]). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Daniel Fischer wrote: Am Donnerstag 18 Februar 2010 19:19:36 schrieb Nick Rudnick: Hi Hans, agreed, but, in my eyes, you directly point to the problem: * doesn't this just delegate the problem to the topic of limit operations, i.e., in how far is the term «closed» here more perspicuous? It's fairly natural in German, abgeschlossen: closed, finished, complete; offen: open, ongoing. * that's (for a very simple concept) That concept (open and closed sets, topology more generally) is *not* very simple. It has many surprising aspects. «concept» is a word of many meanings; to become more specific: Its *definition* is... the way that maths prescribes: + historical background: «I take closed as coming from being closed under limit operations - the origin from analysis.» + definition backtracking: «A closure operation c is defined by the property c(c(x)) = c(x). Actually, that's incomplete, missing are - c(x) contains x - c(x) is minimal among the sets containing x with y = c(y). Even more workload to master... This strengthens the thesis that definition recognition requires a considerable amount of one's effort... If one takes c(X) = the set of limit points of Not limit points, Berührpunkte (touching points). X, then it is the smallest closed set under this operation. The closed sets X are those that satisfy c(X) = X. Naming the complements of the closed sets open might have been introduced as an opposite of closed.» 418 bytes in my file system... how many in my brain...? Is it efficient, inevitable? The most fundamentalist justification I heard in this regard is: «It keeps people off from thinking the could go without the definition...» Meanwhile, we backtrack definition trees filling books, no, even more... In my eyes, this comes equal to claiming: «You have nothing to understand this beyond the provided authoritative definitions -- your understanding is done by strictly following these.» But you can't understand it except by familiarising yourself with the definitions and investigating their consequences. The name of a concept can only help you remembering what the definition was. Choosing obvious names tends to be misleading, because there usually are things satisfying the definition which do not behave like the obvious name implies. So if you state that the used definitions are completely unpredictable so that they have to be studied completely -- which already ignores that human brain is an analogous «machine» --, you, by information theory, imply that these definitions are somewhat arbitrary, don't you? This in my eyes would contradict the concept such definition systems have about themselves. To my best knowledge it is one of the best known characteristics of category theory that it revealed in how many cases maths is a repetition of certain patterns. Speaking categorically it is good practice to transfer knowledge from on domain to another, once the required isomorphisms could be established. This way, category theory itself has successfully torn down borders between several subdisciplines of maths and beyond. I just propose to expand the same to common sense matters... Back to the case of open/closed, given we have an idea about sets -- we in most cases are able to derive the concept of two disjunct sets facing each other ourselves, don't we? The only lore missing is just a Bool: Which term fits which idea? With a reliable terminology using «bordered/unbordered», there is no ambiguity, and we can pass on reading, without any additional effort. And we'd be very wrong. There are sets which are simultaneously open and closed. It is bad enough with the terminology as is, throwing in the boundary (which is an even more difficult concept than open/closed) would only make things worse. Really? As «open == not closed» can similarly be implied, bordered/unbordered even in this concern remains at least equal... Picking such an opportunity thus may save a lot of time and even error -- allowing you to utilize your individual knowledge and experience. I When learning a formal theory, individual knowledge and experience (except coming from similar enough disciplines) tend to be misleading more than helpful. Why does the opposite work well for computing science? All the best, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
On Thu, Feb 18, 2010 at 2:32 AM, Evan Laforge qdun...@gmail.com wrote: By purest coincidence I just wrote the exact same function (the simple mergeAll', not the VIP one). Well, extensionally the same... intensionally mine is 32 complicated lines and equivalent to the 3 line mergeAll'. I even thought of short solution by thinking that pulling the first element destroys the ascending lists property so it's equivalent to a normal sorted merge after that, and have no idea why I didn't just write it that way. Well, the three line version wasn't my first implementation, by any stretch of the imagination. I know I had tried to implement mergeAll at least once, if not two or three times before coming up with the foldr-based implementation. However, I can't find any of them; they may well be lost to the sands of time. Incidentally, that implementation also appears in Melissa O'Neill's Genuine Sieve of Eratosthenes, in an alternate prime sieve by Richard Bird that appears at the end. Anyway, I'm dropping mine and downloading data-ordlist. Thanks for the library *and* the learning experience :) Thanks! BTW, I notice that your merges, like mine, are left-biased. This is a useful property (my callers require it), and doesn't seem to cost anything to implement, so maybe you could commit to it in the documentation? Yes, the description of the module explicitly states that all functions are left-biased; if you have suggestions about how to improve the documentation in content or organization, I am interested in hearing them. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Feb 18, 2010, at 4:49 PM, Nick Rudnick wrote: Why does the opposite work well for computing science? Does it? I remember a peer trying to convince me to use the factory pattern in a language that supports functors. I told him I would do my task my way, and he could change it later if he wanted. He told me an hour later he tried a trivial implementation, and found that the source was twice as long as my REAL implementation, split across multiple files in an unattractive way, all while losing conceptual clarity. He immediately switched to using functors too. He didn't even know he wanted a functor, because the name factory clouded his interpretation. Software development is full of people inventing creative new ways to use the wrong tool for the job. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hi Alexander, please be more specific -- what is your proposal? Seems as if you had more to say... Nick Alexander Solla wrote: On Feb 18, 2010, at 4:49 PM, Nick Rudnick wrote: Why does the opposite work well for computing science? Does it? I remember a peer trying to convince me to use the factory pattern in a language that supports functors. I told him I would do my task my way, and he could change it later if he wanted. He told me an hour later he tried a trivial implementation, and found that the source was twice as long as my REAL implementation, split across multiple files in an unattractive way, all while losing conceptual clarity. He immediately switched to using functors too. He didn't even know he wanted a functor, because the name factory clouded his interpretation. Software development is full of people inventing creative new ways to use the wrong tool for the job. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
On Thu, Feb 18, 2010 at 3:07 AM, Evan Laforge qdun...@gmail.com wrote: BTW, I notice that your merges, like mine, are left-biased. This is a useful property (my callers require it), and doesn't seem to cost anything to implement, so maybe you could commit to it in the documentation? Also, I did briefly consider giving up left bias. GHC has an optimization strategy that seeks to reduce pattern matching, and due to interactions with this I could have saved a few kilobytes of -O2 object code size by giving up left-bias. For example: module MergeLeft where mergeBy :: (a - a - Ordering) - [a] - [a] - [a] mergeBy cmp = loop where loop [] ys = ys loop xs [] = xs loop (x:xs) (y:ys) = case cmp x y of GT - y : loop (x:xs) ys _ - x : loop xs (y:ys) compiles ghc-6.12.1 -O2 to a 4208 byte object file for x64 ELF. By changing the very last line to: _ - x : loop (y:ys) xs I get a 3336 byte object file instead, but of course this is no longer left- (or right-) biased.Repeat this strategy across the entire module, and you can save 3 kilobytes or so. However, in today's modern computing environment, left-bias is clearly a greater benefit to more people. If you are curious why, I suggest taking a look at GHC's core output for each of these two variants. The hackage package ghc-core makes this a little bit more pleasant, as it can pretty-print it for you. It's amazing to think that this library, at 55k (Optimized -O2 for x64), would take up most of the memory of my very first computer, a Commodore 64. Of course, I'm sure there are many others on this list who's first computers had a small fraction of 64k of memory to play with. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
Hi, wow, a topic specific response, at last... But I wish you would be more specific... ;-) A *referrer* (object) refers to a *referee* (object) by a *reference* (arrow). Doesn't work for me. Not in Ens (sets, maps), Grp (groups, homomorphisms), Top (topological spaces, continuous mappings), Diff (differential manifolds, smooth mappings), ... . Why not begin with SET and functions... Every human has a certain age, so that there is a function, ageOf:: Human- Int, which can be regarded as a certain way of a reference relationship between Human and Int, in that by agoOf, * Int reflects a certain aspect of Human, and, on the other hand, * the structure of Human can be traced to Int. Please tell me the aspect you feel uneasy with, and please give me your opinion, whether (in case of accepting this) you would rather choose to consider Human as referrer and Int as referee of the opposite -- for I think this is a deep question. Thank you in advance, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing unionAll
On Thu, Feb 18, 2010 at 5:22 PM, Leon Smith leon.p.sm...@gmail.com wrote: On Thu, Feb 18, 2010 at 3:07 AM, Evan Laforge qdun...@gmail.com wrote: BTW, I notice that your merges, like mine, are left-biased. This is a useful property (my callers require it), and doesn't seem to cost anything to implement, so maybe you could commit to it in the documentation? Ohh, I see it now, I just wasn't looking at the module doc. Also, I did briefly consider giving up left bias. GHC has an optimization strategy that seeks to reduce pattern matching, and due to interactions with this I could have saved a few kilobytes of -O2 object code size by giving up left-bias. Interesting... but left bias is so useful I think it's worth a few extra k. If you are curious why, I suggest taking a look at GHC's core output for each of these two variants. The hackage package ghc-core makes this a little bit more pleasant, as it can pretty-print it for you. I can see there's one extra case in the first one, and I can tell the last case is the 'loop' case including the case on Ordering, but I admit I don't understand what the previous cases are doing. Core is really hard for me to read. It's amazing to think that this library, at 55k (Optimized -O2 for x64), would take up most of the memory of my very first computer, a Commodore 64. Of course, I'm sure there are many others on this list who's first computers had a small fraction of 64k of memory to play with. :-) It's not even that much assembly. I intended to write a small quick program... then I did it in haskell, and then I linked in the GHC API (fatal blow). Now the stripped optimized binary is 22MB (optimization doesn't seem to have an effect on size). The non-haskell UI part is 367k... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Category Theory woes
On Feb 19, 2010, at 2:48 PM, Nick Rudnick wrote: Please tell me the aspect you feel uneasy with, and please give me your opinion, whether (in case of accepting this) you would rather choose to consider Human as referrer and Int as referee of the opposite -- for I think this is a deep question. I've read enough philosophy to be wary of treating reference as a simple concept. And linguistically, referees are people you find telling rugby players naughty naughty. Don't you mean referrer and referent? Of course a basic point about language is that the association between sounds and meanings is (for the most part) arbitrary. Why should the terminology of mathematics be any different? Why is a small dark floating cloud, indicating rain, called a water-dog? Water, yes, but dog? Why are the brackets at each end of a fire-place called fire-dogs? Why are unusually attractive women called foxes (the females of that species being vixens, and both sexes smelly)? What's the logic in doggedness being a term of praise but bitchiness of opprobrium? We can hope for mathematical terms to be used consistently, but asking for them to be transparent is probably too much to hope for. (We can and should use intention-revealing names in a program, but doing it across the totality of all programs is something never achieved and probably never achievable.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: vty-ui 0.3
I'm happy to announce the release of vty-ui 0.3. Get it from Hackage: http://hackage.haskell.org/package/vty-ui Or get the source with darcs: http://repos.codevine.org/vty-ui Project homepage: http://codevine.org/vty-ui/ This version of vty-ui features a richer rendering engine, generalized text transformations, and a more functional style. If you've written any applications to use vty-ui, your type signatures and usage of a few of the built-in widget types will need to change but the API is largely the same. In particular, the largest change was a refactoring inspired by Luke Palmer's blog post, Haskell Antipattern: Existential Typeclass, which targeted vty-ui (among other libraries) in its treatment of the topic: http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ Here's a summary of changes: General * Replace Widget type class with a concrete Widget type * Move text widget into Graphics.Vty.Widgets.Text * Add support for generalized text formatters * Replace WrappedText widget type with a text-wrapping formatter * Provide a regex-based text-highlighting formatter (see the demo for an example) * Refactor the rendering engine to provide address information so you can get coordinates and size for rendered widgets * Add a few QuickCheck tests (and related fixes) Enjoy! -- Jonathan Daugherty ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
