Hi Laurent,

On Sat, 12 Mar 2005 14:46:28 +0100, Laurent Godard <[EMAIL PROTECTED]> wrote:
...
> > I'm pretty much done with the dialog portion of it.  What I'm working
> > on right now is transforming user-supplied data into the standard form
> > of linear model.  This is probably the most difficult part in my
> > estimate.  Once that is done, I will start porting my optimization
> > algorithms from Python to C++.
> >
> 
> Kohei, this sounds great
> Why do you want to change from Python to C++
> Performance ?

Actually I'm just porting the algorithm portion of it.  The UI part is
written in C++ from the beginning.

>Using python for both UNO-UI and calculation could be
> great. All deployed as an addin/addon in one language

That's true.  But at this point, the majority of the UI code is
already in C++, so it makes little sense to switch entirely to Python.
 Plus I am more experienced with making a C++ UNO component than doing
so in Python.

> IMHO, rapidity is not a so great issue. When doing non linear numerical
> analysis i expect it may take some time (if i don't know that, i don't
> use non linear numerical analysis).

I see your point.  But when all the competing programs (lp_solve,
OPT++, Excel Solver etc.) are written in C/C++, why necessarily make
it slower by introducing an extra layer (the Python interpreter). 
Besides, I just feel that C++ is the right tool when an algorithm
involves heavy use of matrix calculations, because there is already
the boost ublas library for matrix operations.  That's difinately an
advantage there.

> So, what are the calculation times involved and what is the gain
> expected to switch to C++ ? From 1 second to 1/100 second for a 1000 dof
> (degres of freedom) problem ? I personnaly don't care ....

Since I haven't done any official benchmark on my solver component, I
can't give you any concrete numbers yet (I'm not that far on this
project).  But I'll do some benchmark when I get a chance.  The
difficulty may be in coming up with a feasible test case with 1000 or
more variables, but I'll worry about that later. ;-)

> For your trials and errors on OOo API with python, i can suggest having
> a look at pyXRay
> http://www.indesko.com/sites/en/downloads/pyxray___a_tool_for/view

Nice.  Thanks for the info. :-)  That looks like a very cool tool.

Anyway, thanks for your compliment, Laurent.  Comments like that is
what drives me forward. :-)

Best regards,

Kohei

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to