numexp-discuss — mailing list to discuss numexp implementation

[NumExp] gnumexp branch moved location

[Gustavo J. A. M. C. <gj...@in...>]

I moved the main gnumexp branch to launchpad, as a hosted team branch.
See https://code.launchpad.net/~numexp/gnumexp/trunk

This means that anyone in the NumExp launchpad team can read and write
to that branch now.


P.S.: for numexp team members, do not listen to the launchpad advice and
use the bzr+ssh URL for downloading/pulling the branch, not just upload,
as it is faster.

-- 
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
"The universe is always one step beyond logic" -- Frank Herbert

[NumExp] numexp-core-0.17 released

[David B. <bo...@wa...>]

Hi the list !

After 9 months of work, here is the last version of the
numexp-core.

Overview of changes in numexp-core 0.17
=======================================

* Expressions' simplification : Simplification does trivial things
now. The goal is not to expand or factorize all an expression but just
see very simple things. A simplification must be done fast.

Also, we have the 'expand' function that expands an
expression, and we always have the 'factor' function. This last one
works only with expressions of one variable, I hope to fix that in a
near future.

* Functions : the mpfr library is used in NumExp for a moment now, but
many functions were not updated to use it. Now, at less if arguments
are real, functions use the mpfr library.

Tests on function's arguments are also improved, if a function needs a
vector of reals as argument, we cannot give to it a vector of complexes
or something else.

* gsl functions : We have new functions for numerical integration
imported from the gsl library.

* Matrices: Error management is improved in the matrices files.

Enjoy !

David.

[NumExp] Changes in NumExp

[David B. <bo...@wa...>]

Hi Alberto, Gustavo, ... and all the list !

I continue to work on my new branch. I want to tell you my changes and
have your feedback.

There are 4 points, the last is surely the more important.

1. The tree.

The NxpElementTree is no more a binary tree, now. Its structure looks
like the function's one. So, the sum 2+x+y+2z is not a big tree of
trees but just one tree. All the arguments are stored in a list.

We can now do three things with trees :

* simplify them : the simplification is not total. The goal is to
simplify trivial things like a+0, a^1, x+3x, etc... Don't expect the
simplify function to expand an expression. This way, NumExp works
faster. The simplification works now like the derivation, we have a
hash table, keys are operators and values are the correspondant
functions. In fact, it works with +, -, /, * and ^...

The code needs cleaning, but works.

* expand them : if you want to expand (a+b)^2, you just have to enter
expand[(a+b)^2], the function transforms the tree (a+b)^2 in a sparse
multivariate polynomial, then this last one is converted back to a tree
which is the result. The interest to work with the polynomial is that
computations are really faster than if we work directly with
NxpElements. You can expect to expand (a+b+c+2)^200.

* factorize them : At the moment, only univariate polynomials can be
factorized. This will change when all that I expose here will work. The
tree entered in the function is transformed to an univariate
polynomial. We factorize it and then we transform it back to a tree.

2. New directory algebra.

Polynomials are now in the kernel/algebra directory. They are not
NxpElement. They work more like mpfr/gmp numbers. At the beginning
their coefficients were just integers, but that didn't really work. So
I changed that for multivariate polynomials. But I didn't want to work
with NxpElement for numbers. So I created a wrapper to gmp/mpfr numbers.
So we have a NxpNb structure that works correctly even if it needs some
work again.

Univariate polynomials work always only with integers just because I
didn't need them with other coefficients. But this could change later.

3. Numbers.

Now that I have NxpNb structure, I changed all the different types
NxpElementInt, NxpElementFrac, NxpElementReal into one.

struct _NxpElementR {
	NxpElementNumber parent;
	NxpNb *value;
};

We always have nxp_element_int_new, nxp_element_frac_new, etc..., but
they creates a new nxp_element_r element.

It's possible that I change NxpElementComplex into

struct _NxpElementComplex {
	NxpElementNumber parent;
	NxpNb *re;
	NxpNb *im;
}

Then calculus in the complex.c file would be easier to read. But I'm
not sure.

4. Functions.

Maybe this is the biggest change.

I wanted to have the possibility to define a function like this in
NumExp :

gcd(a:POLYNOMIAL, b:POLYNOMIAL, x:VARIABLE):=[
	BLABLA
]

But I needed to be able to test the type of each argument.

So, I decided to change the prototype management.

This is what we entered before to define a builtin function:
nxp_bifunc_define_global("igcd", &nxp_prototype__INT_INT, &eval,
&derive, &simp);

This needed that nxp_prototype__INT_INT already exists.

So now, we enter :

nxp_bifunc_define_global("igcd[INT,INT]", &eval, &derive, &simp);

A new function nxp_proto_get_proto_full(name, &new_name); is called in
nxp_bifunc_define_global that returns what I call a NxpProto :

struct _NxpProto {
    int	    arity;
    GSList *eval_proto;
    GSList *derive_proto;
    GSList *simp_proto;
};

If the proto doesn't exist, it is created and otherwise, the already
existing proto is returned.

When we evaluate igcd(4, 6)

All the function with the name igcd are taken.

Then, for each, we compare the arguments' types needed
with the ones given.

This comparison is done like this :

The function gives a NxpProto.

The list of eval_proto in this NxpProto is a list of functions, the
first one tests the type of the first argument, the second one tests
the type of the second argument...

With igcd, the first function tests if 4 is an integer, then if 6 is
an integer too.

A test function does something like this :

if the given element x is of type INT, return REF(x)
else y= eval(x) and if x is of type INT return y
else unref(y)
return NULL

So a NULL returned value tells that the argument is bad, else we have a
pointer to the good value.

If we create a new module which contains new
elements, we can add a test function for those new elements easily :

nxp_proto_add_tester("PERMUTATION", eval, simp);

eval tests the argument if we evaluate the function, and simp tests the
argument if we simplify the function.

When, we have found the good function to execute, the arguments are
also in the good form in a list {4, 6}.

Then, the eval function asks for the C function corresponding to igcd.

The arguments cannot be given like before, so we cannot execute the
following function :

nxp_bifunc_igcd(NxpElement *a, NxpElement *b, ETC);

but we can execute this one :

nxp_bifunc_igcd(NxpElementList *args, ETC);
where args is the list {4, 6} in our example.


So, what do we win ?

PRO
- The structure is dynamical, even with user-functions, we will be able
to test types of arguments.
- The code is smaller, before we had a function to test INT_INT
that was two times the same test, and we also had INT_INT_INT, etc...
Each prototypes had to be know in advance.
- We can ask for type that are not NxpElement types. For example, if we
want to create functions that work only with prime numbers, we can
imagine a test function for PRIME and then we can create a new function
with primes.

CONS
- When we have nxp_bifunc_igcd(NxpElementInt *a, NxpElementInt *b, ETC),
we know that this function needs two arguments that are integers. With 
nxp_bifunc_igcd(NxpElementList *args, ETC); it's not in the name of the
function, but we can tell this in the commentary introducing the
function.
- I don't see others.


All this is in my branch. Things about factorization of expressions
don't work for now because of those so many changes.

I also know my code must be reorganised and cleaned a little, but ideas
are there...


So now, you can criticize all this, don't be too angry !! ;-)

Cheers.
David.

Re: [NumExp] Question about the svn repository

[David B. <bo...@wa...>]

Le Thu, 08 Nov 2007 09:55:43 +0000,
Alberto Manuel Brand=C3=A3o Sim=C3=B5es <al...@al...> a =
=C3=A9crit :

>=20
>=20
> David Boucher wrote:
>=20
> > After googling a lot, I found people with the same difficulty on
> > SVNForum.org, the answer was :
> > * create trunks
> > * create branches
> > * create tags
> > * move all the files and directories to trunk
> >=20
> > So it's done (after hesitations).
> >=20
> > Now, for people who wants to work with the svn version, you have to
> > enter
> >=20
> > svn co  https://numexp.org/svn/numexp-core/trunk numexp-core
> >=20
> > instead of
> >=20
> > svn co  https://numexp.org/svn/numexp-core/
> >=20
> > But, in a short time, we'll have also a very experimental version in
> > the branches directory.
>=20
>=20
> I'll update the webpage info soon

Thanks. The wiki is already updated about that but it could be good to
update also the download page. :-)

Re: [NumExp] Question about the svn repository

[Gustavo J. A. M. C. <gj...@in...>]

On Thu, 2007-11-08 at 00:54 +0100, David Boucher wrote:
> Le Wed, 7 Nov 2007 22:01:20 +0100,
> David Boucher <bo...@wa...> a écrit :
> 
> > Hi,
> > 
> > After asking the question to Alberto, he proposed me to ask it to the
> > list, just because Gustavo surely knows the answer :-)
> > 
> > I would like to have branches on the svn repository. It's not because
> > I want a new gadget but because I made many changes to the
> > numexp-core. Those big changes need other big changes, that need
> > other big ones...
> > 
> > So, my last version is very unstable and I don't want to commit it
> > directly.
> > 
> > My method at the moment is to play with many directories of the
> > numexp-core, but it becomes difficult to work with them.
> > 
> > So, if I could have a development branch, it would be simpler for
> > me. :-)... I think.
> > 
> > So, Gustavo, please, could you point us to a solution ? :-)
> > 
> > Thanks.
> > David.
> 
> After googling a lot, I found people with the same difficulty on
> SVNForum.org, the answer was :
> * create trunks
> * create branches
> * create tags
> * move all the files and directories to trunk

Of course using a DVCS is even better than that ;-)  The problem with
subversion is that creating branches is easy, but merging them back to
trunk is not so easy...

-- 
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
"The universe is always one step beyond logic" -- Frank Herbert

Re: [NumExp] Question about the svn repository

[<al...@al...>]

David Boucher wrote:

> After googling a lot, I found people with the same difficulty on
> SVNForum.org, the answer was :
> * create trunks
> * create branches
> * create tags
> * move all the files and directories to trunk
> 
> So it's done (after hesitations).
> 
> Now, for people who wants to work with the svn version, you have to
> enter
> 
> svn co  https://numexp.org/svn/numexp-core/trunk numexp-core
> 
> instead of
> 
> svn co  https://numexp.org/svn/numexp-core/
> 
> But, in a short time, we'll have also a very experimental version in
> the branches directory.


I'll update the webpage info soon
-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
                  Campus de Gualtar - 4710-057 Braga - Portugal

Re: [NumExp] Question about the svn repository

[David B. <bo...@wa...>]

Le Wed, 7 Nov 2007 22:01:20 +0100,
David Boucher <bo...@wa...> a =C3=A9crit :

> Hi,
>=20
> After asking the question to Alberto, he proposed me to ask it to the
> list, just because Gustavo surely knows the answer :-)
>=20
> I would like to have branches on the svn repository. It's not because
> I want a new gadget but because I made many changes to the
> numexp-core. Those big changes need other big changes, that need
> other big ones...
>=20
> So, my last version is very unstable and I don't want to commit it
> directly.
>=20
> My method at the moment is to play with many directories of the
> numexp-core, but it becomes difficult to work with them.
>=20
> So, if I could have a development branch, it would be simpler for
> me. :-)... I think.
>=20
> So, Gustavo, please, could you point us to a solution ? :-)
>=20
> Thanks.
> David.

After googling a lot, I found people with the same difficulty on
SVNForum.org, the answer was :
* create trunks
* create branches
* create tags
* move all the files and directories to trunk

So it's done (after hesitations).

Now, for people who wants to work with the svn version, you have to
enter

svn co  https://numexp.org/svn/numexp-core/trunk numexp-core

instead of

svn co  https://numexp.org/svn/numexp-core/

But, in a short time, we'll have also a very experimental version in
the branches directory.

Cheers.
David.

[NumExp] Question about the svn repository

[David B. <bo...@wa...>]

Hi,

After asking the question to Alberto, he proposed me to ask it to the
list, just because Gustavo surely knows the answer :-)

I would like to have branches on the svn repository. It's not because I
want a new gadget but because I made many changes to the numexp-core.
Those big changes need other big changes, that need other big ones...

So, my last version is very unstable and I don't want to commit it
directly.

My method at the moment is to play with many directories of the
numexp-core, but it becomes difficult to work with them.

So, if I could have a development branch, it would be simpler for
me. :-)... I think.

So, Gustavo, please, could you point us to a solution ? :-)

Thanks.
David.

[NumExp] numexp-core 0.16.1 released

[<al...@al...>]

Thanks do David, a new set of releases for numexp-core.
Unfortunately I forgot to send an email during 0.16.0 release, so I 
include here both change logs:

Overview of changes in numexp-core 0.16.1
=========================================
  - Debugging comments removed.
  - Some Memory leaks fixed.
  - Bugs fixed in mathml relative to sqrt and to product between numbers.
  - Integers factorization works better, we can factorize negative integers.
  - sqrt works well with integers, sqrt[12] gives 2sqrt[3].
    Beautiful under gnumexp :-)

Overview of changes in numexp-core 0.16.0
=========================================
  - New integer factorization function (ifactor)
  - New arithmetic functions:
         igcd, ilcm, nextPrime, isPrime



Ok, now, go and get it.
Cheers
Alberto

-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
                  Campus de Gualtar - 4710-057 Braga - Portugal

   If you have the technical capability to complain about the docs,
   you have the technical ability to improve those docs.

Re: [NumExp-discuss] numexp> a b == a*b

[Jon Roadley-B. <jon...@gm...>]

ok thanks (updating my bookmark for the homepage)
will knock together the ebuilds and host at my site and if I have time sort
out a layman wrapper until I can convince a gentoo-dev to drop the ebuilds
into the sinrise feed, meeting with some gentoo dev's next weekend so will
discuss with them

On 07/07/07, Alberto Sim=F5es <al...@al...> wrote:
>
> Hi.
>
> Thanks for pointing it out. We made a redirect from the index.html file,
> but forgot to do the same thing for other pages.
>
> Please check our new webpage at
> http://numexp.org  (and http://numexp.org/downs.html).
>
> Thank you
> Alberto
>
> Jon Roadley-Battin wrote:
> > Seem's as this project isn't dead I thought I would go and sort out the
> > ebuild's for the most recent version (I had to stop back when GNOME-2.1=
6
> > was abt to come out).
> >
> > It seems some of the source at the download page (
> > http://numexp.sourceforge.net/downs.html) are missing
> > Libnxplot & xhtml-mathml-dtd are no longer reverenced with the provided
> > url's
> >
> >
> >
> >
> > -----------------------------------------------------------------------=
-
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> >
> >
> > -----------------------------------------------------------------------=
-
> >
> > _______________________________________________
> > Numexp-discuss mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numexp-discuss
>
> --
> Alberto Sim=F5es - Departamento de Inform=E1tica - Universidade do Minho
>                   Campus de Gualtar - 4710-057 Braga - Portugal
>

Re: [NumExp-discuss] numexp> a b == a*b

[<al...@al...>]

Hi.

Thanks for pointing it out. We made a redirect from the index.html file, 
but forgot to do the same thing for other pages.

Please check our new webpage at
http://numexp.org  (and http://numexp.org/downs.html).

Thank you
Alberto

Jon Roadley-Battin wrote:
> Seem's as this project isn't dead I thought I would go and sort out the 
> ebuild's for the most recent version (I had to stop back when GNOME-2.16 
> was abt to come out).
> 
> It seems some of the source at the download page ( 
> http://numexp.sourceforge.net/downs.html) are missing
> Libnxplot & xhtml-mathml-dtd are no longer reverenced with the provided 
> url's
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Numexp-discuss mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numexp-discuss

-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
                  Campus de Gualtar - 4710-057 Braga - Portugal

Re: [NumExp-discuss] numexp> a b == a*b

[Jon Roadley-B. <jon...@gm...>]

Seem's as this project isn't dead I thought I would go and sort out the
ebuild's for the most recent version (I had to stop back when GNOME-2.16 was
abt to come out).

It seems some of the source at the download page (
http://numexp.sourceforge.net/downs.html) are missing
Libnxplot & xhtml-mathml-dtd are no longer reverenced with the provided
url's

Re: [NumExp-discuss] numexp> a b == a*b

[Gustavo J. A. M. C. <gj...@in...>]

On Qua, 2007-06-13 at 10:20 +0200, David Boucher wrote:
> Hi,
> 
> We are near of a new release of NumExp. Not all is on the svn
> repository because of a last difficulty that should be fixed before
> this week end.
> 
> This mail is just to have your idea on different things.
> 
> The parser works now almost the same as Mathematica's one.
> The product doesn't need any * now. So, a b and a*b are equivalent.
> The grammar has no conflict but I had to change little things.
> 
> 
> 
> 1. I come back on the functions' call.
> 
> At the moment, if I enter x(2+x), it is understood as x*(2+x), also x
> (x+2) tells the same thing.
> 
> Gustavo, you wanted that sin(x) is a function call. With the new
> parser, I can propose this :
> 
> f(x) calls the function f with the argument x
> 
> and f (x) is the product of f by x.

  But, IMHO, a single space having such a big impact on the expression
is kind of dangerous.

  I don't know if this is easy or not, but if I was designing the
language from scratch I'd make f(x) == f (x) == { f*x, if f is variable;
f[x] if f is function;}.

  Of course that would imply overloading of variables and functions with
the same name would not be allowed anymore.  And would imply that the
decision of whether to call function or multiply to be shifted from
parse time to eval time.

  Anyway, just an idea; no idea if it is easy to implement, though.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [NumExp-discuss] numexp> a b == a*b

[<al...@al...>]

Hi.

David Boucher wrote:

> 1. I come back on the functions' call.
> 
> At the moment, if I enter x(2+x), it is understood as x*(2+x), also x
> (x+2) tells the same thing.
> 
> Gustavo, you wanted that sin(x) is a function call. With the new
> parser, I can propose this :
> 
> f(x) calls the function f with the argument x
> 
> and f (x) is the product of f by x.
> 
> This needs one more line in the parser grammar, so not difficult to
> implement.
> 
> To forbid f (x) as a product would be more difficult for me (and I'm
> lazy to work on the parser...).

Seems ok, for me.

> 2. Alberto, we discussed on things that don't work with the actual
> parser.
> 
> 3{1, 2, 3} gives the result {3, 6, 9} and the idea of 3{0} cannot be
> implemented. When we talked about that, there was a big error (I didn't
> know about it...) in the parser around product precedence. This error
> is solved but I lost this little grammar.
> 
> At the moment, I have the function fill[3, 0] that returns {0, 0, 0}.
> 
> I wanted to replace 3{0} by 3#{0}, but it generates many conflicts in
> the grammar just because #{vector} returns the size of the vector and
> 3#{vector} by default returns 3 times the size of the vector. So,
> conflict with 3#{0} which ask for something different.

I think to maintain the fill and not add too much syntax is a good idea.

> 3. I have also a difficulty with matrices. It is because of the product
> again.
> 
> What's the sense of |1|2|3| ?
> 
> Is it one matrix with one item equal to 1*|2|*3, which is |6| ? So we
> get ||6||.
> 
> Or is it |1| * 2 * |3|, that is |6| ?
> 
> The problem is that we cannot distinguish inside and outside of a
> matrix.
> 
> To solve this, are you agree me to change || by {} ?
> 
> It needs {2, 3} to be a single row matrix and also a vector, but this
> doesn't seem problematic.
> 
> A second possibility is to remove the element matrix from NumExp and
> consider that a matrix is just a vector of vectors. Mathematica works
> like this. Maple is near of this idea too.

The only reason I like |...| is for multiple lines:
|1,2,3;4,5,6;7,8,9|

But if we change for
{1,2,3;4,5,6;7,8,9}
it seems nice as well.

I know we can write
{{1,2,3},{4,5,6},{7,8,9}},
but it has too much syntax.

> 4. I don't want to start a new war between i or j for the complex
> sqrt(-1)
> 
> But when I make a loop, my counter is very often i or j. So, could we
> change i/j by I/J ?

I understand your motivation but I think to maintain i and j is better.
But if Gustavo agrees to change, no problem with me ;)


> 5. I wanted the range operator to be .. instead of ...
> 
> And the product makes it difficult.
> 
> Here is an example 3..::a ,  is it 3 * (..::a) or 3 .. (::a) ?
> 
> So we have again ... for the range operator.
> 
> But we have another possibility, we could have 3..::a that is
> 3 * (..::a) and if we really want the range, we could enter 3.. ::a
> 
> So if .. and :: are separated by a space we have the range operator and
> if they are concatenated, they make part of the variable.

Ok, now I remember why I used '...' and not '..'
I think it is better to have really different symbols to remove confusions.


Cheers
Alberto
-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
                  Campus de Gualtar - 4710-057 Braga - Portugal

[NumExp-discuss] numexp> a b == a*b

[David B. <bo...@wa...>]

Hi,

We are near of a new release of NumExp. Not all is on the svn
repository because of a last difficulty that should be fixed before
this week end.

This mail is just to have your idea on different things.

The parser works now almost the same as Mathematica's one.
The product doesn't need any * now. So, a b and a*b are equivalent.
The grammar has no conflict but I had to change little things.



1. I come back on the functions' call.

At the moment, if I enter x(2+x), it is understood as x*(2+x), also x
(x+2) tells the same thing.

Gustavo, you wanted that sin(x) is a function call. With the new
parser, I can propose this :

f(x) calls the function f with the argument x

and f (x) is the product of f by x.

This needs one more line in the parser grammar, so not difficult to
implement.

To forbid f (x) as a product would be more difficult for me (and I'm
lazy to work on the parser...).



2. Alberto, we discussed on things that don't work with the actual
parser.

3{1, 2, 3} gives the result {3, 6, 9} and the idea of 3{0} cannot be
implemented. When we talked about that, there was a big error (I didn't
know about it...) in the parser around product precedence. This error
is solved but I lost this little grammar.

At the moment, I have the function fill[3, 0] that returns {0, 0, 0}.

I wanted to replace 3{0} by 3#{0}, but it generates many conflicts in
the grammar just because #{vector} returns the size of the vector and
3#{vector} by default returns 3 times the size of the vector. So,
conflict with 3#{0} which ask for something different.



3. I have also a difficulty with matrices. It is because of the product
again.

What's the sense of |1|2|3| ?

Is it one matrix with one item equal to 1*|2|*3, which is |6| ? So we
get ||6||.

Or is it |1| * 2 * |3|, that is |6| ?

The problem is that we cannot distinguish inside and outside of a
matrix.

To solve this, are you agree me to change || by {} ?

It needs {2, 3} to be a single row matrix and also a vector, but this
doesn't seem problematic.

A second possibility is to remove the element matrix from NumExp and
consider that a matrix is just a vector of vectors. Mathematica works
like this. Maple is near of this idea too.




4. I don't want to start a new war between i or j for the complex
sqrt(-1)

But when I make a loop, my counter is very often i or j. So, could we
change i/j by I/J ?




5. I wanted the range operator to be .. instead of ...

And the product makes it difficult.

Here is an example 3..::a ,  is it 3 * (..::a) or 3 .. (::a) ?

So we have again ... for the range operator.

But we have another possibility, we could have 3..::a that is
3 * (..::a) and if we really want the range, we could enter 3.. ::a

So if .. and :: are separated by a space we have the range operator and
if they are concatenated, they make part of the variable.



I hope my english is not too difficult to read. I wait for your ideas.

Cheers.
David.

Re: [NumExp-discuss] gnumexp devel status report

[Gustavo J. A. M. C. <gj...@in...>]

  I have installed a bzr web interface[1].  With it you can checkout a
tarball, browse the repo, and subscribe an RSS feed of commits.

  Cheers.

[1] http://telecom.inescporto.pt/~gjc/bzr/bazaar-webserve-dir.cgi

Ter, 2006-06-06 =C3=A0s 21:44 +0100, Gustavo J. A. M. Carneiro escreveu:
>   Just a little status report on gnumexp... :-)
>=20
>   Since almost a week ago gnumexp (in my bzr branch, not in sourceforge)
> is in the following state:
>=20
>    - Uses gtk.UIManager instead of bonobo.ui for menus and toolbars;  It
> still uses gnome.ui for option parsing and gnomevfs, so it still depends
> on gnome-python.  I'll probably make gnome-python dependency optional
> when I have nothing more interesting to do :P
>    - The console runs and works like before, though xygraph doesn't;
>    - console help now uses a cairo-based renderer, and embeds widgets
> instead of pixbufs [1] =3D> no more libnxplot dependency;
>    - gnumexp now includes its own copy of pymathml =3D> no more pymathml
> dep;
>    - gnumexp now includes its own private copy of the mathml 2.0 2nd
> edition DTD, which is registered in runtime for gnumexp use only =3D> no
> more mathml DTD dep;
>    - There's a new dependency on gnome-doc-utils; however, this is a
> standard GNOME dependency now, so should cause no problems.
>=20
>   Next step is to port xygraph over to use cairo.  I'm planning to use
> goocanvas, so I'll take a detour to help finish goocanvas python
> bindings.  When it's ready, I'll probably put goocanvas plus python
> bindings inside gnumexp, to avoid external dependencies.  Anyway, a lot
> of work is ahead of me. :P
>=20
>   Cheers.
>=20
> [1] regretably, that is a bit slower, maybe later i'll switch back to
> pixbufs if a suitable cairo.ImageSurface -> gdk.Pixbuf API becomes
> available.
>=20
--=20
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
The universe is always one step beyond logic

[NumExp-discuss] gnumexp devel status report

[Gustavo J. A. M. C. <gj...@in...>]

  Just a little status report on gnumexp... :-)

  Since almost a week ago gnumexp (in my bzr branch, not in sourceforge)
is in the following state:

   - Uses gtk.UIManager instead of bonobo.ui for menus and toolbars;  It
still uses gnome.ui for option parsing and gnomevfs, so it still depends
on gnome-python.  I'll probably make gnome-python dependency optional
when I have nothing more interesting to do :P
   - The console runs and works like before, though xygraph doesn't;
   - console help now uses a cairo-based renderer, and embeds widgets
instead of pixbufs [1] =3D> no more libnxplot dependency;
   - gnumexp now includes its own copy of pymathml =3D> no more pymathml
dep;
   - gnumexp now includes its own private copy of the mathml 2.0 2nd
edition DTD, which is registered in runtime for gnumexp use only =3D> no
more mathml DTD dep;
   - There's a new dependency on gnome-doc-utils; however, this is a
standard GNOME dependency now, so should cause no problems.

  Next step is to port xygraph over to use cairo.  I'm planning to use
goocanvas, so I'll take a detour to help finish goocanvas python
bindings.  When it's ready, I'll probably put goocanvas plus python
bindings inside gnumexp, to avoid external dependencies.  Anyway, a lot
of work is ahead of me. :P

  Cheers.

[1] regretably, that is a bit slower, maybe later i'll switch back to
pixbufs if a suitable cairo.ImageSurface -> gdk.Pixbuf API becomes
available.

--=20
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
The universe is always one step beyond logic

[NumExp-discuss] Numexp advancement

[David B. <bo...@wa...>]

Hi,

I should finish the implementation of one variable polynomials'
factorization in a few days. The last algorithm is made and I must test
it now. All that algorithm is not a very high level algorithm, we can do
much better but this first one works (only for polynomials with
coefficients in Q) and that's not so bad. So don't expect to factorize
polynomials of degree 300 in less than 1 second :-)

The code is not commited yet, to many bugs at the moment... Maybe a
first version tomorrow on cvs, but I'm not sure.

My next step will be to reduce the size of my code, many things are here
to debug the factorization. But then,...


In your opinion, what's the next piece of numexp-core should I work on ?
Is factorization of multivariate polynomials a good idea ? Or do you
think there are things much more important before...

Cheers.
David.

Re: [NumExp-discuss] gnumexp and numexp-kernel

[Gustavo J. A. M. C. <gj...@in...>]

On Seg, 2006-02-13 at 13:19 +0000, Jon Roadley-Battin wrote:
> Is it the plan to migrate the GUI to GTK-2.10 when it comes out? 
> and take full advantage of Cairo vectoring for graphics?
> 
> I might not be able to help with the kernel of numexp (I'm just an
> engineer) but if the GUI is coded in PYTHON (which from what I have
> seen it is, I should be able to help out there. 
> 
> Also looking at the dependancies there is a libnxplot, this seems a
> specific module custom-written for numexp for the soul purpose of
> plotting?

  libnxplot is a more modern replacement for GNU libplot.  It predates
Cairo.  The idea is to drop nxplot and use Cairo, once Cairo has decent
printing support.  At the moment, Cairo isn't ready for printing.

> have you looked into the matplotlib python module, it is extreamly
> flexable and powerful and if you are familiar with matlab they have
> done a very good job of making hte python-code used by matlibplot
> matlab-like 

  gNumExp plotting code also predates matplotlib.  We are pioneers in
some respects (see also our pioneering mathml renderer) ;-)

  I'd look at matplotlib if I didn't have tons of other things to do
first :P

  Regards,

-- 
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
The universe is always one step beyond logic.

Re: [NumExp-discuss] gnumexp and numexp-kernel

[Jon Roadley-B. <jon...@gm...>]

Is it the plan to migrate the GUI to GTK-2.10 when it comes out?
and take full advantage of Cairo vectoring for graphics?

I might not be able to help with the kernel of numexp (I'm just an engineer=
)
but if the GUI is coded in PYTHON (which from what I have seen it is, I
should be able to help out there.

Also looking at the dependancies there is a libnxplot, this seems a specifi=
c
module custom-written for numexp for the soul purpose of plotting?
have you looked into the matplotlib python module, it is extreamly flexable
and powerful and if you are familiar with matlab they have done a very good
job of making hte python-code used by matlibplot matlab-like

it can be interfaced with GTK as well



On 13/02/06, Gustavo J. A. M. Carneiro <gj...@in...> wrote:
>
> On Mon, 2006-02-13 at 11:42 +0100, David Boucher wrote:
> > Hi Gustavo,
> >
> > I think you are the best to answer this question :-)
> >
> > When I launch gnumexp and then exit.
> >
> > I always have numexp-kernel running in the background. That does not
> > happen with numexp-client.
> >
> > I have seen that the Numexp-Kernel object is referenced two times when =
I
> > lauch gnumexp. But when I close it, it is unreferenced only one time.
> >
> > Do you know how to fix it ?
>
>   Find the kernel.py module, add a function shutdown() that does "global
> kernel; kernel.unref(); kernel =3D None"
>
>   In the gnumexp 'shell', import kernel, and call kernel.shutdown()
> where gtk.main_quit() is called.
>
> PS: sorry I haven't been paying attention to gnumexp lately; I promise
> to have another go when gtk+ 2.10 comes out, with cairo PDF support and
> a print dialog.
>
> --
> Gustavo J. A. M. Carneiro
> <gj...@in...> <gu...@us...>
> The universe is always one step beyond logic.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numexp-discuss mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numexp-discuss
>

Re: [NumExp-discuss] gnumexp and numexp-kernel

[Gustavo J. A. M. C. <gj...@in...>]

On Mon, 2006-02-13 at 11:42 +0100, David Boucher wrote:
> Hi Gustavo,
> 
> I think you are the best to answer this question :-)
> 
> When I launch gnumexp and then exit.
> 
> I always have numexp-kernel running in the background. That does not
> happen with numexp-client.
> 
> I have seen that the Numexp-Kernel object is referenced two times when I
> lauch gnumexp. But when I close it, it is unreferenced only one time.
> 
> Do you know how to fix it ?

  Find the kernel.py module, add a function shutdown() that does "global
kernel; kernel.unref(); kernel = None"

  In the gnumexp 'shell', import kernel, and call kernel.shutdown()
where gtk.main_quit() is called.

PS: sorry I haven't been paying attention to gnumexp lately; I promise
to have another go when gtk+ 2.10 comes out, with cairo PDF support and
a print dialog.

-- 
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
The universe is always one step beyond logic.

[NumExp-discuss] gnumexp and numexp-kernel

[David B. <bo...@wa...>]

Hi Gustavo,

I think you are the best to answer this question :-)

When I launch gnumexp and then exit.

I always have numexp-kernel running in the background. That does not
happen with numexp-client.

I have seen that the Numexp-Kernel object is referenced two times when I
lauch gnumexp. But when I close it, it is unreferenced only one time.

Do you know how to fix it ?

Thanks.
Regards.

David.

Re: [NumExp-discuss] News about numexp-core

[Jon Roadley-B. <jon...@gm...>]

OK sorted. It seems the Gentoo Devs changed the polarity of the "Have_NPTL"
function from "1" to "0"  (this is in Portage 2)
I guess it is because NPTL usage is becoming more and more widespread

I have stweaked the detection to explicity check if the NPTL use flag is se=
t

Numexp-core compiles fine

Only other problem is with compiling gNumexp
It fails at it testing for the presence of python-nxplot

Now a "import nxplot" at a python prompt works so it is installed fine and
is fisible to python.
Looking at gNumexp config.log it seems for some reason the configuration
script at the python-nxplot stage is trying to connect to the Xserver



configure:21988: result: -Wl,--export-dynamic -pthread -lORBit-2 -lm -
lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0
configure:22026: checking for python module nxplot
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

configure:22056: result: no
configure:22058: error: libnxplot python module not found





Gentoo (if you do not use it) compiles things in a sandbox to ensure that
something being built does not interfere with the main system. The only
thing I can think of is since ./configure is trying to connect to the
Xserver (for some reason) sandbox stops it.

I am going to write a patch file (specific for Gentoo) to basically change
the PYTHON test so it doesnt try to import nxplot. Now since that section i=
s
there to ensure dependancy's are present, in patching out that test I will
rely on Portage to ensure that Libnxplot is ensure and since libnxplot is a
dependacy of gNumexp, gNumexp will not start to emerge unless libnxplot is
installed. thus taking care of the dependancy issue


Will write the patch and check the ebuilds then I will upload my portage
overlay to my ISP webspace bore for tackling the Gentoo-devs

@ David* yer I do have amd64 in the ebuilds, I just forgot what the arch
label was when I sent the last email*

Re: [NumExp-discuss] News about numexp-core

[David B. <bo...@wa...>]

Hi Jon,

I use a Gentoo box too ( :-) )
So my config.log looks like yours...

Le vendredi 10 f=C3=A9vrier 2006 =C3=A0 22:01 +0000, Jon Roadley-Battin a=
 =C3=A9crit :
> Hi thanks,=20
> If I can get this sorted and can easily emerge stuff I can push on
> with getting this into Portage as well as seeing if I can help
> I have uploaded the cofig.log to my ISP server-space.
>=20
> http://fluidmotion.pwp.blueyonder.co.uk/config.log
>=20
> From it it seems that configure cannot find DB4, yet it is saved in
> the default (Gentoo default) place.
> The includes are located at:
>=20
> /usr/include/db4.2=20
>=20
> with /usr/include/db.h  being a symlink to /usr/include/db4.2/db.h
> I actually made a symlink to db4.2 called just db4 in /usr/include to
> see if that was the problem (no joy).
>=20

At the db4 check, there are 2 steps.
1- numexp-core searches for the /usr/include/db4/db.h but if it doesn't
find it,...
2- it searches for /usr/include/db.h

So I can see on your config.log you made the symlink to db4.2

I don't think the problem is there..

On my box, the first test fails. But the second one is good. So you can
remove your link... :-)

On your config.log, the little C testing program is compiled but it
hurts on that :

configure:23892: i686-pc-linux-gnu-gcc -o conftest -O3 -march=3Dpentium4
-fforce-addr -pipe -fomit-frame-pointer    conftest.c  /usr/lib/libdb.a
>&5
/usr/lib/libdb.a(mut_pthread.o): In function
`__db_pthread_mutex_init_4002':
mut_pthread.c:(.text+0x8c): undefined reference to
`pthread_mutexattr_destroy'
mut_pthread.c:(.text+0x173): undefined reference to
`pthread_condattr_setpshared'
mut_pthread.c:(.text+0x18e): undefined reference to
`pthread_mutexattr_init'
mut_pthread.c:(.text+0x1b1): undefined reference to
`pthread_mutexattr_setpshared'
/usr/lib/libdb.a(mut_pthread.o): In function
`__db_pthread_mutex_lock_4002':
mut_pthread.c:(.text+0x1f9): undefined reference to
`pthread_mutex_trylock'

You can find those functions in /usr/include/pthread.h or the files
called from this one.

On my box, all them come with the glibc...

You said you added ~x64 ~ppc to KEYWORDS.
Shouldn't it be ~amd64 ~ppc ? I have no knowledge about ebuild files,
but I can see amd64 more often than x64. (maybe I'm wrong... ;-))

I hope all this will help you... :-)

Tell us.

Regards
David.

Re: [NumExp-discuss] News about numexp-core

[Gustavo J. A. M. C. <gj...@in...>]

  I can see that it find the db.h header file, but is failing to find
libdbxxx.a:

     1. First it tries /usr/lib/libdb-4.1.a: No such file or directory;
     2. Then, /usr/lib/libdb4.a: No such file or directory;
     3. Finally, /usr/lib/libdb.a:

configure:23892: i686-pc-linux-gnu-gcc -o conftest -O3 -march=pentium4 -fforce-addr -pipe -fomit-frame-pointer    conftest.c  /usr/lib/libdb.a >&5
/usr/lib/libdb.a(mut_pthread.o): In function `__db_pthread_mutex_init_4002':
mut_pthread.c:(.text+0x8c): undefined reference to `pthread_mutexattr_destroy'
mut_pthread.c:(.text+0x173): undefined reference to `pthread_condattr_setpshared'
mut_pthread.c:(.text+0x18e): undefined reference to `pthread_mutexattr_init'
mut_pthread.c:(.text+0x1b1): undefined reference to `pthread_mutexattr_setpshared'
/usr/lib/libdb.a(mut_pthread.o): In function `__db_pthread_mutex_lock_4002':
mut_pthread.c:(.text+0x1f9): undefined reference to `pthread_mutex_trylock'
collect2: ld returned 1 exit status

  Conclusion: libdb.a is the only one that exists, but it uses pthreads,
so we need to add -pthread to CFLAGS around the test.  A temporary hack,
just to prove that it works (or not), is for you to run configure like
this:
	CFLAGS='-g -O2 -pthread' ./configure

  If you confirm that it works, we'll let Alberto or David take care of
it for the next release :-)

  Regards.

On Fri, 2006-02-10 at 22:01 +0000, Jon Roadley-Battin wrote:
> Hi thanks, 
> If I can get this sorted and can easily emerge stuff I can push on
> with getting this into Portage as well as seeing if I can help
> I have uploaded the cofig.log to my ISP server-space.
> 
> http://fluidmotion.pwp.blueyonder.co.uk/config.log
> 
> From it it seems that configure cannot find DB4, yet it is saved in
> the default (Gentoo default) place.
> The includes are located at:
> 
> /usr/include/db4.2 
> 
> with /usr/include/db.h  being a symlink to /usr/include/db4.2/db.h
> I actually made a symlink to db4.2 called just db4 in /usr/include to
> see if that was the problem (no joy).
> 
> The actualy libs are located in /usr/lib and are called libdb-4.2.a as
> well as .la and .so (so c++ libs as well to do with DB4)
> All in all the DB seem to be in the correct place, and
> numexp-core-0.10 compiles fine, same DB used as well
> 
> 
> Thanks
> 
> 
> On 10/02/06, Gustavo J. A. M. Carneiro <gj...@in...> wrote: 
>           If you check (or mail us) your config.log, it might help
>         figure out
>         why it is failing.
>         
>           Regards.
>         
>         On Fri, 2006-02-10 at 18:29 +0000, Jon Roadley-Battin wrote:
>         > I am having a bit of a problem with compileing Numexp-Core 
>         >
>         > I am updating my EBUILD's to the latest version as well as
>         adding ~x64
>         > and ~ppc but compiling numexp-core-0.12 fails on the db4
>         tests.
>         >
>         > Now the last version I had worked on was 0.10 and that went
>         fine, it
>         > required db4.1.24 or greater (at the time I had 4.2.52)
>         >
>         > Now I missed out numexp-core-0.11 since gnumexp required
>         some
>         > GNOME2.10 stuff (well 2.9) and I was still on 2.8 so didn't
>         bother.
>         >
>         > With finding this project still alive I thought I better
>         update by
>         > ebuilds and resubmit to the Gentoo devs.
>         >
>         > This is where I fail
>         >
>         >
>         >
>         >
>         > --- Checking DB4 Library
>         > checking for db4 compiler flags... -I/usr/lib/include
>         > checking db4/db.h usability... yes
>         > checking db4/db.h presence... yes
>         > checking for db4/db.h... yes
>         > checking db4 header version... 4.1.24
>         > checking for db4 library name... configure: error: Could not
>         find db4
>         > library
>         >
>         >
>         >
>         > Funny thing is I do not have db-4.1.24 on my system
>         >
>         >
>         > Fluid numexp-core-0.12.0 # emerge -C db -vp
>         >
>         > >>> These are the packages that I would unmerge:
>         >
>         >  sys-libs/db
>         >     selected: 1.85-r2 4.2.52_p2-r1
>         >    protected: none
>         >      omitted: none
>         >
>         > >>> 'Selected' packages are slated for removal.
>         > >>> 'Protected' and 'omitted' packages will not be removed.
>         >
>         >
>         >
>         > So as you can see from this I have DB-1.85 (for legacy
>         progs) and
>         > DB-4.2.52.
>         > Eqaully looking at the include file in /usr/include it is
>         just a
>         > symlink to /usr/include/db4.2/db.h
>         > Even a GREP through all the headers didn't even come up with
>         anything 
>         > with DB-4.1.24 in it???
>         >
>         >
>         > There seems to be something wring in the configure script. I
>         don't
>         > know what it is atm, will play around with it to hopefully
>         fix
>         >
>         > Jon RB
>         --
>         Gustavo J. A. M. Carneiro
>         <gj...@in...> <gu...@us...>
>         The universe is always one step beyond logic. 
>         
> 
-- 
Gustavo J. A. M. Carneiro
<gj...@in...> <gu...@us...>
The universe is always one step beyond logic