You can subscribe to this list here.
2008 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}
(5) 

2009 
_{Jan}

_{Feb}

_{Mar}
(2) 
_{Apr}
(7) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2010 
_{Jan}

_{Feb}
(6) 
_{Mar}

_{Apr}
(2) 
_{May}

_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(6) 
_{Sep}
(10) 
_{Oct}
(2) 
_{Nov}
(3) 
_{Dec}
(6) 
2012 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(5) 
_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(7) 
_{Oct}
(3) 
_{Nov}
(10) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Dennis Ferron <system.windows.codeslinger@gm...>  20160823 16:28:25

I'm using Castor as well as SQLite in my program. I wrote a function which accepts lref's for database column values, and it either selects the value if the lref was undefined or it uses the value in the where claused if the lref was defined. As soon as the query is known, it reads all of the rows eagerly so that it can put them into a Disjunctions result. However, looking at the API for SQLite it occurred to me that there's a nice correspondence between how db readers work and how Castor works. With Castor, you create a relation, then while the relation is true you keep evaluating it and accessing lrefs gives the values for that iteration. With SQLite, you create a reader and while reader.step() is true, accessing columns from the reader gives the values for that iteration. It seems like a direct mapping would be a better way to use SQLite from Castor, and Castor could provide a more convenient way to use SQLite readers. However I foresee a problem in that SQLite readers have to opened and closed. Creating a relation and not terminating it would leave an open reader dangling, which is bad. I came up with a logic expression which I think solves part of the problem. What if my database function returned this: open_reader && step_reader && close_reader I believe this would result in the opening and closing I want. However I see several other problems with this: What if evaluation stops partway through? If I "and" the result of this equation with another will this actually just open the reader, step through all the rows, and close the reader before anything else happens? So do I need to turn the expression "inside out" and provide a lambda argument? I.e.: open_reader && step_reader && user_expression && close_reader The calling code of the above would look something like: db.read_rows(sql_string, tuple_of_lrefs, user_provided_expression) for example: db.read_rows("select id, name from employees", make_tuple(id_lref, name_lref), eq(name_lref, "john")  eq(id, 1234)) Note: Despite the eq's in the user expression, this example would have issued one select for all employees, not two selects or a where clause with "or", because both lref's were still undefined when *open_reader* was evaluated. However: (eq(name_lref, "john")  eq(id, 1234)) && db.read_rows(...) *would* do 2 selects, one for name john and one for id 1234, and would not select all of the employees. Anyway does this look like the right track? Is there a better approach that I'm missing? 
From: Angel Traversi <atraversi@gm...>  20141220 20:02:09

Hi! Yesterday I downloaded and compiled Castor 1.1 on Mac with XCode 6.2 on a project for iPhone. I could run several examples written in the tutorial smoothly! I am very happy to be able to use prolog again after so many years. I used Prolog in college, back in 1997. I also ran tests on the 'test' folder, mostly compiled correctly, but I had a compilation error that could not be resolved and wanted to comment. The error happens with test_tlr test, test_predicate and test_eq, and the message is: Undefined symbols for architecture x86_64: "std :: __ 1 :: basic_string <char, std :: __ 1 :: char_traits <char>, std :: __ 1 :: allocator <char>> :: length () const" referenced from: test_order_mf () in test_tlr.o Any help to solve it? Regards, Lic. Angel Traversi Enviado desde mi Mac 
From: Eugene Grigoriev <eugene.grigoriev@gm...>  20140710 16:08:47

Ok, looks like LC++ has no cut and no retract. So even though Castor is much uglier, it can do dynamic relations and do them fast.  Eugene Grigoriev +1 6503364041 +1 4149791024 On Thu, Jul 10, 2014 at 8:29 AM, Eugene Grigoriev < eugene.grigoriev@...> wrote: > Hi all, > > How does Castor compare to LC++? http://cgi.di.uoa.gr/~smaragd/lc++/ > > If somebody would try to give an objective reason why Castor is better > (disregarding the syntax), It will be greatly appreciated. I am leaning > toward LC++/FC++ simply because I know Haskell, but if Castor has some > feature(s) the other lacks (or is faster), I need to use Castor. > > > 
From: Eugene Grigoriev <eugene.grigoriev@gm...>  20140710 15:29:35

Hi all, How does Castor compare to LC++? http://cgi.di.uoa.gr/~smaragd/lc++/ If somebody would try to give an objective reason why Castor is better (disregarding the syntax), It will be greatly appreciated. I am leaning toward LC++/FC++ simply because I know Haskell, but if Castor has some feature(s) the other lacks (or is faster), I need to use Castor. 
From: Roshan Naik <roshan@mp...>  20121127 08:49:27

Hi Szymon, It depends on what kind of graph problems you are trying to solve. There are some simple DAG problems which I have described. For large graphs more optimized techniques would be of useful. Particularly to speedup lookups. As usual, DAGs are generally easier work with as compared to cyclic graphs. Personally, I have not pursued graph problems very deeply. So, out of the box there is no special support for graphs. I think a layer of reusable abstractions (relations or other primitives) might be helpful on top of the base Castor to be more effective. Some time ago there was AI related work that used Castor. Not sure if this has much overlap with the problems you are trying to solve. but here is a reference to it anyway.. Joris Ijsselmuiden, Rainer Stiefelhagen (2010) <http://www.mendeley.com/research/towardshighlevelhumanactivityrecognit ionthroughcomputervisiontemporallogic1/> Towards HighLevel Human Activity Recognition through Computer Vision and Temporal Logic, 426435. In KI 2010: Advances in Artificial Intelligence. <http://www.informatik.unitrier.de/~ley/db/indices/atree/i/Ijsselmuiden:Jo ris.html> http://www.informatik.unitrier.de/~l... <http://www.mendeley.com/download/public/2974111/3876888722/3b097f3ad6230eaa ea8ae1d4efe339e3e3cab15b/dl.pdf> Download PDF (328.08 KB) A multiparadigm approach to solving graph problems does interest me. Happy to lend my assistance. roshan From: Szymon Gatner [mailto:szymon.gatner@...] Sent: Monday, November 26, 2012 1:01 PM To: castorlogiclibrary@... Subject: [Castorlogiclibrary] Graph algortihms Hello, I am interested in using Castor for game AI related code. My understanding is that it would be fairly simple to describe a graph using logic relations between vertices. My question is: is Castor suitable to perform a patfinding in such graph?  Szymon Gatner 
From: Szymon Gatner <szymon.gatner@gm...>  20121126 21:00:43

Hello, I am interested in using Castor for game AI related code. My understanding is that it would be fairly simple to describe a graph using logic relations between vertices. My question is: is Castor suitable to perform a patfinding in such graph?  Szymon Gatner 
From: Roshan Naik <roshan@mp...>  20121118 19:46:14

Hi Reiner, Not problem. This is a venue for having such Qs answered. The eq() relation also requires T to support operator== Any relation can impose additional requirements. For each relations requirements are specified in the reference manual. Usually supporting = and == makes your struct/class usable with most relations. I think I should add a small advisory note along with lref<> requirements that operator== will be most often be required also as you are very likely that T with eq. In C++ struct and class are almost identical with two minor exceptions as described here http://www.parashift.com/c++faq/structvsclass.html roshan From: Reinhard Männer [mailto:r@...] Sent: Sunday, November 18, 2012 8:53 AM To: Roshan Naik Cc: castorlogiclibrary@... Subject: Re: lref's to structures possible? Hi Roshan, well, this section says that the template parameter T must support copy construction and copy assignment. Unfortunately, I don't know C++ well enough (I am an ObjectiveC programmer) to understand the consequences fully. As far as I know, a class supports at least default copy and assignment operation. Additionally, simple types like int or string apparently do support it also  you use it in your examples. But what about a struct as I used it in my example below? I can "assign" one variable of type "matrix_element" to another one. And if I can "copy construct" an int, it should be possible for a struct also. BTW: The complier points to the "eq" relation in relation s and says "In instantiation of function template specialization 'castor::relation::relation<castor::UnifyLR<matrix_element, matrix_element, castor::detail::None> >' requested here", which I neither understand. So, maybe I should replace the struct by a class? Best regards, Reiner PS: I am sorry that I am bombing you with questions. Am 17.11.2012 um 08:29 schrieb Roshan Naik <roshan@...>: Reiner, Take a look at page 10 of reference manual. The section is titled Requirements for template parameter T. Let me know if that works. roshan From: Reinhard Männer [mailto:r@...] Sent: Thursday, November 15, 2012 9:19 AM To: Roshan Naik Cc: castorlogiclibrary@... Subject: lref's to structures possible? Hi Roshan, I am sorry that I have to bother you again: Apparently it is not possible to have lref's to structures, like in the following code (this was not clear to me from reading the docs): struct matrix_element { int value; }; matrix_element me; me.value = 1; lref<matrix_element> lr_me_1 = me; lref<matrix_element> lr_me_2; relation s = eq(lr_me_1, lr_me_2); s(); Such code gives a compile error in the relation. Best regards, Reiner 
From: Reinhard Männer <r@mn...>  20121118 16:53:36

Hi Roshan, well, this section says that the template parameter T must support copy construction and copy assignment. Unfortunately, I don't know C++ well enough (I am an ObjectiveC programmer) to understand the consequences fully. As far as I know, a class supports at least default copy and assignment operation. Additionally, simple types like int or string apparently do support it also  you use it in your examples. But what about a struct as I used it in my example below? I can "assign" one variable of type "matrix_element" to another one. And if I can "copy construct" an int, it should be possible for a struct also. BTW: The complier points to the "eq" relation in relation s and says "In instantiation of function template specialization 'castor::relation::relation<castor::UnifyLR<matrix_element, matrix_element, castor::detail::None> >' requested here", which I neither understand. So, maybe I should replace the struct by a class? Best regards, Reiner PS: I am sorry that I am bombing you with questions. Am 17.11.2012 um 08:29 schrieb Roshan Naik <roshan@...>: > Reiner, > Take a look at page 10 of reference manual. The section is titled ‘Requirements for template parameter T’. Let me know if that works. > roshan > > > From: Reinhard Männer [mailto:r@...] > Sent: Thursday, November 15, 2012 9:19 AM > To: Roshan Naik > Cc: castorlogiclibrary@... > Subject: lref's to structures possible? > > Hi Roshan, > I am sorry that I have to bother you again: > Apparently it is not possible to have lref's to structures, like in the following code (this was not clear to me from reading the docs): > > struct matrix_element { > int value; > }; > > matrix_element me; > me.value = 1; > lref<matrix_element> lr_me_1 = me; > lref<matrix_element> lr_me_2; > relation s = eq(lr_me_1, lr_me_2); > s(); > > Such code gives a compile error in the relation. > Best regards, > Reiner > 
From: Roshan Naik <roshan@mp...>  20121117 07:29:20

Reiner, Take a look at page 10 of reference manual. The section is titled Requirements for template parameter T. Let me know if that works. roshan From: Reinhard Männer [mailto:r@...] Sent: Thursday, November 15, 2012 9:19 AM To: Roshan Naik Cc: castorlogiclibrary@... Subject: lref's to structures possible? Hi Roshan, I am sorry that I have to bother you again: Apparently it is not possible to have lref's to structures, like in the following code (this was not clear to me from reading the docs): struct matrix_element { int value; }; matrix_element me; me.value = 1; lref<matrix_element> lr_me_1 = me; lref<matrix_element> lr_me_2; relation s = eq(lr_me_1, lr_me_2); s(); Such code gives a compile error in the relation. Best regards, Reiner 
From: Reinhard Männer <r@mn...>  20121115 17:19:39

Hi Roshan, I am sorry that I have to bother you again: Apparently it is not possible to have lref's to structures, like in the following code (this was not clear to me from reading the docs): struct matrix_element { int value; }; matrix_element me; me.value = 1; lref<matrix_element> lr_me_1 = me; lref<matrix_element> lr_me_2; relation s = eq(lr_me_1, lr_me_2); s(); Such code gives a compile error in the relation. Best regards, Reiner 
From: Reinhard Männer <r@mn...>  20121109 16:46:02

Hi Roshan, thanks for your quick and detailed reply. You are, of course, right. I expected to get an lref to a list of int by calling head, and was not aware that I would get one lref more. Best regard, Reiner Am 08.11.2012 um 09:43 schrieb Roshan Naik <roshan@...>: > Hi Richard, > Since the highlighted portion below is the vector’s value_type. The type for h_lr_vc_lr_li_int should have been lref< lref< list<int> > > > > But, even if you fix it you will get a different error. > > The issue is as follows: head(), as you know, performs either comparison (if the second arg is initialized) with the first element, or assignment of head element to the second arg (if second arg is not initialized). > > In your case the type of head element is a lref<list<int> > , which will be compared with the second lref argument’s value type which is lref< list< … > >. Now this is a comparison of two lref’s and not a comparison of two lists as you might be expecting. Attempting to compare two lref’s creates an ILE. > > I think, What you want to do is eliminate the one extra lref level in the middle and use lref<vector<list<int> > > > > > > list<int> li_int; > li_int.push_back(1); li_int.push_back(2); li_int.push_back(3); > > vector<list<int>> vc_li_int; > vc_li_int.push_back(li_int); vc_li_int.push_back(li_int); vc_li_int.push_back(li_int); > > lref<vector<list<int>>> lr_vc_li_int = vc_li_int; > > lref< list< int > > first_elem; > > relation rh = head(lr_vc_li_int, first_elem); > > > roshan > > > From: Reinhard Männer [mailto:r@...] > Sent: Tuesday, November 06, 2012 9:33 PM > To: roshan@... > Cc: castorlogiclibrary@... > Subject: problem with head/tail of nested containers > > Hi Roshan, > sorry, another problem: > The following code gives a compile error in relation rh that I do not understand: > > // Define list of int = [1,2,3] and lref to it > list<int> li_int; li_int.push_back(1); li_int.push_back(2); li_int.push_back(3); > lref<list<int>> lr_li_int = li_int; > > // Define vector of (lrefs to such (refs to such lists)) and lref to it > vector<lref<list<int>>> vc_lr_li_int; vc_lr_li_int.push_back(lr_li_int); vc_lr_li_int.push_back(lr_li_int); vc_lr_li_int.push_back(lr_li_int); > lref<vector<lref<list<int>>>> lr_vc_lr_li_int = vc_lr_li_int; > > // Define lref to 1st element of vector > lref<list<int>> h_lr_vc_lr_li_int; > > // Define relation to get lref to 1st element of vector > relation rh = head(lr_vc_lr_li_int, h_lr_vc_lr_li_int); > > Maybe "head" cannot be applied to such nested structures? > Regards, > Reiner > 
From: Roshan Naik <roshan@mp...>  20121108 08:43:06

Hi Richard, Since the highlighted portion below is the vectors value_type. The type for h_lr_vc_lr_li_int should have been lref< lref< list<int> > > But, even if you fix it you will get a different error. The issue is as follows: head(), as you know, performs either comparison (if the second arg is initialized) with the first element, or assignment of head element to the second arg (if second arg is not initialized). In your case the type of head element is a lref<list<int> > , which will be compared with the second lref arguments value type which is lref< list< > >. Now this is a comparison of two lrefs and not a comparison of two lists as you might be expecting. Attempting to compare two lrefs creates an ILE. I think, What you want to do is eliminate the one extra lref level in the middle and use lref<vector<list<int> > > list<int> li_int; li_int.push_back(1); li_int.push_back(2); li_int.push_back(3); vector<list<int>> vc_li_int; vc_li_int.push_back(li_int); vc_li_int.push_back(li_int); vc_li_int.push_back(li_int); lref<vector<list<int>>> lr_vc_li_int = vc_li_int; lref< list< int > > first_elem; relation rh = head(lr_vc_li_int, first_elem); roshan From: Reinhard Männer [mailto:r@...] Sent: Tuesday, November 06, 2012 9:33 PM To: roshan@... Cc: castorlogiclibrary@... Subject: problem with head/tail of nested containers Hi Roshan, sorry, another problem: The following code gives a compile error in relation rh that I do not understand: // Define list of int = [1,2,3] and lref to it list<int> li_int; li_int.push_back(1); li_int.push_back(2); li_int.push_back(3); lref<list<int>> lr_li_int = li_int; // Define vector of (lrefs to such (refs to such lists)) and lref to it vector<lref<list<int>>> vc_lr_li_int; vc_lr_li_int.push_back(lr_li_int); vc_lr_li_int.push_back(lr_li_int); vc_lr_li_int.push_back(lr_li_int); lref<vector<lref<list<int>>>> lr_vc_lr_li_int = vc_lr_li_int; // Define lref to 1st element of vector lref<list<int>> h_lr_vc_lr_li_int; // Define relation to get lref to 1st element of vector relation rh = head(lr_vc_lr_li_int, h_lr_vc_lr_li_int); Maybe "head" cannot be applied to such nested structures? Regards, Reiner 
From: Reinhard Männer <r@mn...>  20121107 05:33:16

Hi Roshan, sorry, another problem: The following code gives a compile error in relation rh that I do not understand: // Define list of int = [1,2,3] and lref to it list<int> li_int; li_int.push_back(1); li_int.push_back(2); li_int.push_back(3); lref<list<int>> lr_li_int = li_int; // Define vector of (lrefs to such (refs to such lists)) and lref to it vector<lref<list<int>>> vc_lr_li_int; vc_lr_li_int.push_back(lr_li_int); vc_lr_li_int.push_back(lr_li_int); vc_lr_li_int.push_back(lr_li_int); lref<vector<lref<list<int>>>> lr_vc_lr_li_int = vc_lr_li_int; // Define lref to 1st element of vector lref<list<int>> h_lr_vc_lr_li_int; // Define relation to get lref to 1st element of vector relation rh = head(lr_vc_lr_li_int, h_lr_vc_lr_li_int); Maybe "head" cannot be applied to such nested structures? Regards, Reiner 
From: Reinhard Männer <r@mn...>  20121101 09:42:49

Hi Roshan, thanks for your quick reply. Actually I assumed that ^ has the same precedence level as that of operator , but the manual (which I did not read carefully enough, sorry) states clearly "operator ^ has a higher precedence than &&"... Reiner Am 31.10.2012 um 23:19 schrieb roshan@...: > Hi Reinhard, > Sure. I think you want to surround the highlighted expression with ( ) to accomodate the ^ operator's precedence level which is not same as that of operator  . > Do consider ccing to the mailing list also. > roshan > > On October 30, 2012 at 4:17 PM "Reinhard Männer" <r@...> wrote: >> Hi Roshan, >> sorry for being back. I am still trying to understand Castor programming, but I am currently stuck at one point: >> One of my programs, reduced to the absolute minimum, is: >> >> relation s( lref< int> lr_index){ >> lref< int> lr_next_index; // next index >> >> return write( "lr_index: ") && write(lr_index) && write( "\n") && >> ( >> predicate(lr_index >= 3) >> ^ >> next(lr_index, lr_next_index) >> && recurse(s, lr_next_index) >> ); >> } >> >> void test::oneSolution(){ >> if ( s( 0)()) { >> cout << "solution found\n" ; >> } >> >> When I run this program, I get the output: >> >> lr_index: 0 >> lr_index: 1 >> lr_index: 2 >> lr_index: 3 >> lr_index: >> >> and then an exception is thrown in: >> >> T& operator*() const { >> if (reset_ ) throw InvalidDeref (); // here, so something is not initialized that should be so >> return * ptr_; >> >> What I expected was that the program stops at lr_index == 3 with s == true, and prints out "solution found\n". >> So, why does this program not stop at lr_index == 3? It should return with true until it prints out "solution found\n". >> Cheers, >> Reiner >> >> Am 09.10.2012 um 09:44 schrieb Roshan Naik < roshan@...>: >> >>> Seems to be an issue with in that example. Passing the containers(i.e sequence) by value is not supported (as noted in reference manual). >>> roshan >>> >>> From: Reinhard Männer [mailto:r@...] >>> Sent: Monday, October 08, 2012 11:58 PM >>> To: Roshan Naik >>> Cc: castorlogiclibrary@... >>> Subject: Castor tutorial: Sequence example does not compile >>> >>> Hi Roshan, >>> I tried to run an example of the tutorial (part 2.8.1), but it does not compile under Apple LLVM compiler 4.1. But with a slight modification it compiles, see below. >>> Do you have any idea what is wrong? >>> Regards, >>> Reiner >>> >>> string s = "One"; lref<string> lrs = "Two"; >>> vector<string> ls; ls.push_back("Three"); ls.push_back("Four"); >>> vector<string> lsTemp; lsTemp.push_back("Five"); lsTemp.push_back("Six"); >>> lref<vector<string> > lrls = lsTemp; >>> // create the sequence into ln >>> lref<vector<string> > ln; >>> // The following line gives a compiler error (no matching member function for call to 'push_back') and is commented out >>> // relation numbers = sequence(ln)("Zero")(s)(lrs)(ls)(lrls); >>> // With the following 2 lines it compiles >>> lref<vector<string> > lls = ls; // added >>> relation numbers = sequence(ln)("Zero")(s)(lrs)(lls)(lrls); // modified >>> // see what it generates >>> if(numbers()) >>> copy(ln>begin(), ln>end(), ostream_iterator<string>(cout," ")); > 
From: Roshan Naik <roshan@mp...>  20121009 07:44:47

Seems to be an issue with in that example. Passing the containers(i.e sequence) by value is not supported (as noted in reference manual). roshan From: Reinhard Männer [mailto:r@...] Sent: Monday, October 08, 2012 11:58 PM To: Roshan Naik Cc: castorlogiclibrary@... Subject: Castor tutorial: Sequence example does not compile Hi Roshan, I tried to run an example of the tutorial (part 2.8.1), but it does not compile under Apple LLVM compiler 4.1. But with a slight modification it compiles, see below. Do you have any idea what is wrong? Regards, Reiner string s = "One"; lref<string> lrs = "Two"; vector<string> ls; ls.push_back("Three"); ls.push_back("Four"); vector<string> lsTemp; lsTemp.push_back("Five"); lsTemp.push_back("Six"); lref<vector<string> > lrls = lsTemp; // create the sequence into ln lref<vector<string> > ln; // The following line gives a compiler error (no matching member function for call to 'push_back') and is commented out // relation numbers = sequence(ln)("Zero")(s)(lrs)(ls)(lrls); // With the following 2 lines it compiles lref<vector<string> > lls = ls; // added relation numbers = sequence(ln)("Zero")(s)(lrs)(lls)(lrls); // modified // see what it generates if(numbers()) copy(ln>begin(), ln>end(), ostream_iterator<string>(cout," ")); 
From: Roshan Naik <roshan@mp...>  20121009 07:26:28

Reiner, >> 1st of all, the Castor package is really VERY powerful. Thanks a lot for providing this package for free. My pleasure. >> If I understand the Exclusive Distinction of Castor right, "x ^ y" means "If x EVER succeeds, then x, else y". Therefore I would call it rather ifthenelse than exclusive distinction, but this is a matter of taste. Yes I have been thinking along the same lines. Everyone raises an eyebrow when I try to explain it. >> One more thing: the permutation relation provided by Castor is really called "permutation", as specified in the docs. However, in the examples given there, it is called "permute". So when I copied the example code and tried to compile it, I got an error, and was worried what was going on. Thanks for pointing it out. roshan 
From: Reinhard Männer <r@mn...>  20121009 06:58:15

Hi Roshan, I tried to run an example of the tutorial (part 2.8.1), but it does not compile under Apple LLVM compiler 4.1. But with a slight modification it compiles, see below. Do you have any idea what is wrong? Regards, Reiner string s = "One"; lref<string> lrs = "Two"; vector<string> ls; ls.push_back("Three"); ls.push_back("Four"); vector<string> lsTemp; lsTemp.push_back("Five"); lsTemp.push_back("Six"); lref<vector<string> > lrls = lsTemp; // create the sequence into ln lref<vector<string> > ln; // The following line gives a compiler error (no matching member function for call to 'push_back') and is commented out // relation numbers = sequence(ln)("Zero")(s)(lrs)(ls)(lrls); // With the following 2 lines it compiles lref<vector<string> > lls = ls; // added relation numbers = sequence(ln)("Zero")(s)(lrs)(lls)(lrls); // modified // see what it generates if(numbers()) copy(ln>begin(), ln>end(), ostream_iterator<string>(cout," ")); 
From: Roshan Naik <roshan@mp...>  20120924 05:48:53

I hope you do see that the solution in Castor is more simple and direct than the suggested alternative. Using an operator system purely based on && and ^ for general purpose programming would lead to a terrible readability problem in my opinion. The newer >>= operator is another nonstandard operator which greatly helps in more elegant expressions wherever applicable. Although it is possible to achieve equivalent semantics using other more standard operators, they would lead to a lot of ugliness. Its good to know why things are done a certain way, but you may want to avoid getting stuck on design issues too soon. Building the relational mindset should make the tradeoffs clearer. roshan From: Reinhard Männer [mailto:r@...] Sent: Sunday, September 23, 2012 8:06 AM To: Roshan Naik Cc: castorlogiclibrary@... Subject: Re: [Castorlogiclibrary] Bug in Exclusive Disjunction ? Hi Roshan, I very much appreciate that you try to explain "relations logic". Thanks a lot. But it is simply too unusual for me yet beacse I am only used to Boolean logic. My example  based on Boolean logic  was simply the following: There are "complete operator systems" that allow to express any Boolean expression by just using these operators. One of them is "And" and "Exclusive Or". Using these operators only, negation of x can be expressed as "x exclusive or 1", since if x is true, the results is false and vice versa. So my hope was to express unequals(a,b), where a and b are initialized lrefs, by "eq(a,b) ^ eq("a","a")", since eq("a","a") always evaluates successfully. But surely, I am still too much focused to Boolean logic. Reiner Am 22.09.2012 um 21:16 schrieb Roshan Naik: The &&,  and ^ operators are really mechanisms to coordinate the evaluation of relations (i.e. their arguments) in different ways. The current semantics provide the equivalent of the imperative if else construct if( cond1 ) { x1(); } else if ( cond2 ) { x2(); } else { X3(); } Which can be expressed using ExOr.. ( cond1() && x1() ) ^ ( cond2() && x2() ) ^ x3() This is a common use case and it is harder to express easily and elegantly otherwise (same problem in Prolog). This is the key reason. The more natural extension to the standard ExOr semantics that you are talking about would support some other use cases which are relatively less common but can often be expressed differently. > This definition would be invariant against an interchange of lref and rref, and it would be more similar to the binary exclusive OR than Castor's. It would allow, I believe, e.g., an expression like "relation ^ equ("a","a")" that would negate "relation". I do not think I understand this example of negation. If you can come up with a clearer use case then I can comment. roshan From: Reinhard Männer [mailto:r@...] Sent: Saturday, September 22, 2012 9:54 AM To: Roshan Naik Cc: castorlogiclibrary@... Subject: Re: [Castorlogiclibrary] Bug in Exclusive Disjunction ? Hi Roshan, again, thanks for your quick reply, and sorry for these long emails. First, your explanation to my question 2) is very helpful. Sorry that I did not study the tutorial and the docs well enough to come up with the right solution by myself. As I said, I am a Castor (and LP) newbie with little experience with Prolog only. But your explanation is completely sound. Regarding your comments on Exclusive Disjunction, I don't feel so happy. Of course, it is a different function as the binary logic exclusive OR, but I think it should resemble this one as far as possible. One point is that the exclusive OR is symmetric, i.e. independent against an exchange of its 2 arguments, which Castor's exclusive distinction is not. Let me try to assemble Castor's current function (if I understand it right) in a "truth table", where a relation can have 3 states: 1) it never succeeds, 2) is succeeds, or 3) it succeeds no more (i.e. it succeeded before, but does it no longer). Then the truth table of Castor's Exclusive Disjunction takes the following form: lhs succeeds rhs succeeds result succeeds never never never never yes yes never no more no more yes never yes yes yes yes yes no more yes no more never no more no more yes no more no more no more no more To my mind, the truth table should look like (differences in CAPS): lhs succeeds rhs succeeds result succeeds never never never never yes yes never no more no more yes never yes yes yes NO yes no more yes no more never no more no more yes YES no more no more no more This definition would be invariant against an interchange of lref and rref, and it would be more similar to the binary exclusive OR than Castor's. It would allow, I believe, e.g., an expression like "relation ^ equ("a","a")" that would negate "relation". So, in which respect is the current definition better than the suggested one? Sorry again for the long question, but I seriously want to use Castor in my programs, and I want to understand how it behaves, and why. Reiner Am 22.09.2012 um 08:45 schrieb Roshan Naik: >> But this is exactly the behavior of the INCLUSIVE Disjunction. So, where is the difference? 1) The difference is that rhs is executed ONLY if lhs never succeeded. Look carefully at the header of the second while loop in ExOr. while(!lhsSucceded && rhs()) Does that make sense ? >> I simply wanted to formulate a relation that says "lref a is different from lref b" where a and b are initialized. 2) Good question about negation. Sometimes negation can get tricky in logic programming. But in this case it is easy (see section 2.7 in tutorial for explanation) .. predicate(a!=b) Thats all you need to know when starting out, but someday you might find this additional info of interest. .. Actually IMHO, this solution is not pure LP. It is a combination of functional and LP. A pure LP solution would have to be something like this.. not_eq(a,b) Such a relation does not exist in Castor. But if it did, it would have the following semantics to be pure and faithful LP. (Lets assume a & b are integers):  If a and b are both initialized then return the succeeds if a!=b  If only one of them is initialized (lets say a is initialized). Then it would generate all possible integers for b that are not equal to a.  If both are not initialized, it would generate all pairs of integers that are not equal. It may look reasonable to implement such generative behavior for integers but gets weird if a & b are of type string, floating point number, complex number etc. The enumeration strategy for all possible values is no longer straightforward. IMHO, you are rarely interested in such behavior. But if you really need it, you can always implement relations like not_eq_int() or not_eq_myType() using coroutines (chapter 3). Of course a refinement is to pass the enumerator as a argument .. not_eq(a,b, gen_strings). roshan 
From: Roshan Naik <roshan@mp...>  20120922 19:16:52

The &&,  and ^ operators are really mechanisms to coordinate the evaluation of relations (i.e. their arguments) in different ways. The current semantics provide the equivalent of the imperative if else construct if( cond1 ) { x1(); } else if ( cond2 ) { x2(); } else { X3(); } Which can be expressed using ExOr.. ( cond1() && x1() ) ^ ( cond2() && x2() ) ^ x3() This is a common use case and it is harder to express easily and elegantly otherwise (same problem in Prolog). This is the key reason. The more natural extension to the standard ExOr semantics that you are talking about would support some other use cases which are relatively less common but can often be expressed differently. > This definition would be invariant against an interchange of lref and rref, and it would be more similar to the binary exclusive OR than Castor's. It would allow, I believe, e.g., an expression like "relation ^ equ("a","a")" that would negate "relation". I do not think I understand this example of negation. If you can come up with a clearer use case then I can comment. roshan From: Reinhard Männer [mailto:r@...] Sent: Saturday, September 22, 2012 9:54 AM To: Roshan Naik Cc: castorlogiclibrary@... Subject: Re: [Castorlogiclibrary] Bug in Exclusive Disjunction ? Hi Roshan, again, thanks for your quick reply, and sorry for these long emails. First, your explanation to my question 2) is very helpful. Sorry that I did not study the tutorial and the docs well enough to come up with the right solution by myself. As I said, I am a Castor (and LP) newbie with little experience with Prolog only. But your explanation is completely sound. Regarding your comments on Exclusive Disjunction, I don't feel so happy. Of course, it is a different function as the binary logic exclusive OR, but I think it should resemble this one as far as possible. One point is that the exclusive OR is symmetric, i.e. independent against an exchange of its 2 arguments, which Castor's exclusive distinction is not. Let me try to assemble Castor's current function (if I understand it right) in a "truth table", where a relation can have 3 states: 1) it never succeeds, 2) is succeeds, or 3) it succeeds no more (i.e. it succeeded before, but does it no longer). Then the truth table of Castor's Exclusive Disjunction takes the following form: lhs succeeds rhs succeeds result succeeds never never never never yes yes never no more no more yes never yes yes yes yes yes no more yes no more never no more no more yes no more no more no more no more To my mind, the truth table should look like (differences in CAPS): lhs succeeds rhs succeeds result succeeds never never never never yes yes never no more no more yes never yes yes yes NO yes no more yes no more never no more no more yes YES no more no more no more This definition would be invariant against an interchange of lref and rref, and it would be more similar to the binary exclusive OR than Castor's. It would allow, I believe, e.g., an expression like "relation ^ equ("a","a")" that would negate "relation". So, in which respect is the current definition better than the suggested one? Sorry again for the long question, but I seriously want to use Castor in my programs, and I want to understand how it behaves, and why. Reiner Am 22.09.2012 um 08:45 schrieb Roshan Naik: >> But this is exactly the behavior of the INCLUSIVE Disjunction. So, where is the difference? 1) The difference is that rhs is executed ONLY if lhs never succeeded. Look carefully at the header of the second while loop in ExOr. while(!lhsSucceded && rhs()) Does that make sense ? >> I simply wanted to formulate a relation that says "lref a is different from lref b" where a and b are initialized. 2) Good question about negation. Sometimes negation can get tricky in logic programming. But in this case it is easy (see section 2.7 in tutorial for explanation) .. predicate(a!=b) Thats all you need to know when starting out, but someday you might find this additional info of interest. .. Actually IMHO, this solution is not pure LP. It is a combination of functional and LP. A pure LP solution would have to be something like this.. not_eq(a,b) Such a relation does not exist in Castor. But if it did, it would have the following semantics to be pure and faithful LP. (Lets assume a & b are integers):  If a and b are both initialized then return the succeeds if a!=b  If only one of them is initialized (lets say a is initialized). Then it would generate all possible integers for b that are not equal to a.  If both are not initialized, it would generate all pairs of integers that are not equal. It may look reasonable to implement such generative behavior for integers but gets weird if a & b are of type string, floating point number, complex number etc. The enumeration strategy for all possible values is no longer straightforward. IMHO, you are rarely interested in such behavior. But if you really need it, you can always implement relations like not_eq_int() or not_eq_myType() using coroutines (chapter 3). Of course a refinement is to pass the enumerator as a argument .. not_eq(a,b, gen_strings). roshan 
From: Reinhard Männer <r@mn...>  20120922 16:59:13

Hi Roshan, again, thanks for your quick reply, and sorry for these long emails. First, your explanation to my question 2) is very helpful. Sorry that I did not study the tutorial and the docs well enough to come up with the right solution by myself. As I said, I am a Castor (and LP) newbie with little experience with Prolog only. But your explanation is completely sound. Regarding your comments on Exclusive Disjunction, I don't feel so happy. Of course, it is a different function as the binary logic exclusive OR, but I think it should resemble this one as far as possible. One point is that the exclusive OR is symmetric, i.e. independent against an exchange of its 2 arguments, which Castor's exclusive distinction is not. Let me try to assemble Castor's current function (if I understand it right) in a "truth table", where a relation can have 3 states: 1) it never succeeds, 2) is succeeds, or 3) it succeeds no more (i.e. it succeeded before, but does it no longer). Then the truth table of Castor's Exclusive Disjunction takes the following form: lhs succeeds rhs succeeds result succeeds never never never never yes yes never no more no more yes never yes yes yes yes yes no more yes no more never no more no more yes no more no more no more no more To my mind, the truth table should look like (differences in CAPS): lhs succeeds rhs succeeds result succeeds never never never never yes yes never no more no more yes never yes yes yes NO yes no more yes no more never no more no more yes YES no more no more no more This definition would be invariant against an interchange of lref and rref, and it would be more similar to the binary exclusive OR than Castor's. It would allow, I believe, e.g., an expression like "relation ^ equ("a","a")" that would negate "relation". So, in which respect is the current definition better than the suggested one? Sorry again for the long question, but I seriously want to use Castor in my programs, and I want to understand how it behaves, and why. Reiner Am 22.09.2012 um 08:45 schrieb Roshan Naik: > > >> But this is exactly the behavior of the INCLUSIVE Disjunction. So, where is the difference? > > 1) The difference is that rhs is executed ONLY if lhs never succeeded. Look carefully at the header of the second while loop in ExOr. > while(!lhsSucceded && rhs()) > > Does that make sense ? > > >> I simply wanted to formulate a relation that says "lref a is different from lref b" where a and b are initialized. > > 2) Good question about negation. Sometimes negation can get tricky in logic programming. But in this case it is easy (see section 2.7 in tutorial for explanation) .. > > predicate(a!=b) > > That’s all you need to know when starting out, but someday you might find this additional info of interest. .. > > Actually IMHO, this solution is not pure LP. It is a combination of functional and LP. A pure LP solution would have to be something like this.. > > not_eq(a,b) > > Such a relation does not exist in Castor. But if it did, it would have the following semantics to be pure and faithful LP. (Let’s assume a & b are integers): >  If a and b are both initialized then return the succeeds if a!=b >  If only one of them is initialized (let’s say ‘a’ is initialized). Then it would generate all possible integers for b that are not equal to a. >  If both are not initialized, it would generate all pairs of integers that are not equal. > > It may look reasonable to implement such generative behavior for integers but gets weird if a & b are of type string, floating point number, complex number etc. The enumeration strategy for all possible values is no longer straightforward. > > IMHO, you are rarely interested in such behavior. But if you really need it, you can always implement relations like not_eq_int() or not_eq_myType() using coroutines (chapter 3). Of course a refinement is to pass the enumerator as a argument .. not_eq(a,b, gen_strings). > > roshan > 
From: Roshan Naik <roshan@mp...>  20120922 06:45:41

>> But this is exactly the behavior of the INCLUSIVE Disjunction. So, where is the difference? 1) The difference is that rhs is executed ONLY if lhs never succeeded. Look carefully at the header of the second while loop in ExOr. while(!lhsSucceded && rhs()) Does that make sense ? >> I simply wanted to formulate a relation that says "lref a is different from lref b" where a and b are initialized. 2) Good question about negation. Sometimes negation can get tricky in logic programming. But in this case it is easy (see section 2.7 in tutorial for explanation) .. predicate(a!=b) That’s all you need to know when starting out, but someday you might find this additional info of interest. .. Actually IMHO, this solution is not pure LP. It is a combination of functional and LP. A pure LP solution would have to be something like this.. not_eq(a,b) Such a relation does not exist in Castor. But if it did, it would have the following semantics to be pure and faithful LP. (Let’s assume a & b are integers):  If a and b are both initialized then return the succeeds if a!=b  If only one of them is initialized (let’s say ‘a’ is initialized). Then it would generate all possible integers for b that are not equal to a.  If both are not initialized, it would generate all pairs of integers that are not equal. It may look reasonable to implement such generative behavior for integers but gets weird if a & b are of type string, floating point number, complex number etc. The enumeration strategy for all possible values is no longer straightforward. IMHO, you are rarely interested in such behavior. But if you really need it, you can always implement relations like not_eq_int() or not_eq_myType() using coroutines (chapter 3). Of course a refinement is to pass the enumerator as a argument .. not_eq(a,b, gen_strings). roshan 
From: Reinhard Männer <r@mn...>  20120921 15:18:02

Hi Roshan, thanks for your quick reply, and  once again  for this great software. You are surely right: I am not used yet to think in relations. Thus, I have 2 questions: To find out where I am wrong, and what really happens in Castor, I compared the 2 pseudo codes for Inclusive Disjunction and Exclusive Disjunction in the docs: Inclusive Disjunction, copied from the docs: while( l() ) yield return true; // Not C++. „yield‟ keyword borrowed from C# while( r() ) yield return true; return false; //no more solutions left Here, I understand, the 1st while loop yields true as long as the left hand side succeeds, and thus the Inclusive Disjunction succeeds as long as well. When the 1st loop does no longer succeed, the 2nd while loop is executed, and succeeds, as long as the right hand side succeeds, and thus the Inclusive Disjunction succeeds as long as well. Only when the left hand side AND the right hand side no longer succeed, the Inclusive Disjunction neither succeeds. This is the behavior of an inclusive OR. Now to the Exclusive Disjunction, copied from the docs: //This is psuedo code! bool lhsSucceded = false; while( lhs() ) { lhsSucceded = true; yield return true; // Not C++. „yield‟ keyword is not valid C++ } while(!lhsSucceded && rhs()) yield return true; return false; Here, again to my understanding, the 1st while loop yields true as long as the left hand side succeeds, and thus the Exclusive Disjunction succeeds as long as well  INDEPENDENT OF WHETHER THE RIGHT HAND SIDE WOULD SUCCEED. When the 1st loop does not succeed, the 2nd while loop is executed, and succeeds, as long as the right hand side succeeds, and thus the Exclusive Disjunction succeeds as well. Only when the left hand side AND the right hand side no longer succeed, the Exclusive Disjunction neither succeeds. But this is exactly the behavior of the INCLUSIVE Disjunction. So, where is the difference? Sorry for this maybe naive question, but I am used to traditional logic, and not to relations logic. This brings me to my 2nd question: For my 1st tests, I simply wanted to formulate a relation that says "lref a is different from lref b" where a and b are initialized. It is of course easy to say "lref a is the same as lref b" if a and b are initialized, namely eq(a,b). But how to negate this? My hope was that I can use the formula "NOT a equals a EXCLUSIVE OR 1", i.e. something like eq(a,b) ^ eq("s","s"). But this does not work, since the Exclusive Disjunction works differently than I expected. Can you help me? Reiner Am 21.09.2012 um 10:16 schrieb Roshan Naik: > Reiner, > What you say is true for the semantics of the standard (non relational) > ExOr. In practice, those semantics are much less useful for relational > programming and thus the same operator's meaning has been slightly tweaked > when the arguments are relations(generating multiple answers). This is a > purely practical matter. The meaning is close enough but not really. The > alternative solutions were worse... > >  Invent a new operator (e.g. ^^) and give it a new name .. this is not > possible in C++ >  Use a different operator .. the other choices were much worse. > > As far as I can tall, in English the usage of 'either or' or even just 'or' > is less precise in comparison to the mathematical/computer science > definitions. In the documentation I exploit this purely for pedagogical > purposes. > > So, the document is correct. I did expect people to find this a bit weird > initially when they encountered it. > > roshan > "It's not a bug. It’s a feature" :) > > > Original Message > From: Reinhard Männer [mailto:r@...] > Sent: Thursday, September 20, 2012 2:06 AM > To: castorlogiclibrary@... > Subject: [Castorlogiclibrary] Bug in Exclusive Disjunction ? > > Hi, > by chance I found this great library, and am about testing my 1st programs. > Now I have a problem with the Exclusive Disjunction operator. > The manual says first: "Exclusive disjunction is a binary relation between > any two relations with a meaning similar to “either or” in English." > But then it continues, in contradiction to the 1st sentence: "A simplified > definition for exclusive disjunction is: a relation that succeeds when one > of its argument relations succeeds. The second argument is evaluated only if > the first does not succeed." > > To my understanding, both arguments have always to be evaluated, because the > operator should only succeed if exactly one of the arguments succeeds. > As it is implemented now, the operator succeeds if the 1st arguments > succeeds, EVEN IF the 2nd arguments would also succeed. But this is not the > correct behavior of an exclusive disjunction. > Am I right or did I understand something wrong? > Reiner >  >  > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics Download AppDynamics Lite for > free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Castorlogiclibrary mailing list > Castorlogiclibrary@... > https://lists.sourceforge.net/lists/listinfo/castorlogiclibrary > 
From: Roshan Naik <roshan@mp...>  20120921 08:29:52

Reiner, What you say is true for the semantics of the standard (non relational) ExOr. In practice, those semantics are much less useful for relational programming and thus the same operator's meaning has been slightly tweaked when the arguments are relations(generating multiple answers). This is a purely practical matter. The meaning is close enough but not really. The alternative solutions were worse...  Invent a new operator (e.g. ^^) and give it a new name .. this is not possible in C++  Use a different operator .. the other choices were much worse. As far as I can tall, in English the usage of 'either or' or even just 'or' is less precise in comparison to the mathematical/computer science definitions. In the documentation I exploit this purely for pedagogical purposes. So, the document is correct. I did expect people to find this a bit weird initially when they encountered it. roshan "It's not a bug. Its a feature" :) Original Message From: Reinhard Männer [mailto:r@...] Sent: Thursday, September 20, 2012 2:06 AM To: castorlogiclibrary@... Subject: [Castorlogiclibrary] Bug in Exclusive Disjunction ? Hi, by chance I found this great library, and am about testing my 1st programs. Now I have a problem with the Exclusive Disjunction operator. The manual says first: "Exclusive disjunction is a binary relation between any two relations with a meaning similar to either or in English." But then it continues, in contradiction to the 1st sentence: "A simplified definition for exclusive disjunction is: a relation that succeeds when one of its argument relations succeeds. The second argument is evaluated only if the first does not succeed." To my understanding, both arguments have always to be evaluated, because the operator should only succeed if exactly one of the arguments succeeds. As it is implemented now, the operator succeeds if the 1st arguments succeeds, EVEN IF the 2nd arguments would also succeed. But this is not the correct behavior of an exclusive disjunction. Am I right or did I understand something wrong? Reiner   Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Castorlogiclibrary mailing list Castorlogiclibrary@... https://lists.sourceforge.net/lists/listinfo/castorlogiclibrary 
From: Reinhard Männer <r@mn...>  20120920 09:06:25

Hi, by chance I found this great library, and am about testing my 1st programs. Now I have a problem with the Exclusive Disjunction operator. The manual says first: "Exclusive disjunction is a binary relation between any two relations with a meaning similar to “either or” in English." But then it continues, in contradiction to the 1st sentence: "A simplified definition for exclusive disjunction is: a relation that succeeds when one of its argument relations succeeds. The second argument is evaluated only if the first does not succeed." To my understanding, both arguments have always to be evaluated, because the operator should only succeed if exactly one of the arguments succeeds. As it is implemented now, the operator succeeds if the 1st arguments succeeds, EVEN IF the 2nd arguments would also succeed. But this is not the correct behavior of an exclusive disjunction. Am I right or did I understand something wrong? Reiner 
From: <roshan@mp...>  20120623 18:18:34

+ castor mailing list. Hi Chris, > Assigning NULL to it via set_ptr does set the lref internal pointer to > NULL, but the lref remains... I assume you meant to say 'but the referenced object remains' lref is a simple reference counted smart pointer. Once there are no more lref's pointing to the same object, the reference count drops to zero and the referenced object will be automatically deleted. Normally there should be no need to worry about the lifetime of the underlying object. For situations where you do not want lref to be responsible for deletion of the object (eg. you want it to point directly at a global object without creating a separate copy) you can use the the set_ptr method or the constructor that takes a second bool argument. Section 3.1 in the reference manual <http://mpprogramming.com/resources/CastorReference.pdf>; discusses how lref performs memory management with some examples. Let me know if your question remains unresolved. roshan On June 22, 2012 at 10:41 AM Christopher Dartnell <christopher.dartnell@...> wrote: > Hello, > > First off all, I must say I was very pleased to find such a library > allowing to easilly mix LP with usual programming. > I guess you have a lot of questions from people trying Castor, but I hope > you'll find some time to answer mine. I've read the well written tutorial > several times, and searched through forums, but I'm missing something here: > > I'm testing Castor as a constraint manager to tell if I can add/move/remove > objects in an environment. > > How can I be sure that a lref is deleted/destroyed? > > assigning NULL to it via set_ptr does set the lref internal pointer to > NULL, but the lref remains... > if its lifespan is "managed", what part of castor manages it? > Should I use references instead of objects to initialize the lrefs, and > then delete them? > > Best regards, > Christopher Dartnell 