## reduce-algebra-developers — Discussion of development, administration and support for Reduce

You can subscribe to this list here.

 2009 2010 2011 2012 2013 2014 2015 2016 2017 Jan (2) Feb (5) Mar Apr May (2) Jun (8) Jul (4) Aug Sep Oct (2) Nov (6) Dec Jan (1) Feb (1) Mar (3) Apr (2) May (2) Jun (2) Jul (18) Aug (13) Sep (7) Oct Nov Dec (2) Jan Feb (11) Mar Apr (4) May Jun (1) Jul (18) Aug (16) Sep (12) Oct (12) Nov (19) Dec (42) Jan (16) Feb (3) Mar (8) Apr (14) May (30) Jun (5) Jul (7) Aug (3) Sep (10) Oct (4) Nov (10) Dec (1) Jan (14) Feb (8) Mar (5) Apr (3) May (9) Jun (19) Jul Aug (27) Sep (5) Oct (18) Nov (12) Dec (8) Jan (5) Feb (8) Mar (20) Apr (22) May (28) Jun (9) Jul (6) Aug (46) Sep (40) Oct (15) Nov (8) Dec (34) Jan (20) Feb (15) Mar (18) Apr (20) May (3) Jun (13) Jul (10) Aug (19) Sep (8) Oct (31) Nov (26) Dec (13) Jan (13) Feb (4) Mar (14) Apr (28) May (19) Jun (7) Jul (1) Aug Sep (19) Oct (5) Nov (4) Dec (9) Jan (4) Feb (23) Mar Apr May Jun Jul Aug Sep Oct Nov Dec
S M T W T F S
1

2

3

4

5
(3)
6
(1)
7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22
(4)
23

24

25

26

27
(1)
28

29

30

Showing 9 results of 9

 [Reduce-algebra-developers] Returning roots_of from solve From: Rainer Schöpf - 2014-06-27 20:06:13 ```The following behaviour seems inconsistent: after "operator f;" solve(f(x)=x,x); returns {x=root_of( - f(x_) + x_,x_,tag_2)} but solve(f(x)=a,x); returns {f(x) - a=0} I believe it should be {x=root_of(f(x_),x_,tag_1)} (and it's a simple change in solve/solve11.red) What do others think? Rainer ```
 Re: [Reduce-algebra-developers] problem in packages/plot/plotsynt.red, svn 2567 From: Kostas Oikonomou - 2014-06-22 15:20:42 ```Well, there is also a typo in my report of the typo :-) I am also making progress with the NLopt interface, although it is slow going. Kostas On 06/22/2014 11:04, Arthur Norman wrote: > Thank you. That indeed looks like a simple typo and I am certain that > Winfried will sort it out shortly. Meanwhile one of the super things > about subversion is that one can easily go something like > svn -r 2565 update packages/plot/plotsynt.red > to get back the version of that file just before the change and hence > get yourself able to build/run again. Apologies for the blip ^ thanks > for reporting it to us. Good to know there are users out there! > Arthur > > On Sun, 22 Jun 2014, Kostas Oikonomou wrote: > >> I neglected to mention that this prevents the gnuplot package from >> working... >> >> On 06/22/2014 09:33, Kostas Oikonomou wrote: >>> There seems to be a type in the lines >>> >>> % "init" on the next line looks like an und!*eclared variable, however >>> t!-reval >>> % plotdriver is a macro and uses it as a literal... >>> >>> Kostas >> ```
 Re: [Reduce-algebra-developers] problem in packages/plot/plotsynt.red, svn 2567 From: Arthur Norman - 2014-06-22 15:04:41 ```Thank you. That indeed looks like a simple typo and I am certain that Winfried will sort it out shortly. Meanwhile one of the super things about subversion is that one can easily go something like svn -r 2565 update packages/plot/plotsynt.red to get back the version of that file just before the change and hence get yourself able to build/run again. Apologies for the blip ^ thanks for reporting it to us. Good to know there are users out there! Arthur On Sun, 22 Jun 2014, Kostas Oikonomou wrote: > I neglected to mention that this prevents the gnuplot package from > working... > > On 06/22/2014 09:33, Kostas Oikonomou wrote: >> There seems to be a type in the lines >> >> % "init" on the next line looks like an und!*eclared variable, however >> t!-reval >> % plotdriver is a macro and uses it as a literal... >> >> Kostas > ```
 Re: [Reduce-algebra-developers] problem in packages/plot/plotsynt.red, svn 2567 From: Kostas Oikonomou - 2014-06-22 14:32:38 ```I neglected to mention that this prevents the gnuplot package from working... On 06/22/2014 09:33, Kostas Oikonomou wrote: > There seems to be a type in the lines > > % "init" on the next line looks like an und!*eclared variable, however > t!-reval > % plotdriver is a macro and uses it as a literal... > > Kostas ```
 [Reduce-algebra-developers] problem in packages/plot/plotsynt.red, svn 2567 From: Kostas Oikonomou - 2014-06-22 13:31:55 ```There seems to be a type in the lines % "init" on the next line looks like an und!*eclared variable, however t!-reval % plotdriver is a macro and uses it as a literal... Kostas ```
 Re: [Reduce-algebra-developers] interface to NLopt, 0-th step From: Arthur Norman - 2014-06-06 06:46:49 ```On Thu, 5 Jun 2014, Kostas Oikonomou wrote: > Dear Arthur, > Thanks, I can test quite easily in the way you suggest. But it seems > that I'm missing something: > > 5* in ""nlopt.red" > .... > 6* {v1,v2,v3} := nlopt_version(); > +++ Error bad args for call-foreign-function > > So I must be doing something wrong in these lines from nlopt.red: > > % NLOPT_EXTERN(void) nlopt_version(int *major, int *minor, int *bugfix); > call!-foreign!-function(nlopt_version!*, 'int32, major, 'int32, minor, > 'int32, bugfix); In part because I have a bunch of other things I am also working on I am not going to be able to sort out every step for you (or indeed for any other user...) but I will try to provide short replies - but I am probably not going to actually try your code for you since I do not have nlopt installed and to make sense of it I would need to invest time learning about it a bit nore than I can cope with right now. However you can find the implementation of the CSL foreign function scheme in trunk/csl/cslbase/fns1.c - and when you look you will see that the code is pretty grotty. The calls to aerror() are where it has found something it dislikes and your diagnostic comes from one of those. What you return does not include enough to see if you have set up nlopt_version!* happily but if that had failed to deliver a proper encapsulated entrypoint that would explain things. If you can see ways that the code could produce diagnostics that you would expect to be more helpful by all means make and test them locally for yourself and then send them in for consideration... > First, I don't really know where the 'int32, etc. are coming from. > I.e., how does Reduce or CSL know about them? See the comments in fns1.c and these names stand for raw C-level data representation. > I am just imitating what > is in gurobi.red. Second, what about the fact that in the real C > function these are pointers to ints, not actual ints? That is a calamity for you in that what is being passed is the value of each of the arguments you try to pass as a 32-bit integer - so major, minor and bugfix are expected to have small integer values when you call-foreign-function, which they do not, and if the nlopt code you call treats those as pointers it will try to write to the memory addresses they point to. Having the foreign code overwrite bits of stuff in the Lisp world would be dangerous at a level where really only a system expert should even consider it! So the foreign function interface can only get back results as the "honest" results from the functions it calls. So you presumably need to write your own C-coded shim that gets invoked from Lisp, decodes and packages the arguments that nlopt will want, calls nlopt and then returns one of the very limited sorts of value that can be passed back. Eg along the lines of int32_t get_nlopt_version() { int maj, min, bug; printf("I got here\n"); fflush(stdout); // to help debug NLOPT_LD_MMA(&maj, &min, &bug); // If this is how it goes! printf("version into = %d %d %d\n", maj, min, bug); fflush(stdout); return ((maj & 0xff)<<16) | ((min & 0xff)<<8) | (bug & 0xff); } so that it is as EASY as possible for the Lisp to interface to. Observe that I layer print statements in this so that once I get the scripts that make my DLL set up I and manage my very first foreign function call I am in a position to trace and hence debug everything. > Perhaps there is some other code I should be looking at for guidance? > > Kostas > ```
 Re: [Reduce-algebra-developers] interface to NLopt, 0-th step From: Kostas Oikonomou - 2014-06-05 22:12:09 ```Dear Arthur, Thanks, I can test quite easily in the way you suggest. But it seems that I'm missing something: 5* in ""nlopt.red" .... 6* {v1,v2,v3} := nlopt_version(); +++ Error bad args for call-foreign-function So I must be doing something wrong in these lines from nlopt.red: % NLOPT_EXTERN(void) nlopt_version(int *major, int *minor, int *bugfix); call!-foreign!-function(nlopt_version!*, 'int32, major, 'int32, minor, 'int32, bugfix); First, I don't really know where the 'int32, etc. are coming from. I.e., how does Reduce or CSL know about them? I am just imitating what is in gurobi.red. Second, what about the fact that in the real C function these are pointers to ints, not actual ints? Perhaps there is some other code I should be looking at for guidance? Kostas On 06/05/2014 09:06, Arthur Norman wrote: >> module nlopt; >> >> #if (memq 'csl lispsystem!*) >> >> fluid '(nlopt_lib!*); > ... >> endmodule; % nlopt >> >> My question for the moment is: how do I test this with CSL Reduce? Do I >> have to put this file in packages/foreign/nlopt/ and rebuild Reduce? >> Since I >> am going to be adding more functions and doing repeated testing, I would >> like to avoid having to rebuild Reduce every time. > > ```
 Re: [Reduce-algebra-developers] interface to NLopt, 0-th step From: Arthur Norman - 2014-06-05 13:06:50 ```> module nlopt; > > #if (memq 'csl lispsystem!*) > > fluid '(nlopt_lib!*); ... > endmodule;  % nlopt > > My question for the moment is: how do I test this with CSL Reduce?  Do I > have to put this file in packages/foreign/nlopt/ and rebuild Reduce? Since I > am going to be adding more functions and doing repeated testing, I would > like to avoid having to rebuild Reduce every time. For initial testing I would tend to comment out the "module" and "endmodule" statements and put "symbolic;" at the head of the file and "end;" at the end. Then I would start up Reduce from the directory I had my file in and just go in "nlopt.red"; % or whatever file I had put it in. which should load in the code you have and you can then test it. IN fact I would often put some of my test case in that file so that in "nlopt.red"; both read in the code and tried the first few tests. That is liable to be reasonable while your code is short and to get you off the ground. As you indicate, you could gradually move to having the code in your own copy of the Reduce tree so rebuilding the whole would build it. In cases like that I would then have development scripts that go lisp spool "logfile.log"; on echo,backtrace; lisp; load_package nlopt; % Now my latest patches and updates... symbolic procedure new_version_of_whatever a; ... % And some test cases... algebraic; end; or something a BIT like that, so that the new module of code I am working on goes in a single file short enough to build on top of the stuff I already built in the major system rebuild. Others may have different patters of work that they like instead... I do not view what I do as The One True Way at all - it is just what works for me. Arthur ```
 [Reduce-algebra-developers] interface to NLopt, 0-th step From: Kostas Oikonomou - 2014-06-05 12:51:35 Attachments: Message as HTML ```I have cleared some of my confusion w.r.t. Lisp vs. Scheme vs. C "foreign" interfaces, and I am taking the 0th step in an interface of Reduce to the NLopt package. So far, I have in a file "nlopt.red" the following: ------------------------------------------------------------------------ module nlopt; #if (memq 'csl lispsystem!*) fluid '(nlopt_lib!*); fluid '(nlopt_version!*); fluid '(nlopt_ld_mma!*); % patterned after packages/foreign/gurobi/gurobi.red: nlopt_lib!* := open!-foreign!-library "/opt/nlopt/lib/libnlopt.so"; % nlopt_lib!* := lto_sconcat {rltools_trunk(), "packages/foreign/nlopt/libnlopt.so"}; nlopt_version := find!-foreign!-function("nlopt_version", nlopt_lib!*); nlopt_ld_mma := find!-foreign!-function("NLOPT_LD_MMA", nlopt_lib!*); procedure nlopt_version(); begin scalar major,minor,bugfix; % NLOPT_EXTERN(void) nlopt_version(int *major, int *minor, int *bugfix); call!-foreign!-function(nlopt_version!*, 'int32, major, 'int32, minor, 'int32, bugfix); return {major,minor,bugfix}; end; procedure nlopt_ld_mma(); begin % call!-foreign!-function(nlopt_ld_mma!*, ...) end; #endif endmodule; % nlopt ------------------------------------------------------------------------ Here I am attempting just to test the NLopt "nlopt_version" routine. If anyone wants to comment on this, point out problems, etc, I would be happy to hear. My question for the moment is: how do I test this with CSL Reduce? Do I have to put this file in packages/foreign/nlopt/ and rebuild Reduce? Since I am going to be adding more functions and doing repeated testing, I would like to avoid having to rebuild Reduce every time. Kostas ```

Showing 9 results of 9