GSL interface is half-done (ok, 1/3 done) but the test-suite has only 5 tests done at the moment.

We need to finish to import the integration.

Just three functions are not done (April 26, 2008)

The last functions to implement are not essential, we have a sufficient number of functions to make numerical integration. The difficulty with the lacking functions is that they need tables and I don't really see how I could implement this to stay relatively simple. Maybe, I must use them in a precise case… don't know.

This was asked, so we must do it.

This will be done later, except if one asks for particular functions

Many polynomials we want to factor are very particular ones and they are easy to factor. Knowing this, we can improve the polynomials factorization algorithm.

* The Eisenstein criterion is a good idea to execute before a factorization.

This should be easy to implement since we have a direct access to integers' factorization.

* All the polynomials of the form

are easy to factorize, we can do particular things for them. See http://en.wikipedia.org/wiki/Root_of_unity

The reconstitution of factors after Hensel's lifting is a basic algorithm for now. We can improve it by implementing the Knapsack algorithm.

At the moment, NumExp can only factor univariate polynomials. So, the multivariate case rests to be done !

We have this problem :

numexp> 0.3
ans = 0.29999999999999999
numexp> 0.1
ans = 0.10000000000000001

It should not be so difficult to correct those problems.

We can already : * simplify automatically an expression :

gives

or

just returns

* expand an expression

gives

* factorize an expression

gives

What we need to implement now is factorization for multivariate expressions, for example:

should return

Also, we don't have a real simplification function :

It would be good if :

gives

and

gives

This function would return the shortest form it can compute. There's another good example that should be simplified a lot :

should return 6.

Also, we could have things like this:

gives 1.

Here, the function uses a table of known things about functions.

This example is interesting too :

and simpler than the previous ones. But at the moment, nothing is done to simplify this.

In NumExp, we can define different versions of the same function but with different arguments. So, in theory it is possible to define a function factor for integers and a function factor for polynomials.

In the mean time, the NumExp developers did not define this function like this, the problem is the following : we can see a number (different than 0) as a polynomial of degree 0. So what version of the function should be used ?

For this function, the problem is not so big, but it exists.

Also, we have the following situation, an end user could define a function for two polynomials. But this function won't work for other arguments. It could be a good thing to be able to test the type of the arguments.

Instead of defining the function like this :

f[a, b]:=...

we could imagine the following definition :

f[a:POLYNOMIAL, b:POLYNOMIAL]:=...

Then, when we call this function f, NumExp tries to typecast the two arguments to have two polynomials.

If two functions are defined with the same name, say we also have

f[a:POLYNOMIAL, b:INTEGER]:=...

With a call of f like the following :

f[x^2+2x-3, 5]

NumExp can't know what definition of f to use. It'll return an error.

In that case, the end user can enter :

f[x^2+2x-3, 5:INTEGER]

to solve the ambiguity.

The bad thing: a such definition makes conflicts. A block of instructions is particular function called :, so a:POLYNOMIAL could be seen as the product of a, : and POLYNOMIAL. Too bad

Another thing interesting, we could imagine to define a function of one variable x only if x is positive or only if x is a prime number ; and the previous way to give the type is not very good.

So, at the moment, the idea is to use a new function with.

So instead of defining f[x:INTEGER]:=2x+3, the idea is to enter with x in INTEGERS do f[x]:=2x+3

The definition is longuer but works better.

We can also make something like this, with x>0 and y>0 do f[x, y]:=sqrt[x]-sqrt[y]

People often cannot compile numex-kernel that depends on libbonobo.

A possibility is to change the numexp-kernel from libbonobo to dbus.

This is almost done now and you can try it with the actual svn version.

The only difficulty is with graphics, at the moment there is a limitation in DBus and we cannot send through it a big structure containing all the points of a complicated curve. So we must change how curves are drawn in NumExp. I try to describe the changes I want in the next section.

I think a good improvement would be NumExp to be able to draw directly from the server and not like at the moment, that is to say the gnumexp client asks for a tabular of points and draws them. If we have a graphic element in the kernel, this would be helpful to draw also histograms or other things and we can imagine other outputs than the screen, why not having a postscript output or other…

The algorithm of functions plotting can also be improved, I realized this with a function like . If we want to plot this one for x in [-2;2], there are many points computed when x arrives near zero.

It would also be good to have graphics directly inside the gnumexp console, but I'll see this later.