ojalgo-user — For ojAlgo users

Re: [ojAlgo-user] Question/Issue

[Anders P. <an...@op...>]

The intention is that BigFunction, ComplexFunction and  
PrimitiveFunction should have matching sets of members and that  
implementations should be specific to their type.

Currently BigFunction implementations have taken a shortcut. Fixing  
this, generally, is not high priority.

Is there something in particular causing you problems?

Also; in the future most (all) BigFunction, ComplexFunction and  
PrimitiveFunction members should be org.ojalgo.function.Function  
instances.

/Anders

On 31 maj 2006, at 20.01, David H. Clements wrote:

> First of all, great library, I really appreciate the work that has  
> been put
> into this.
>
> A question:
>
> In the BigFunction package everything returns BigDecimals, but it is
> converted as an intermediary step into a double, which loses the  
> fidelity of
> using a BigDecimal to start with.  Are there any plans to rewrite  
> these so
> that they maintain BigDecimal fidelity?
>
> Sincerely,
> David H. Clements
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and  
> Risk!
> Fully trained technicians. The highest number of Red Hat  
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user

[ojAlgo-user] Question/Issue

[David H. C. <dcl...@21...>]

First of all, great library, I really appreciate the work that has been put
into this.

A question:

In the BigFunction package everything returns BigDecimals, but it is
converted as an intermediary step into a double, which loses the fidelity of
using a BigDecimal to start with.  Are there any plans to rewrite these so
that they maintain BigDecimal fidelity?

Sincerely,
David H. Clements

[ojAlgo-user] ANN: V.ersion 10

[Anders P. <an...@oj...>]

Version 10 is available for download at SourceForge.

Mainly worked on MatrixStore and MatrixDecomposition. They=92ve been =20
generized and a rather large number of (surprisingly serious) =20
problems have been fixed. The problems mainly had to do with matrix =20
multiplication for LogicalStore and extracting matrices (the parts) =20
from decompositions.

Currently there are NO junit tests that fail!

All users who are using Java 5 are strongly recommended to switch to =20
this latest version as soon as possible.

If you=92re not using Java 5 you have to stick to version 8.

/Anders=

[ojAlgo-user] ANN: Version 9

[Anders P. <an...@oj...>]

This release is for Java 5 (1.5) only. If you're not using Java 5 you  
should stick to version 8.

Things have changed. This release is not a drop in replacement for  
earlier releases - that's normal with ojAlgo. This time there are  
more than usual changes. The BasicMatrix interface is unchanged! I  
assume that's important information for many users. Things that have  
changed include:

1) The array classes have been significantly refactored.
2) BigUtils, PrimitiveUtils and ComplexUtils have been split up in  
org.ojalgo.constant.* and org.ojago.function.*
3) The JFreeChart extensions has been removed.
4) The default matrix implementation for DefaultFactory is now  
PrimitiveMatrix. It used to be BigMatrix.
5) A few things I already forgot about...

Note: The BasicMatrix interface is unchanged, and if you're not using  
Java 5 you should stick to version 8.

Please report any problems you may have to this list.

/Anders

[ojAlgo-user] ANN: Version 8

[Anders P. <an...@oj...>]

 From now on all future development will target Java 5.0. This  
release is simply a snapshot of HEAD just before any Java 5.0  
specific features are added.

There is now also a branch in CVS - NO_TIGER - that could be used for  
future fixes to this release.

Let me know if there are any problems.

/Anders

[ojAlgo-user] Info on future releases

[Anders P. <an...@oj...>]

As of some, yet undetermined, date early next year future development  
of ojAlgo will make use of Java 1.5 features. There will be a "last"  
pre 1.5 release, and a branch for future bug fixes of that release.

/Anders

[ojAlgo-user] Re: quadratic programming problem

[Anders P. <an...@oj...>]

Hi,

I understand (now) that using the ojAlgo optimisation models is not  
trivial. I'll see if I can improve the docs for the next version.

Using the QP-solver without the models should be straight forward...

The few lines of documentation in

http://ojalgo.org/generated/org/ojalgo/optimisation/qp/ 
GenericQPSolver.html

should be enough.

1) Just build your matrixes
2) Instantiate an ActiveSetSolver
3) Call solve();

/Anders
________________________________________
an...@oj...
http://ojalgo.org/

Anders Peterson
ojAlgo c/o Optimatika
Torstenssonsgatan 12, 5tr.
114 56 Stockholm
Sweden

[ojAlgo-user] New release

[Anders P. <an...@oj...>]

Released version 7.

Fixed a few bugs...

/Anders

[ojAlgo-user] Re: Quadratic Programming

[Anders P. <and...@op...>]

Are you trying to use the solvers with or without a model?

Look at the source for:

1) org.ojalgo.optimisation.qp.GenericQPSolver. (Read the docs on the 
class and the constructors. Just realized that this is not included in 
the generated JavaDoc since this class is package private.)

2) The unit tests in the org.ojalgo.optimisation.qp package.

3) The org.ojalgo.application.PortfolioOptimiser class. (Just added 
this. You'll have to get it from CVS.)

Please direct furher questions to the mailing list.

/Anders

sione wrote:
> 
> Hi Anders,
> 
> Is there any example of how to use  the "Quadratic Programming" package
> for solving optimization problem ?  I try to read and read the latest 
> version
> of how to use it but I still have no clue as to how to use it, such as 
> inputing
> objective function, decision variables, constraint , etc ?
> 
> Any hint would be appreciated.
> 
> Thanks,
> Sione.

-- 
http://ojalgo.org/

Mathematics, Linear Algebra and Optimisation with Java

[ojAlgo-user] New release

[Anders P. <an...@oj...>]

Version 6 has been released!

/Anders

[ojAlgo-user] Info about upcoming versions

[Anders P. <an...@oj...>]

Hi,

There has been a lot of changes and additions made to ojAlgo lately.  
Among other things there are now 6 different BasicMatrix  
implementations, 3 of which are native to ojAlgo. (The other 3 are  
facades to Colt, Jama and Jampack.)

A few more things remain to be done before there will be a new  
release. If you are not already a "CVS user" I recommend you become  
one. Get the latest source code from CVS, take it for a spin, and  
please give me feedback.

The next release will (probably) be later this summer. Chances are  
that that will be the last release before switching to Java 1.5. As  
soon as it is possible for Optimatika to switch (all) development to  
Java we will, and when we do we want to make use of its specific  
features. This will affect ojAlgo.

/Anders

[ojAlgo-user] Re: Performance comparison

[Wolfgang H. <who...@lb...>]

>
> I didn't expect you to know anything about ojAlgo. I'll refrase the 
> question: Is there any reason why you ask people to consider VectMath 
> and not Jama?
>

The linear algebra algorithms in Colt are an adapted version of Jama's 
algorithms.

[ojAlgo-user] Re: Performance comparison

[Anders P. <and...@op...>]

Wolfgang Hoschek wrote:

>> Why do you recommend VecMath over Jama, Jampack, Jakarta or my own  
>> ojAlgo?
>
> Just to clarify: I never said Colt was slow/bad, and yes the tests  
> were done using small matrices.
>
> "Consider" does not mean "recommend".
> Plus, I have expressed no opinion either way on your project.

I didn't expect you to know anything about ojAlgo. I'll refrase the 
question: Is there any reason why you ask people to consider VectMath 
and not Jama?

>
>> I just rewrote the tests to work with randomly generated matrices of  
>> arbitrary size. These are the numbers for 100x100 dimension matrices  
>> looping 10 times.
>
>
> Total execution time is too small for this to be a meaningful 
> benchmark  with real-world relevance.
> There are lots of gotchas when benchmarking with hotspot engines. To  
> get some background, try to attend a talk from hotspot engineers when  
> you get a chance. Here one such talk "how not to write a  
> microbenchmark"  
> http://servlet.java.sun.com/javaone/sf2002/conf/sessions/display 
> -1816.en.jsp

Just running the test on Windows instead of on Mac gives different 
execution time relations/proprotions.

There are other problems... Is exploiting characteristics of a specific 
implementation cheating? Both BigMatrix and ColtMatrix are very fast at 
transposing matrices, but that's because they´re not actually moving the 
numbers.

>
>> Working with BigDecimal rather than double gives you unmatched  
>> precision (not speed).
>
> Which is what few use cases need in practise, at least in my experience.

I needed it once. That's why ojAlgo exists. Currently I can switch 
between 4 implementations with different characteristics (speed, 
precision, complex numbers...)

/Anders
http://ojalgo.org/

> Anyway, enjoy your project.
>
> Wolfgang.

[ojAlgo-user] Performance comparison

[Anders P. <and...@op...>]

Hi,

I've begun implementing performance comparison tests between Colt, Jama, 
Jampack and a matrix implementation that I've made (based on BigDecimal 
elements).

So far only a few tests exists, but the results were not what I expected.

http://ojalgo.org/generated/comparison.xml

If you want to know what the tests actually do you need to look at the 
source code.

What I have is facades to the Colt/Jama/Jampack packages (one class 
each) implementing a common matrix interface. This will, of course, 
never utilize the full potential of the individual packages. In addition 
I am certain the facade implementations can be improved. Perhaps you'd 
like to help with that. ;-)

All the current tests are using (very) small matrices, which I assume 
does not favour Colt.

Jampack works with complex numbers, but none of the tests use complex 
numbers (since none of the other implementations can handle that).

I can't explain/describe everything here. If you're interested please 
have a look at: http://ojalgo.org/
You need to work from CVS. The downloads at Source Forge do not contain 
the comparison tests.

If you want to discuss these tests it's probably best done at: 
oja...@li...

I'm very interested in getting tests that represent (your) real-life use 
of matrices.

/Anders

[ojAlgo-user] ANN: v5

[Anders P. <an...@we...>]

I've released version 5.

Current users should upgrade when they have time to investigate the 
changes.

There is a new array package: org.ojalgo.array.*

replacing the earlier array classes.

Post questions and feedback to this list.

/Anders

[ojAlgo-user] Maths collaboration

[Martin-M. <si...@di...>]

Hi,


I am part of a group of people at JScience.org trying to build a general 
scientific package. I contact you as an author and primary source of 
information concerning the implementation of maths algorithms for the Java 
platform and wondered if you would like to join or review our work.

Thanks a lot.

Cheers,

Silvere Martin

PS: you can check the lastest version of our work at 
http://www.digitalbiosphere.com/jsciencepackages.zip


__________________________________________________________________________________________

Silvere Martin-Michiellot builds the Internet future on 
www.digitalbiosphere.com
__________________________________________________________________________________________

[ojAlgo-user] ANN: v4

[Anders P. <and...@op...>]

Version 4 of ojAlgo is available at SourceForge.

The main "news" is that the unit tests are fixed. Currently only two 
tests fail. One is a problem with calculating a Singular Value 
Decomposition for matrices with more columns than rows (fat matrices). 
The other is a numerical problem in calculating/comparing the inverse 
of a matrix between the three different matrix implementations.

In addition the QP solvers are confirmed to function with either of the 
three matrix implementations, and optimisation problems can now be 
generated using a lightweight modelling framework.

I frequently refactor substantial parts of the code. To make sure the 
functionality you use continue to work you are recommended to supply me 
with JUnit test cases.

/Anders

[ojAlgo-user] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[ojAlgo-user] Released v3

[Anders P. <and...@op...>]

No new features. Just refactoring and bug fixes. /Anders

Re: [ojAlgo-user] Questions

[Anders P. <and...@op...>]

On 2004-04-21, at 18.21, Inger, Matthew wrote:

> Actually 2 things
> 	1.  I've noticed that the .solve method returns slightly =
different
>           results than our algorithm

I tried this yesterday, and there were a few bugs in the BigMatrix =20
implementation of the QR decomposition - I fixed those yesterday. =20
Please try this again with the latest version from CVS.

I'm surprised you you only got a slightly different solution ;-)

> 	2.  Using "solve" instead produces no speed gain, as I'm caching =
the
>           majority of the matrix computations:

Since you=B4re caching almost everything, and in the end only work with  =
=20
2-by-2 matrices, I assume you may be close to optimum performance. In =20=

general, with larger matrices, your way is not the better way!

> This is the formula we're using:
>
>         B =3D (Xt * X)i * (Xt * Y)

This is one way of solving X*B =3D Y (I prefer to write A*X=3DB) when =
there =20
are more equations than variables. It gives you the least squares =20
solution.

Another way, almost the same, is:

X =3D A.mulyiplyLeft(A.transpose()).solve(B.mulyiplyLeft(A.transpose()))
Internally the solve method delegates to the matrix' LU decomposition.

And a third way, that I recommend, is:

X =3D A.solve(B)
Internally the solve method now delegates to the matrix' QR =20
decomposition. This will give you the least squares solution directly, =20=

and in most cases will be much faster than what you are doing! =20
(Provided that you are reusing A).

If/when you tried this you did not get correct answers because the code =20=

had bugs.

You can even try this with JamaMatrix....

> (t is transpose and i is inverse).
>
> Since the X value is the same, when we construct the
> cached X matrix, we also construct Xt and (Xt * X)i
> and cache those as well.
>
> Then i only have to do two matrix calculations, one for
> the (Xt * Y) and then again to multiply that by the inverse
> of the square I stored earlier.
>
> Most, if not all values are non-zero.

Nothing to do then...

> At this point, i'm just chalking it up to BigDecimal construction
> being time consuming (it takes ~ 25% of the total execution time), and
> then the "add" method on BigDecimal takes another 25% of the time.

/Anders

> -----Original Message-----
> From: Anders Peterson [mailto:and...@op...]
> Sent: Wednesday, April 21, 2004 11:31 AM
> To: Inger, Matthew
> Cc: 'oja...@li...'
> Subject: Re: [ojAlgo-user] Questions
>
>
> There are a couple of things you can try...
>
> 1) Basically what you want to do is solve a linear equation system =
with
> far more rows than columns: Ax=3DB
>
> Is your current strategy to calculate A.transpose() and multiplying
> both sides of the equation with this?
>
> There is another way. Simply call A.solve(B)
>
> Not sure I tested this, but it should produce the same result! =
Provided
> you use the same A for each of the 10000 iterations the heavy
> "processing" is cached for you (A internally stores its QR
> decomposition).
>
> 2) Perhaps you can reduce the number of BigDecimal calls. When you=B4re
> doing matrix multiplication; do the matrices involved have a lot of
> zeros? If they do, then implementing multiplication code in one or =
more
> of the MatrixStore subclasses may speed things up.
>
>
> Have to leave the office now - live in a different time zone,
> /Anders
>
> On 2004-04-21, at 17.06, Inger, Matthew wrote:
>
>> Yes, that kind of pattern for factories is very commonly
>> used.  You could still have the implementation you supplied
>> which is a generic Reflection based strategy, but when you're
>> dealing with thousands, or millions of records, every little
>> bit counts.
>>
>> 1.  I'm processing 10,000 records
>> 2.  The X values are the same for every iteration
>>
>> Using this, i created a Solver class which caches the X matrix,
>> along with it's transpose, and a couple of other computed matrices
>> (such as Xt * X) which do not involve the Y values.  And i'm also
>> caching the Unit matrix.
>>
>> So each iteration through the loop, only the Y values have to be set,
>> and i've minimized the number of matrix operations required to =
compute
>> the coefficients.
>>
>> After running this, i trimmed run time from 8s to 5s, and noticed =
that
>> 75% of the time is spent in the BigDecimal class, with about 1/3 of
>> that
>> spent in the constructor, and 1/3 in the "timesTenToThe" method.  So
>> there's
>> really nothing further i can do to speed it up.
>>
>>
>> -----Original Message-----
>> From: Anders Peterson [mailto:and...@op...]
>> Sent: Wednesday, April 21, 2004 11:01 AM
>> To: Anders Peterson
>> Cc: Inger, Matthew; 'oja...@li...'
>> Subject: Re: [ojAlgo-user] Questions
>>
>>
>> This is done! It's in CVS.
>>
>> Please let me know if it faster.
>>
>> /Anders
>>
>> On 2004-04-21, at 11.41, Anders Peterson wrote:
>>
>>> In my previous mail it should read "It will speed things up..." ;-)
>>>
>>> On 2004-04-20, at 14.57, Inger, Matthew wrote:
>>>
>>>> The basic slowdown is that the constructors are not cached.
>>>> Finding the constructor each time is what makes that factory
>>>> slow.
>>>
>>> I understand! Do you know of any reason why MatrixFactory should not
>>> cache the constructors?
>>>
>>>> If MatrixFactory was an interface, one could just call
>>>> the appropriate constructurs directly without reflection.
>>>>
>>>> public interface MatrixFactory {
>>>>    public BasicMatrix create(double values[][]);
>>>> }
>>>>
>>>> public class BigMatrixFactory implements MatrixFactory {
>>>>   public BasicMatrix create(double values[][]) {
>>>>      return new BigMatrix(values);
>>>>   }
>>>> }
>>>>
>>>> You could still have the original vresion, but it would
>>>> be named something different, and implement this new interface.
>>>
>>> Ok, I see what you mean. Is that a commonly used design pattern for
>>> factories?
>>>
>>>> -----Original Message-----
>>>> From: Anders Peterson [mailto:and...@op...]
>>>> Sent: Tuesday, April 20, 2004 4:40 AM
>>>> To: Inger, Matthew
>>>> Cc: 'oja...@li...'
>>>> Subject: Re: [ojAlgo-user] Questions
>>>>
>>>>
>>>> On 2004-04-19, at 22.39, Inger, Matthew wrote:
>>>>
>>>>> FYI:  Using MatrixFactory is also extremely slow.
>>>>> If i directly instantiate JamaMatrix for 100,000
>>>>> regressions, it takes ~ 2 seconds or so.  If i use
>>>>> MatrixFactory to instantiate, it goes up to 8 seconds.
>>>>
>>>> MatrixFactory uses reflection to call the appropriate constructor.
>>>> Using it centralises matrix creation and allows you to switch
>>>> implementation by changing one line of code - the call to the
>>>> MatrixFactory constructor. (Make sure you re-use the factory
>>>> instances.)
>>>>
>>>> This will naturally take longer than calling the constructor
>>>> directly,
>>>> but I am surprised it is that much slower.
>>>>
>>>> If this is a problem; call the constructors directly. Perhaps you
>>>> should implement your own static factory method.
>>>>
>>>>> I'm a little curious why MatrixFactory is not an interface,
>>>>> with implementations per different type of Matrix.
>>>>
>>>> Interfaces can't specify contructors.
>>>>
>>>> /Anders
>>>>
>>>>> -----Original Message-----
>>>>> From: Inger, Matthew
>>>>> Sent: Monday, April 19, 2004 3:04 PM
>>>>> To: 'Anders Peterson'; Inger, Matthew
>>>>> Subject: RE: [ojAlgo-user] Questions
>>>>>
>>>>>
>>>>> There are a small number of variables.  In most cases, we
>>>>> have a single variable equation, and up to 24 points with
>>>>> which to fit the linear regression.
>>>>>
>>>>> Then, we do that 10,000 times.
>>>>>
>>>>> Basically, each row in the database contains time elapsed
>>>>> data (typically one value per month).  We use the # of the
>>>>> month as the x values, and the data as the y value, and try
>>>>> to fit a line to it to determine short term trends.
>>>>>
>>>>> So for each row, we calculate 1 set of coefficients (b0 and b1,
>>>>> aka intercept & slope), and make 1 more predictions.
>>>>>
>>>>> However, there are potentially millions of rows in the database.
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Anders Peterson [mailto:and...@op...]
>>>>> Sent: Monday, April 19, 2004 2:32 PM
>>>>> To: Inger, Matthew
>>>>> Subject: Re: [ojAlgo-user] Questions
>>>>>
>>>>>
>>>>> This is just a naive first attempt...
>>>>>
>>>>> On 2004-04-19, at 20.06, Inger, Matthew wrote:
>>>>>
>>>>>> PS:  As far as solving the equations, i basically have two
>>>>>> matrices.  X and Y.  Any kind of code snippet would help here.
>>>>>> Keep in mind, equations are of the form
>>>>>>
>>>>>> 	y =3D b0 + b1*X
>>>>>
>>>>> 1*b0 + x*b1 =3D y
>>>>>
>>>>> A*X =3D B
>>>>>
>>>>> where
>>>>>
>>>>> A:
>>>>> 1	x1
>>>>> 1	x2
>>>>> 1	x3
>>>>> ...	...
>>>>>
>>>>> B:
>>>>> y1
>>>>> y2
>>>>> y3
>>>>> ...
>>>>>
>>>>> X:
>>>>> b0
>>>>> b1
>>>>>
>>>>> X =3D A.solve(B);
>>>>>
>>>>> Are you doing this 10 000 times with a relatively small number of =20=

>>>>> x-
>>>>> and y-values or do you have 10 000 x- and y-values for each
>>>>> calculation?
>>>>>
>>>>> /Anders
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Anders Peterson [mailto:and...@op...]
>>>>>> Sent: Monday, April 19, 2004 2:02 PM
>>>>>> To: Inger, Matthew
>>>>>> Cc: 'oja...@li...'
>>>>>> Subject: Re: [ojAlgo-user] Questions
>>>>>>
>>>>>>
>>>>>> On 2004-04-19, at 18.33, Inger, Matthew wrote:
>>>>>>
>>>>>>> 1.  Have any performance tests been run with BigMatrix?
>>>>>>
>>>>>> Not really...
>>>>>>
>>>>>>>    I'm using
>>>>>>> BigMatrix to do a
>>>>>>>      LinearRegression algorithm.  I had previously been using =20=

>>>>>>> Jama
>>>>>>> directly,
>>>>>>> but our FD
>>>>>>>      department noticed a difference between the results given =
by
>>>>>>> java
>>>>>>> and
>>>>>>> the LINEST
>>>>>>>      function in Excel.  I have determined that the difference =
is
>>>>>>> DEFINATELY
>>>>>>> due to rounding
>>>>>>>      limitations in the java double primitive type.
>>>>>>>
>>>>>>>      These issues go away when i use ojAlgo library,
>>>>>>
>>>>>> That's great news to me - that is the reason I created ojAlgo!
>>>>>>
>>>>>>> however, the time
>>>>>>> required to do the
>>>>>>>      calculations increases to about 12-13x what it was using
>>>>>>> regular
>>>>>>> double
>>>>>>> calculations.
>>>>>>>
>>>>>>>      Doing 10,000 linear regressions with Jama took about .781s
>>>>>>> (according
>>>>>>> to junit), and
>>>>>>>      with BigMatrix, took 10.345s
>>>>>>
>>>>>> I wasn't aware the difference was that big. ;-)
>>>>>>
>>>>>>>      Any idea why such a hug disparity?
>>>>>>
>>>>>> Try altering the scale. A larger scale means better results, but =20=

>>>>>> it
>>>>>> takes longer. You can change a matrix' scale whenever you want -
>>>>>> the
>>>>>> new scale will be used from then on. Elements are not rounded
>>>>>> unless
>>>>>> you call enforceScale().
>>>>>>
>>>>>> Internally BigMatrix uses various decompositions for some of the
>>>>>> more
>>>>>> complex calculations. These decompositions inherit a scale from =20=

>>>>>> the
>>>>>> parent matrix. It is however not the same - it's bigger. I =
believe
>>>>>> the
>>>>>> formula is 2 * (3 + max(9, matrixScale)) and this formula is
>>>>>> evaluated
>>>>>> when the decomposition is created. After the decomposition is
>>>>>> created
>>>>>> its scale wont change even if you change the matrix' scale. The
>>>>>> scale
>>>>>> of a decomposition is never smaller than 24 (according to the =20
>>>>>> above
>>>>>> formula).
>>>>>>
>>>>>> I'm not happy with this, and have been meaning to change it.
>>>>>> Decompositions should have the same scale as its parent matrix, =20=

>>>>>> and
>>>>>> when it is changed, updated "everywhere".
>>>>>>
>>>>>> Would you prefer that?
>>>>>>
>>>>>>> 2.  Is there a way to use the solvers in OjAlg to do the linear
>>>>>>> regression?
>>>>>>> Or is that not
>>>>>>>      something that is provided?
>>>>>>
>>>>>> How are you currently doing it?
>>>>>>
>>>>>> I imagine the best way would be to simply build an =
over-determined
>>>>>> set
>>>>>> of linear equations - Ax=3DB - and call A.solve(B). Internally
>>>>>> BigMatrix
>>>>>> would then use the QR decomposition to give a least squares
>>>>>> estimation
>>>>>> of x. That would be my first attempt.
>>>>>>
>>>>>> You could use the QP solver do the same thing, but I don't see =
how
>>>>>> that
>>>>>> would simplify or improve anything.
>>>>>>
>>>>>> What version of ojAlgo are you using - v1, v2 or CVS?
>>>>>>
>>>>>> I recommend working from CVS. Unfortunately I have moved things
>>>>>> around
>>>>>> a bit in between version...
>>>>>>
>>>>>> I don't have access to a profiling tool, but I know they can be
>>>>>> very
>>>>>> useful in finding bottlenecks. If you can identify a problem,
>>>>>> and/or
>>>>>> suggest a specific improvement, I'll be happy to help you =20
>>>>>> implement
>>>>>> it.
>>>>>>
>>>>>> /Anders
>>>>>>
>>>>>>> ----------------------
>>>>>>> Matthew Inger
>>>>>>> Design Architect
>>>>>>> Synygy, Inc
>>>>>>> 610-664-7433 x7770
>>>>>>>
>>>>>>> -------------------------------------------------------
>>>>>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>>>>>> Free Linux tutorial presented by Daniel Robbins, President and =20=

>>>>>>> CEO
>>>>>>> of
>>>>>>> GenToo technologies. Learn everything from fundamentals to =
system
>>>>>>> administration.http://ads.osdn.com/?
>>>>>>> ad_id=3D1470&alloc_id=3D3638&op=3Dclick
>>>>>>> _______________________________________________
>>>>>>> ojAlgo-user mailing list
>>>>>>> ojA...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>>> Free Linux tutorial presented by Daniel Robbins, President and CEO =20=

>>>> of
>>>> GenToo technologies. Learn everything from fundamentals to system
>>>> administration.http://ads.osdn.com/?=20
>>>> ad_id=3D1470&alloc_id=3D3638&op=3Dclick
>>>> _______________________________________________
>>>> ojAlgo-user mailing list
>>>> ojA...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user

Re: [ojAlgo-user] Questions

[Anders P. <and...@op...>]

There are a couple of things you can try...

1) Basically what you want to do is solve a linear equation system with=20=

far more rows than columns: Ax=3DB

Is your current strategy to calculate A.transpose() and multiplying=20
both sides of the equation with this?

There is another way. Simply call A.solve(B)

Not sure I tested this, but it should produce the same result! Provided=20=

you use the same A for each of the 10000 iterations the heavy=20
"processing" is cached for you (A internally stores its QR=20
decomposition).

2) Perhaps you can reduce the number of BigDecimal calls. When you=B4re=20=

doing matrix multiplication; do the matrices involved have a lot of=20
zeros? If they do, then implementing multiplication code in one or more=20=

of the MatrixStore subclasses may speed things up.


Have to leave the office now - live in a different time zone,
/Anders

On 2004-04-21, at 17.06, Inger, Matthew wrote:

> Yes, that kind of pattern for factories is very commonly
> used.  You could still have the implementation you supplied
> which is a generic Reflection based strategy, but when you're
> dealing with thousands, or millions of records, every little
> bit counts.
>
> 1.  I'm processing 10,000 records
> 2.  The X values are the same for every iteration
>
> Using this, i created a Solver class which caches the X matrix,
> along with it's transpose, and a couple of other computed matrices
> (such as Xt * X) which do not involve the Y values.  And i'm also
> caching the Unit matrix.
>
> So each iteration through the loop, only the Y values have to be set,
> and i've minimized the number of matrix operations required to compute
> the coefficients.
>
> After running this, i trimmed run time from 8s to 5s, and noticed that
> 75% of the time is spent in the BigDecimal class, with about 1/3 of=20
> that
> spent in the constructor, and 1/3 in the "timesTenToThe" method.  So=20=

> there's
> really nothing further i can do to speed it up.
>
>
> -----Original Message-----
> From: Anders Peterson [mailto:and...@op...]
> Sent: Wednesday, April 21, 2004 11:01 AM
> To: Anders Peterson
> Cc: Inger, Matthew; 'oja...@li...'
> Subject: Re: [ojAlgo-user] Questions
>
>
> This is done! It's in CVS.
>
> Please let me know if it faster.
>
> /Anders
>
> On 2004-04-21, at 11.41, Anders Peterson wrote:
>
>> In my previous mail it should read "It will speed things up..." ;-)
>>
>> On 2004-04-20, at 14.57, Inger, Matthew wrote:
>>
>>> The basic slowdown is that the constructors are not cached.
>>> Finding the constructor each time is what makes that factory
>>> slow.
>>
>> I understand! Do you know of any reason why MatrixFactory should not
>> cache the constructors?
>>
>>> If MatrixFactory was an interface, one could just call
>>> the appropriate constructurs directly without reflection.
>>>
>>> public interface MatrixFactory {
>>>    public BasicMatrix create(double values[][]);
>>> }
>>>
>>> public class BigMatrixFactory implements MatrixFactory {
>>>   public BasicMatrix create(double values[][]) {
>>>      return new BigMatrix(values);
>>>   }
>>> }
>>>
>>> You could still have the original vresion, but it would
>>> be named something different, and implement this new interface.
>>
>> Ok, I see what you mean. Is that a commonly used design pattern for
>> factories?
>>
>>> -----Original Message-----
>>> From: Anders Peterson [mailto:and...@op...]
>>> Sent: Tuesday, April 20, 2004 4:40 AM
>>> To: Inger, Matthew
>>> Cc: 'oja...@li...'
>>> Subject: Re: [ojAlgo-user] Questions
>>>
>>>
>>> On 2004-04-19, at 22.39, Inger, Matthew wrote:
>>>
>>>> FYI:  Using MatrixFactory is also extremely slow.
>>>> If i directly instantiate JamaMatrix for 100,000
>>>> regressions, it takes ~ 2 seconds or so.  If i use
>>>> MatrixFactory to instantiate, it goes up to 8 seconds.
>>>
>>> MatrixFactory uses reflection to call the appropriate constructor.
>>> Using it centralises matrix creation and allows you to switch
>>> implementation by changing one line of code - the call to the
>>> MatrixFactory constructor. (Make sure you re-use the factory
>>> instances.)
>>>
>>> This will naturally take longer than calling the constructor=20
>>> directly,
>>> but I am surprised it is that much slower.
>>>
>>> If this is a problem; call the constructors directly. Perhaps you
>>> should implement your own static factory method.
>>>
>>>> I'm a little curious why MatrixFactory is not an interface,
>>>> with implementations per different type of Matrix.
>>>
>>> Interfaces can't specify contructors.
>>>
>>> /Anders
>>>
>>>> -----Original Message-----
>>>> From: Inger, Matthew
>>>> Sent: Monday, April 19, 2004 3:04 PM
>>>> To: 'Anders Peterson'; Inger, Matthew
>>>> Subject: RE: [ojAlgo-user] Questions
>>>>
>>>>
>>>> There are a small number of variables.  In most cases, we
>>>> have a single variable equation, and up to 24 points with
>>>> which to fit the linear regression.
>>>>
>>>> Then, we do that 10,000 times.
>>>>
>>>> Basically, each row in the database contains time elapsed
>>>> data (typically one value per month).  We use the # of the
>>>> month as the x values, and the data as the y value, and try
>>>> to fit a line to it to determine short term trends.
>>>>
>>>> So for each row, we calculate 1 set of coefficients (b0 and b1,
>>>> aka intercept & slope), and make 1 more predictions.
>>>>
>>>> However, there are potentially millions of rows in the database.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Anders Peterson [mailto:and...@op...]
>>>> Sent: Monday, April 19, 2004 2:32 PM
>>>> To: Inger, Matthew
>>>> Subject: Re: [ojAlgo-user] Questions
>>>>
>>>>
>>>> This is just a naive first attempt...
>>>>
>>>> On 2004-04-19, at 20.06, Inger, Matthew wrote:
>>>>
>>>>> PS:  As far as solving the equations, i basically have two
>>>>> matrices.  X and Y.  Any kind of code snippet would help here.
>>>>> Keep in mind, equations are of the form
>>>>>
>>>>> 	y =3D b0 + b1*X
>>>>
>>>> 1*b0 + x*b1 =3D y
>>>>
>>>> A*X =3D B
>>>>
>>>> where
>>>>
>>>> A:
>>>> 1	x1
>>>> 1	x2
>>>> 1	x3
>>>> ...	...
>>>>
>>>> B:
>>>> y1
>>>> y2
>>>> y3
>>>> ...
>>>>
>>>> X:
>>>> b0
>>>> b1
>>>>
>>>> X =3D A.solve(B);
>>>>
>>>> Are you doing this 10 000 times with a relatively small number of =
x-
>>>> and y-values or do you have 10 000 x- and y-values for each
>>>> calculation?
>>>>
>>>> /Anders
>>>>
>>>>> -----Original Message-----
>>>>> From: Anders Peterson [mailto:and...@op...]
>>>>> Sent: Monday, April 19, 2004 2:02 PM
>>>>> To: Inger, Matthew
>>>>> Cc: 'oja...@li...'
>>>>> Subject: Re: [ojAlgo-user] Questions
>>>>>
>>>>>
>>>>> On 2004-04-19, at 18.33, Inger, Matthew wrote:
>>>>>
>>>>>> 1.  Have any performance tests been run with BigMatrix?
>>>>>
>>>>> Not really...
>>>>>
>>>>>>    I'm using
>>>>>> BigMatrix to do a
>>>>>>      LinearRegression algorithm.  I had previously been using =
Jama
>>>>>> directly,
>>>>>> but our FD
>>>>>>      department noticed a difference between the results given by
>>>>>> java
>>>>>> and
>>>>>> the LINEST
>>>>>>      function in Excel.  I have determined that the difference is
>>>>>> DEFINATELY
>>>>>> due to rounding
>>>>>>      limitations in the java double primitive type.
>>>>>>
>>>>>>      These issues go away when i use ojAlgo library,
>>>>>
>>>>> That's great news to me - that is the reason I created ojAlgo!
>>>>>
>>>>>> however, the time
>>>>>> required to do the
>>>>>>      calculations increases to about 12-13x what it was using
>>>>>> regular
>>>>>> double
>>>>>> calculations.
>>>>>>
>>>>>>      Doing 10,000 linear regressions with Jama took about .781s
>>>>>> (according
>>>>>> to junit), and
>>>>>>      with BigMatrix, took 10.345s
>>>>>
>>>>> I wasn't aware the difference was that big. ;-)
>>>>>
>>>>>>      Any idea why such a hug disparity?
>>>>>
>>>>> Try altering the scale. A larger scale means better results, but =
it
>>>>> takes longer. You can change a matrix' scale whenever you want -=20=

>>>>> the
>>>>> new scale will be used from then on. Elements are not rounded=20
>>>>> unless
>>>>> you call enforceScale().
>>>>>
>>>>> Internally BigMatrix uses various decompositions for some of the
>>>>> more
>>>>> complex calculations. These decompositions inherit a scale from =
the
>>>>> parent matrix. It is however not the same - it's bigger. I believe
>>>>> the
>>>>> formula is 2 * (3 + max(9, matrixScale)) and this formula is
>>>>> evaluated
>>>>> when the decomposition is created. After the decomposition is
>>>>> created
>>>>> its scale wont change even if you change the matrix' scale. The
>>>>> scale
>>>>> of a decomposition is never smaller than 24 (according to the =
above
>>>>> formula).
>>>>>
>>>>> I'm not happy with this, and have been meaning to change it.
>>>>> Decompositions should have the same scale as its parent matrix, =
and
>>>>> when it is changed, updated "everywhere".
>>>>>
>>>>> Would you prefer that?
>>>>>
>>>>>> 2.  Is there a way to use the solvers in OjAlg to do the linear
>>>>>> regression?
>>>>>> Or is that not
>>>>>>      something that is provided?
>>>>>
>>>>> How are you currently doing it?
>>>>>
>>>>> I imagine the best way would be to simply build an over-determined
>>>>> set
>>>>> of linear equations - Ax=3DB - and call A.solve(B). Internally
>>>>> BigMatrix
>>>>> would then use the QR decomposition to give a least squares
>>>>> estimation
>>>>> of x. That would be my first attempt.
>>>>>
>>>>> You could use the QP solver do the same thing, but I don't see how
>>>>> that
>>>>> would simplify or improve anything.
>>>>>
>>>>> What version of ojAlgo are you using - v1, v2 or CVS?
>>>>>
>>>>> I recommend working from CVS. Unfortunately I have moved things
>>>>> around
>>>>> a bit in between version...
>>>>>
>>>>> I don't have access to a profiling tool, but I know they can be=20
>>>>> very
>>>>> useful in finding bottlenecks. If you can identify a problem,=20
>>>>> and/or
>>>>> suggest a specific improvement, I'll be happy to help you =
implement
>>>>> it.
>>>>>
>>>>> /Anders
>>>>>
>>>>>> ----------------------
>>>>>> Matthew Inger
>>>>>> Design Architect
>>>>>> Synygy, Inc
>>>>>> 610-664-7433 x7770
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>>>>> Free Linux tutorial presented by Daniel Robbins, President and =
CEO
>>>>>> of
>>>>>> GenToo technologies. Learn everything from fundamentals to system
>>>>>> administration.http://ads.osdn.com/?
>>>>>> ad_id=3D1470&alloc_id=3D3638&op=3Dclick
>>>>>> _______________________________________________
>>>>>> ojAlgo-user mailing list
>>>>>> ojA...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>> Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
>>> GenToo technologies. Learn everything from fundamentals to system
>>> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dclic=
k
>>> _______________________________________________
>>> ojAlgo-user mailing list
>>> ojA...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>>
>>
>

Re: [ojAlgo-user] Questions

[Anders P. <and...@op...>]

This is done! It's in CVS.

Please let me know if it faster.

/Anders

On 2004-04-21, at 11.41, Anders Peterson wrote:

> In my previous mail it should read "It will speed things up..." ;-)
>
> On 2004-04-20, at 14.57, Inger, Matthew wrote:
>
>> The basic slowdown is that the constructors are not cached.
>> Finding the constructor each time is what makes that factory
>> slow.
>
> I understand! Do you know of any reason why MatrixFactory should not  
> cache the constructors?
>
>> If MatrixFactory was an interface, one could just call
>> the appropriate constructurs directly without reflection.
>>
>> public interface MatrixFactory {
>>    public BasicMatrix create(double values[][]);
>> }
>>
>> public class BigMatrixFactory implements MatrixFactory {
>>   public BasicMatrix create(double values[][]) {
>>      return new BigMatrix(values);
>>   }
>> }
>>
>> You could still have the original vresion, but it would
>> be named something different, and implement this new interface.
>
> Ok, I see what you mean. Is that a commonly used design pattern for  
> factories?
>
>> -----Original Message-----
>> From: Anders Peterson [mailto:and...@op...]
>> Sent: Tuesday, April 20, 2004 4:40 AM
>> To: Inger, Matthew
>> Cc: 'oja...@li...'
>> Subject: Re: [ojAlgo-user] Questions
>>
>>
>> On 2004-04-19, at 22.39, Inger, Matthew wrote:
>>
>>> FYI:  Using MatrixFactory is also extremely slow.
>>> If i directly instantiate JamaMatrix for 100,000
>>> regressions, it takes ~ 2 seconds or so.  If i use
>>> MatrixFactory to instantiate, it goes up to 8 seconds.
>>
>> MatrixFactory uses reflection to call the appropriate constructor.
>> Using it centralises matrix creation and allows you to switch
>> implementation by changing one line of code - the call to the
>> MatrixFactory constructor. (Make sure you re-use the factory
>> instances.)
>>
>> This will naturally take longer than calling the constructor directly,
>> but I am surprised it is that much slower.
>>
>> If this is a problem; call the constructors directly. Perhaps you
>> should implement your own static factory method.
>>
>>> I'm a little curious why MatrixFactory is not an interface,
>>> with implementations per different type of Matrix.
>>
>> Interfaces can't specify contructors.
>>
>> /Anders
>>
>>> -----Original Message-----
>>> From: Inger, Matthew
>>> Sent: Monday, April 19, 2004 3:04 PM
>>> To: 'Anders Peterson'; Inger, Matthew
>>> Subject: RE: [ojAlgo-user] Questions
>>>
>>>
>>> There are a small number of variables.  In most cases, we
>>> have a single variable equation, and up to 24 points with
>>> which to fit the linear regression.
>>>
>>> Then, we do that 10,000 times.
>>>
>>> Basically, each row in the database contains time elapsed
>>> data (typically one value per month).  We use the # of the
>>> month as the x values, and the data as the y value, and try
>>> to fit a line to it to determine short term trends.
>>>
>>> So for each row, we calculate 1 set of coefficients (b0 and b1,
>>> aka intercept & slope), and make 1 more predictions.
>>>
>>> However, there are potentially millions of rows in the database.
>>>
>>>
>>> -----Original Message-----
>>> From: Anders Peterson [mailto:and...@op...]
>>> Sent: Monday, April 19, 2004 2:32 PM
>>> To: Inger, Matthew
>>> Subject: Re: [ojAlgo-user] Questions
>>>
>>>
>>> This is just a naive first attempt...
>>>
>>> On 2004-04-19, at 20.06, Inger, Matthew wrote:
>>>
>>>> PS:  As far as solving the equations, i basically have two
>>>> matrices.  X and Y.  Any kind of code snippet would help here.
>>>> Keep in mind, equations are of the form
>>>>
>>>> 	y = b0 + b1*X
>>>
>>> 1*b0 + x*b1 = y
>>>
>>> A*X = B
>>>
>>> where
>>>
>>> A:
>>> 1	x1
>>> 1	x2
>>> 1	x3
>>> ...	...
>>>
>>> B:
>>> y1
>>> y2
>>> y3
>>> ...
>>>
>>> X:
>>> b0
>>> b1
>>>
>>> X = A.solve(B);
>>>
>>> Are you doing this 10 000 times with a relatively small number of x-
>>> and y-values or do you have 10 000 x- and y-values for each
>>> calculation?
>>>
>>> /Anders
>>>
>>>> -----Original Message-----
>>>> From: Anders Peterson [mailto:and...@op...]
>>>> Sent: Monday, April 19, 2004 2:02 PM
>>>> To: Inger, Matthew
>>>> Cc: 'oja...@li...'
>>>> Subject: Re: [ojAlgo-user] Questions
>>>>
>>>>
>>>> On 2004-04-19, at 18.33, Inger, Matthew wrote:
>>>>
>>>>> 1.  Have any performance tests been run with BigMatrix?
>>>>
>>>> Not really...
>>>>
>>>>>    I'm using
>>>>> BigMatrix to do a
>>>>>      LinearRegression algorithm.  I had previously been using Jama
>>>>> directly,
>>>>> but our FD
>>>>>      department noticed a difference between the results given by
>>>>> java
>>>>> and
>>>>> the LINEST
>>>>>      function in Excel.  I have determined that the difference is
>>>>> DEFINATELY
>>>>> due to rounding
>>>>>      limitations in the java double primitive type.
>>>>>
>>>>>      These issues go away when i use ojAlgo library,
>>>>
>>>> That's great news to me - that is the reason I created ojAlgo!
>>>>
>>>>> however, the time
>>>>> required to do the
>>>>>      calculations increases to about 12-13x what it was using  
>>>>> regular
>>>>> double
>>>>> calculations.
>>>>>
>>>>>      Doing 10,000 linear regressions with Jama took about .781s
>>>>> (according
>>>>> to junit), and
>>>>>      with BigMatrix, took 10.345s
>>>>
>>>> I wasn't aware the difference was that big. ;-)
>>>>
>>>>>      Any idea why such a hug disparity?
>>>>
>>>> Try altering the scale. A larger scale means better results, but it
>>>> takes longer. You can change a matrix' scale whenever you want - the
>>>> new scale will be used from then on. Elements are not rounded unless
>>>> you call enforceScale().
>>>>
>>>> Internally BigMatrix uses various decompositions for some of the  
>>>> more
>>>> complex calculations. These decompositions inherit a scale from the
>>>> parent matrix. It is however not the same - it's bigger. I believe  
>>>> the
>>>> formula is 2 * (3 + max(9, matrixScale)) and this formula is  
>>>> evaluated
>>>> when the decomposition is created. After the decomposition is  
>>>> created
>>>> its scale wont change even if you change the matrix' scale. The  
>>>> scale
>>>> of a decomposition is never smaller than 24 (according to the above
>>>> formula).
>>>>
>>>> I'm not happy with this, and have been meaning to change it.
>>>> Decompositions should have the same scale as its parent matrix, and
>>>> when it is changed, updated "everywhere".
>>>>
>>>> Would you prefer that?
>>>>
>>>>> 2.  Is there a way to use the solvers in OjAlg to do the linear
>>>>> regression?
>>>>> Or is that not
>>>>>      something that is provided?
>>>>
>>>> How are you currently doing it?
>>>>
>>>> I imagine the best way would be to simply build an over-determined  
>>>> set
>>>> of linear equations - Ax=B - and call A.solve(B). Internally  
>>>> BigMatrix
>>>> would then use the QR decomposition to give a least squares  
>>>> estimation
>>>> of x. That would be my first attempt.
>>>>
>>>> You could use the QP solver do the same thing, but I don't see how
>>>> that
>>>> would simplify or improve anything.
>>>>
>>>> What version of ojAlgo are you using - v1, v2 or CVS?
>>>>
>>>> I recommend working from CVS. Unfortunately I have moved things  
>>>> around
>>>> a bit in between version...
>>>>
>>>> I don't have access to a profiling tool, but I know they can be very
>>>> useful in finding bottlenecks. If you can identify a problem, and/or
>>>> suggest a specific improvement, I'll be happy to help you implement
>>>> it.
>>>>
>>>> /Anders
>>>>
>>>>> ----------------------
>>>>> Matthew Inger
>>>>> Design Architect
>>>>> Synygy, Inc
>>>>> 610-664-7433 x7770
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>>>> Free Linux tutorial presented by Daniel Robbins, President and CEO  
>>>>> of
>>>>> GenToo technologies. Learn everything from fundamentals to system
>>>>> administration.http://ads.osdn.com/? 
>>>>> ad_id=1470&alloc_id=3638&op=click
>>>>> _______________________________________________
>>>>> ojAlgo-user mailing list
>>>>> ojA...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> ojAlgo-user mailing list
>> ojA...@li...
>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>
>

Re: [ojAlgo-user] Questions

[Anders P. <and...@op...>]

In my previous mail it should read "It will speed things up..." ;-)

On 2004-04-20, at 14.57, Inger, Matthew wrote:

> The basic slowdown is that the constructors are not cached.
> Finding the constructor each time is what makes that factory
> slow.

I understand! Do you know of any reason why MatrixFactory should not  
cache the constructors?

> If MatrixFactory was an interface, one could just call
> the appropriate constructurs directly without reflection.
>
> public interface MatrixFactory {
>    public BasicMatrix create(double values[][]);
> }
>
> public class BigMatrixFactory implements MatrixFactory {
>   public BasicMatrix create(double values[][]) {
>      return new BigMatrix(values);
>   }
> }
>
> You could still have the original vresion, but it would
> be named something different, and implement this new interface.

Ok, I see what you mean. Is that a commonly used design pattern for  
factories?

> -----Original Message-----
> From: Anders Peterson [mailto:and...@op...]
> Sent: Tuesday, April 20, 2004 4:40 AM
> To: Inger, Matthew
> Cc: 'oja...@li...'
> Subject: Re: [ojAlgo-user] Questions
>
>
> On 2004-04-19, at 22.39, Inger, Matthew wrote:
>
>> FYI:  Using MatrixFactory is also extremely slow.
>> If i directly instantiate JamaMatrix for 100,000
>> regressions, it takes ~ 2 seconds or so.  If i use
>> MatrixFactory to instantiate, it goes up to 8 seconds.
>
> MatrixFactory uses reflection to call the appropriate constructor.
> Using it centralises matrix creation and allows you to switch
> implementation by changing one line of code - the call to the
> MatrixFactory constructor. (Make sure you re-use the factory
> instances.)
>
> This will naturally take longer than calling the constructor directly,
> but I am surprised it is that much slower.
>
> If this is a problem; call the constructors directly. Perhaps you
> should implement your own static factory method.
>
>> I'm a little curious why MatrixFactory is not an interface,
>> with implementations per different type of Matrix.
>
> Interfaces can't specify contructors.
>
> /Anders
>
>> -----Original Message-----
>> From: Inger, Matthew
>> Sent: Monday, April 19, 2004 3:04 PM
>> To: 'Anders Peterson'; Inger, Matthew
>> Subject: RE: [ojAlgo-user] Questions
>>
>>
>> There are a small number of variables.  In most cases, we
>> have a single variable equation, and up to 24 points with
>> which to fit the linear regression.
>>
>> Then, we do that 10,000 times.
>>
>> Basically, each row in the database contains time elapsed
>> data (typically one value per month).  We use the # of the
>> month as the x values, and the data as the y value, and try
>> to fit a line to it to determine short term trends.
>>
>> So for each row, we calculate 1 set of coefficients (b0 and b1,
>> aka intercept & slope), and make 1 more predictions.
>>
>> However, there are potentially millions of rows in the database.
>>
>>
>> -----Original Message-----
>> From: Anders Peterson [mailto:and...@op...]
>> Sent: Monday, April 19, 2004 2:32 PM
>> To: Inger, Matthew
>> Subject: Re: [ojAlgo-user] Questions
>>
>>
>> This is just a naive first attempt...
>>
>> On 2004-04-19, at 20.06, Inger, Matthew wrote:
>>
>>> PS:  As far as solving the equations, i basically have two
>>> matrices.  X and Y.  Any kind of code snippet would help here.
>>> Keep in mind, equations are of the form
>>>
>>> 	y = b0 + b1*X
>>
>> 1*b0 + x*b1 = y
>>
>> A*X = B
>>
>> where
>>
>> A:
>> 1	x1
>> 1	x2
>> 1	x3
>> ...	...
>>
>> B:
>> y1
>> y2
>> y3
>> ...
>>
>> X:
>> b0
>> b1
>>
>> X = A.solve(B);
>>
>> Are you doing this 10 000 times with a relatively small number of x-
>> and y-values or do you have 10 000 x- and y-values for each
>> calculation?
>>
>> /Anders
>>
>>> -----Original Message-----
>>> From: Anders Peterson [mailto:and...@op...]
>>> Sent: Monday, April 19, 2004 2:02 PM
>>> To: Inger, Matthew
>>> Cc: 'oja...@li...'
>>> Subject: Re: [ojAlgo-user] Questions
>>>
>>>
>>> On 2004-04-19, at 18.33, Inger, Matthew wrote:
>>>
>>>> 1.  Have any performance tests been run with BigMatrix?
>>>
>>> Not really...
>>>
>>>>    I'm using
>>>> BigMatrix to do a
>>>>      LinearRegression algorithm.  I had previously been using Jama
>>>> directly,
>>>> but our FD
>>>>      department noticed a difference between the results given by
>>>> java
>>>> and
>>>> the LINEST
>>>>      function in Excel.  I have determined that the difference is
>>>> DEFINATELY
>>>> due to rounding
>>>>      limitations in the java double primitive type.
>>>>
>>>>      These issues go away when i use ojAlgo library,
>>>
>>> That's great news to me - that is the reason I created ojAlgo!
>>>
>>>> however, the time
>>>> required to do the
>>>>      calculations increases to about 12-13x what it was using  
>>>> regular
>>>> double
>>>> calculations.
>>>>
>>>>      Doing 10,000 linear regressions with Jama took about .781s
>>>> (according
>>>> to junit), and
>>>>      with BigMatrix, took 10.345s
>>>
>>> I wasn't aware the difference was that big. ;-)
>>>
>>>>      Any idea why such a hug disparity?
>>>
>>> Try altering the scale. A larger scale means better results, but it
>>> takes longer. You can change a matrix' scale whenever you want - the
>>> new scale will be used from then on. Elements are not rounded unless
>>> you call enforceScale().
>>>
>>> Internally BigMatrix uses various decompositions for some of the more
>>> complex calculations. These decompositions inherit a scale from the
>>> parent matrix. It is however not the same - it's bigger. I believe  
>>> the
>>> formula is 2 * (3 + max(9, matrixScale)) and this formula is  
>>> evaluated
>>> when the decomposition is created. After the decomposition is created
>>> its scale wont change even if you change the matrix' scale. The scale
>>> of a decomposition is never smaller than 24 (according to the above
>>> formula).
>>>
>>> I'm not happy with this, and have been meaning to change it.
>>> Decompositions should have the same scale as its parent matrix, and
>>> when it is changed, updated "everywhere".
>>>
>>> Would you prefer that?
>>>
>>>> 2.  Is there a way to use the solvers in OjAlg to do the linear
>>>> regression?
>>>> Or is that not
>>>>      something that is provided?
>>>
>>> How are you currently doing it?
>>>
>>> I imagine the best way would be to simply build an over-determined  
>>> set
>>> of linear equations - Ax=B - and call A.solve(B). Internally  
>>> BigMatrix
>>> would then use the QR decomposition to give a least squares  
>>> estimation
>>> of x. That would be my first attempt.
>>>
>>> You could use the QP solver do the same thing, but I don't see how
>>> that
>>> would simplify or improve anything.
>>>
>>> What version of ojAlgo are you using - v1, v2 or CVS?
>>>
>>> I recommend working from CVS. Unfortunately I have moved things  
>>> around
>>> a bit in between version...
>>>
>>> I don't have access to a profiling tool, but I know they can be very
>>> useful in finding bottlenecks. If you can identify a problem, and/or
>>> suggest a specific improvement, I'll be happy to help you implement
>>> it.
>>>
>>> /Anders
>>>
>>>> ----------------------
>>>> Matthew Inger
>>>> Design Architect
>>>> Synygy, Inc
>>>> 610-664-7433 x7770
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>>> Free Linux tutorial presented by Daniel Robbins, President and CEO  
>>>> of
>>>> GenToo technologies. Learn everything from fundamentals to system
>>>> administration.http://ads.osdn.com/? 
>>>> ad_id=1470&alloc_id=3638&op=click
>>>> _______________________________________________
>>>> ojAlgo-user mailing list
>>>> ojA...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>

Re: [ojAlgo-user] Questions

[Anders P. <and...@op...>]

Sorry just A from the example below...

I will speed things up if you can reduce the number of times you  
calculate the QR decomposition (Regardless of which matrix  
implementation you use).

In practise perhaps you can create groups of calculations that share  
the same x values.

/Anders

On 2004-04-20, at 14.57, Inger, Matthew wrote:

> In my test, yes, they are the same, but in practice, they
> will not be.  What's an A-Matrix?
>
> -----Original Message-----
> From: Anders Peterson [mailto:and...@op...]
> Sent: Tuesday, April 20, 2004 4:53 AM
> To: Inger, Matthew
> Cc: 'oja...@li...'
> Subject: Re: [ojAlgo-user] Questions
>
>
> Do you re-use the A-matrix? Are the x values the same for the 10k
> regressions?
>
> On 2004-04-19, at 21.03, Inger, Matthew wrote:
>
>> There are a small number of variables.  In most cases, we
>> have a single variable equation, and up to 24 points with
>> which to fit the linear regression.
>>
>> Then, we do that 10,000 times.
>>
>> Basically, each row in the database contains time elapsed
>> data (typically one value per month).  We use the # of the
>> month as the x values, and the data as the y value, and try
>> to fit a line to it to determine short term trends.
>>
>> So for each row, we calculate 1 set of coefficients (b0 and b1,
>> aka intercept & slope), and make 1 more predictions.
>>
>> However, there are potentially millions of rows in the database.
>>
>>
>> -----Original Message-----
>> From: Anders Peterson [mailto:and...@op...]
>> Sent: Monday, April 19, 2004 2:32 PM
>> To: Inger, Matthew
>> Subject: Re: [ojAlgo-user] Questions
>>
>>
>> This is just a naive first attempt...
>>
>> On 2004-04-19, at 20.06, Inger, Matthew wrote:
>>
>>> PS:  As far as solving the equations, i basically have two
>>> matrices.  X and Y.  Any kind of code snippet would help here.
>>> Keep in mind, equations are of the form
>>>
>>> 	y = b0 + b1*X
>>
>> 1*b0 + x*b1 = y
>>
>> A*X = B
>>
>> where
>>
>> A:
>> 1	x1
>> 1	x2
>> 1	x3
>> ...	...
>>
>> B:
>> y1
>> y2
>> y3
>> ...
>>
>> X:
>> b0
>> b1
>>
>> X = A.solve(B);
>>
>> Are you doing this 10 000 times with a relatively small number of x-
>> and y-values or do you have 10 000 x- and y-values for each
>> calculation?
>>
>> /Anders
>>
>>> -----Original Message-----
>>> From: Anders Peterson [mailto:and...@op...]
>>> Sent: Monday, April 19, 2004 2:02 PM
>>> To: Inger, Matthew
>>> Cc: 'oja...@li...'
>>> Subject: Re: [ojAlgo-user] Questions
>>>
>>>
>>> On 2004-04-19, at 18.33, Inger, Matthew wrote:
>>>
>>>> 1.  Have any performance tests been run with BigMatrix?
>>>
>>> Not really...
>>>
>>>>    I'm using
>>>> BigMatrix to do a
>>>>      LinearRegression algorithm.  I had previously been using Jama
>>>> directly,
>>>> but our FD
>>>>      department noticed a difference between the results given by
>>>> java
>>>> and
>>>> the LINEST
>>>>      function in Excel.  I have determined that the difference is
>>>> DEFINATELY
>>>> due to rounding
>>>>      limitations in the java double primitive type.
>>>>
>>>>      These issues go away when i use ojAlgo library,
>>>
>>> That's great news to me - that is the reason I created ojAlgo!
>>>
>>>> however, the time
>>>> required to do the
>>>>      calculations increases to about 12-13x what it was using  
>>>> regular
>>>> double
>>>> calculations.
>>>>
>>>>      Doing 10,000 linear regressions with Jama took about .781s
>>>> (according
>>>> to junit), and
>>>>      with BigMatrix, took 10.345s
>>>
>>> I wasn't aware the difference was that big. ;-)
>>>
>>>>      Any idea why such a hug disparity?
>>>
>>> Try altering the scale. A larger scale means better results, but it
>>> takes longer. You can change a matrix' scale whenever you want - the
>>> new scale will be used from then on. Elements are not rounded unless
>>> you call enforceScale().
>>>
>>> Internally BigMatrix uses various decompositions for some of the more
>>> complex calculations. These decompositions inherit a scale from the
>>> parent matrix. It is however not the same - it's bigger. I believe  
>>> the
>>> formula is 2 * (3 + max(9, matrixScale)) and this formula is  
>>> evaluated
>>> when the decomposition is created. After the decomposition is created
>>> its scale wont change even if you change the matrix' scale. The scale
>>> of a decomposition is never smaller than 24 (according to the above
>>> formula).
>>>
>>> I'm not happy with this, and have been meaning to change it.
>>> Decompositions should have the same scale as its parent matrix, and
>>> when it is changed, updated "everywhere".
>>>
>>> Would you prefer that?
>>>
>>>> 2.  Is there a way to use the solvers in OjAlg to do the linear
>>>> regression?
>>>> Or is that not
>>>>      something that is provided?
>>>
>>> How are you currently doing it?
>>>
>>> I imagine the best way would be to simply build an over-determined  
>>> set
>>> of linear equations - Ax=B - and call A.solve(B). Internally  
>>> BigMatrix
>>> would then use the QR decomposition to give a least squares  
>>> estimation
>>> of x. That would be my first attempt.
>>>
>>> You could use the QP solver do the same thing, but I don't see how
>>> that
>>> would simplify or improve anything.
>>>
>>> What version of ojAlgo are you using - v1, v2 or CVS?
>>>
>>> I recommend working from CVS. Unfortunately I have moved things  
>>> around
>>> a bit in between version...
>>>
>>> I don't have access to a profiling tool, but I know they can be very
>>> useful in finding bottlenecks. If you can identify a problem, and/or
>>> suggest a specific improvement, I'll be happy to help you implement
>>> it.
>>>
>>> /Anders
>>>
>>>> ----------------------
>>>> Matthew Inger
>>>> Design Architect
>>>> Synygy, Inc
>>>> 610-664-7433 x7770
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>>> Free Linux tutorial presented by Daniel Robbins, President and CEO  
>>>> of
>>>> GenToo technologies. Learn everything from fundamentals to system
>>>> administration.http://ads.osdn.com/? 
>>>> ad_id=1470&alloc_id=3638&op=click
>>>> _______________________________________________
>>>> ojAlgo-user mailing list
>>>> ojA...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>

RE: [ojAlgo-user] Questions

[Inger, M. <In...@Sy...>]

In my test, yes, they are the same, but in practice, they
will not be.  What's an A-Matrix?

-----Original Message-----
From: Anders Peterson [mailto:and...@op...]
Sent: Tuesday, April 20, 2004 4:53 AM
To: Inger, Matthew
Cc: 'oja...@li...'
Subject: Re: [ojAlgo-user] Questions


Do you re-use the A-matrix? Are the x values the same for the 10k 
regressions?

On 2004-04-19, at 21.03, Inger, Matthew wrote:

> There are a small number of variables.  In most cases, we
> have a single variable equation, and up to 24 points with
> which to fit the linear regression.
>
> Then, we do that 10,000 times.
>
> Basically, each row in the database contains time elapsed
> data (typically one value per month).  We use the # of the
> month as the x values, and the data as the y value, and try
> to fit a line to it to determine short term trends.
>
> So for each row, we calculate 1 set of coefficients (b0 and b1,
> aka intercept & slope), and make 1 more predictions.
>
> However, there are potentially millions of rows in the database.
>
>
> -----Original Message-----
> From: Anders Peterson [mailto:and...@op...]
> Sent: Monday, April 19, 2004 2:32 PM
> To: Inger, Matthew
> Subject: Re: [ojAlgo-user] Questions
>
>
> This is just a naive first attempt...
>
> On 2004-04-19, at 20.06, Inger, Matthew wrote:
>
>> PS:  As far as solving the equations, i basically have two
>> matrices.  X and Y.  Any kind of code snippet would help here.
>> Keep in mind, equations are of the form
>>
>> 	y = b0 + b1*X
>
> 1*b0 + x*b1 = y
>
> A*X = B
>
> where
>
> A:
> 1	x1
> 1	x2
> 1	x3
> ...	...
>
> B:
> y1
> y2
> y3
> ...
>
> X:
> b0
> b1
>
> X = A.solve(B);
>
> Are you doing this 10 000 times with a relatively small number of x-
> and y-values or do you have 10 000 x- and y-values for each
> calculation?
>
> /Anders
>
>> -----Original Message-----
>> From: Anders Peterson [mailto:and...@op...]
>> Sent: Monday, April 19, 2004 2:02 PM
>> To: Inger, Matthew
>> Cc: 'oja...@li...'
>> Subject: Re: [ojAlgo-user] Questions
>>
>>
>> On 2004-04-19, at 18.33, Inger, Matthew wrote:
>>
>>> 1.  Have any performance tests been run with BigMatrix?
>>
>> Not really...
>>
>>>    I'm using
>>> BigMatrix to do a
>>>      LinearRegression algorithm.  I had previously been using Jama
>>> directly,
>>> but our FD
>>>      department noticed a difference between the results given by 
>>> java
>>> and
>>> the LINEST
>>>      function in Excel.  I have determined that the difference is
>>> DEFINATELY
>>> due to rounding
>>>      limitations in the java double primitive type.
>>>
>>>      These issues go away when i use ojAlgo library,
>>
>> That's great news to me - that is the reason I created ojAlgo!
>>
>>> however, the time
>>> required to do the
>>>      calculations increases to about 12-13x what it was using regular
>>> double
>>> calculations.
>>>
>>>      Doing 10,000 linear regressions with Jama took about .781s
>>> (according
>>> to junit), and
>>>      with BigMatrix, took 10.345s
>>
>> I wasn't aware the difference was that big. ;-)
>>
>>>      Any idea why such a hug disparity?
>>
>> Try altering the scale. A larger scale means better results, but it
>> takes longer. You can change a matrix' scale whenever you want - the
>> new scale will be used from then on. Elements are not rounded unless
>> you call enforceScale().
>>
>> Internally BigMatrix uses various decompositions for some of the more
>> complex calculations. These decompositions inherit a scale from the
>> parent matrix. It is however not the same - it's bigger. I believe the
>> formula is 2 * (3 + max(9, matrixScale)) and this formula is evaluated
>> when the decomposition is created. After the decomposition is created
>> its scale wont change even if you change the matrix' scale. The scale
>> of a decomposition is never smaller than 24 (according to the above
>> formula).
>>
>> I'm not happy with this, and have been meaning to change it.
>> Decompositions should have the same scale as its parent matrix, and
>> when it is changed, updated "everywhere".
>>
>> Would you prefer that?
>>
>>> 2.  Is there a way to use the solvers in OjAlg to do the linear
>>> regression?
>>> Or is that not
>>>      something that is provided?
>>
>> How are you currently doing it?
>>
>> I imagine the best way would be to simply build an over-determined set
>> of linear equations - Ax=B - and call A.solve(B). Internally BigMatrix
>> would then use the QR decomposition to give a least squares estimation
>> of x. That would be my first attempt.
>>
>> You could use the QP solver do the same thing, but I don't see how 
>> that
>> would simplify or improve anything.
>>
>> What version of ojAlgo are you using - v1, v2 or CVS?
>>
>> I recommend working from CVS. Unfortunately I have moved things around
>> a bit in between version...
>>
>> I don't have access to a profiling tool, but I know they can be very
>> useful in finding bottlenecks. If you can identify a problem, and/or
>> suggest a specific improvement, I'll be happy to help you implement 
>> it.
>>
>> /Anders
>>
>>> ----------------------
>>> Matthew Inger
>>> Design Architect
>>> Synygy, Inc
>>> 610-664-7433 x7770
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>> GenToo technologies. Learn everything from fundamentals to system
>>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>> _______________________________________________
>>> ojAlgo-user mailing list
>>> ojA...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>