ojalgo-user — For ojAlgo users

Re: [ojAlgo-user] Performance tests

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

ojAlgo only has one SVD implementation and that is the Jama version -  
there is nothing to compare.

Remember that Jama is part of ojAlgo. When I say I compare ojAlgo and  
Jama I actually compare two different implementations that both are  
part of ojAlgo.

ojAlgo has added a couple of features to the Jama SVD implementation:

1) You do not have to worry about if m >= n or not.
2) The pseudoinverse is generated for you

Compared to QR, SVD has about half the speed when computing the  
decomposition and twice the speed when solving equation systems. If  
you need to solve several equation system using the same  
decomposition you should cache the pseudoinverse.

/Anders


Cholesky" name="testComputeJamaMatrix" time="8.222"
Cholesky" name="testComputePrimitiveMatrix" time="7.312"
Cholesky" name="testSolveJamaMatrix" time="293.061"
Cholesky" name="testSolvePrimitiveMatrix" time="32.724"

LU" name="testComputeJamaMatrix" time="11.854"
LU" name="testComputePrimitiveMatrix" time="11.117"
LU" name="testSolveJamaMatrix" time="52.472"
LU" name="testSolvePrimitiveMatrix" time="32.969"

QR" name="testComputeJamaMatrix" time="100.003"
QR" name="testComputePrimitiveMatrix" time="97.261"
QR" name="testSolveJamaMatrix" time="324.638"
QR" name="testSolvePrimitiveMatrix" time="170.974"

SingularValue" name="testComputeJamaMatrix" time="738.433"
SingularValue" name="testSolveJamaMatrix" time="127.215"

Eigenvalue" name="testComputeJamaMatrix" time="312.795"


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


On 18 jul 2007, at 10.51, Dimitri Pourbaix wrote:

> Anders,
>
>> The main news is that the ojAlgo "native" LU.compute() is now faster
>> than (or at least roughly as fast as) the Jama version. It used to be
>> clearly slower. There is some variation in the timings between  
>> different
>> runs, but the trend is clear.
>
> What about SVD?
>
> Regards,
>    Dim.
> ---------------------------------------------------------------------- 
> ------
> Dimitri Pourbaix                         *
> Institut d'Astronomie et d'Astrophysique *      Don't worry, be happy
> CP 226, office 2.N4.211, building NO     *         and CARPE DIEM.
> Universite Libre de Bruxelles            *
> Boulevard du Triomphe                    *      Tel : +32-2-650.35.71
>    B-1050 Bruxelles                        *      Fax :  
> +32-2-650.42.26
> http://sb9.astro.ulb.ac.be/~pourbaix     *  
> mailto:pou...@as...
>
> ---------------------------------------------------------------------- 
> ---
> 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/
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>
>

Re: [ojAlgo-user] Performance tests

[Dimitri P. <pou...@as...>]

Anders,

> The main news is that the ojAlgo "native" LU.compute() is now faster
> than (or at least roughly as fast as) the Jama version. It used to be
> clearly slower. There is some variation in the timings between different
> runs, but the trend is clear.

What about SVD?

Regards,
   Dim.
----------------------------------------------------------------------------
Dimitri Pourbaix                         *
Institut d'Astronomie et d'Astrophysique *      Don't worry, be happy
CP 226, office 2.N4.211, building NO     *         and CARPE DIEM.
Universite Libre de Bruxelles            *
Boulevard du Triomphe                    *      Tel : +32-2-650.35.71
   B-1050 Bruxelles                        *      Fax : +32-2-650.42.26
http://sb9.astro.ulb.ac.be/~pourbaix     * mailto:pou...@as...

[ojAlgo-user] Performance tests

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

These are the latest timings...

1000x1000 matrices and performing each operation 10 times.

compute() ojAlgo/Jama

Chol: 7,31/8,22
LU: 11.12/11.85
QR: 97.26/100.00

solve() ojAlgo/Jama

Chol: 32.74/293.06
LU: 32.97/52.47
QR: 170.97/324.64

The main news is that the ojAlgo "native" LU.compute() is now faster 
than (or at least roughly as fast as) the Jama version. It used to be 
clearly slower. There is some variation in the timings between different 
runs, but the trend is clear.

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

/Anders

Re: [ojAlgo-user] Error Message

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

ojAlgo is not an application. It's Java code you may use to build  
your own application. The BLapp prototype application is built using  
ojAlgo, but the source code for BLApp is not available to you.

/Anders

On 13 jul 2007, at 21.05, ken black wrote:

> I am a "newbie" to Java so I am sure this is cockpit error------- 
> when I click on the downloaded Ojalgo-20
> executable Jar file in "Bin folder" I get an error message as follows
>   "Failed to Load Main class manifest attribute from     C 
> \............bin\ojalgo.jar"
>
> What do I do?
> ---------------------------------------------------------------------- 
> ---
> 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/ 
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user

[ojAlgo-user] Error Message

[ken b. <ken...@ad...>]

I am a "newbie" to Java so I am sure this is cockpit error-------when I =
click on the downloaded Ojalgo-20=20
executable Jar file in "Bin folder" I get an error message as follows
  "Failed to Load Main class manifest attribute from     =
C\............bin\ojalgo.jar"

What do I do?

Re: [ojAlgo-user] URL problems

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

The application server had died. It should work now.

The app that is currently available is a very early beta version -  
but useable. One cool thing to notice is that the Symbols you can  
type/choose on the Setup Basics page can be set to any instrument  
symbol available at Yahoo Finance. To find what symbols to use you  
should look here:

http://finance.yahoo.com/lookup

Also note that not all symbols available at Yahoo Finance have  
historical prices. You'll notice when that's the case as the price is  
set to constant 1 (straight line).

/Anders


On 13 jul 2007, at 16.18, ken black wrote:

> I am unable to view the online Black-Litterman application using  
> the url given on the website
> ---------------------------------------------------------------------- 
> ---
> 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/ 
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user

[ojAlgo-user] URL problems

[ken b. <ken...@ad...>]

I am unable to view the online Black-Litterman application using the url =
given on the website

[ojAlgo-user] [SourceForge.net Release] ojAlgo v20

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

http://ojalgo.org/change_log.html

SourceForge.net wrote:
> Project: ojAlgo  (ojalgo)
> Package: ojAlgo
> Date   : 2007-05-21 09:09
>
> Project "ojAlgo" ('ojalgo') has released the new version of package 'ojAlgo'.
> You can download it from SourceForge.net by following this link:
> <https://sourceforge.net/project/showfiles.php?group_id=79000&release_id=509971>
> or browse Release Notes and ChangeLog by visiting this link:
> <https://sourceforge.net/project/shownotes.php?release_id=509971> 
>
> You receive this email because you requested to be notified when new versions
> of this package were released. If you don't wish to be notified in the future,
> please login to SourceForge.net and click this link:
> <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=80289>
> If you lost your SourceForge.net login name or password, refer to this document:
> <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1>
>
> Note that you may receive this message indirectly via one of your mailing list
> subscriptions. Please review message headers before reporting unsolicited
> mailings.
>   

Re: [ojAlgo-user] Performance tests

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

Niko Brummer wrote:
> Hi Anders
>
> I have a general comment about  performance when working with large matrices.
>
> ************************************************************************
> *  It matters a lot in what order you access the data in memory. *
> ************************************************************************
>   
> I have done similar matrix multiplication experiments in Java, with
> similar results. Although in Java you don't have very good control
> over how and where matrix elements are stored in memory, it is still
> often possible by re-arranging the order in which elements are
> accessed, to speed up things considerably.

I have spent many hours performance tweaking ojAlgo. (Performance has 
improved a lot with the last handful of releases.) Though I am beginning 
to get a feeling for what is good/bad I cannot say I know how to write 
top performing code. I have to experiment, and tiny changes can make a 
huge difference. Yes, I have also learned, that thinking about in what 
order you access array elements is very important. Doing matrix 
decompositions, in place, is particularly difficult.

/Anders

Re: [ojAlgo-user] Performance tests

[Niko B. <nik...@gm...>]

Hi Anders

I have a general comment about  performance when working with large matrices.

************************************************************************
*  It matters a lot in what order you access the data in memory. *
************************************************************************

Consider the following example, using MATLAB version 5.2.0 on a 3Ghz Pentium 4.

>> M = ones(10000); % This matrix has a size of about 800 MB.
>> v = ones(10000,1);

% multiply
>> tic;M*v;toc
elapsed_time =

    6.6870

% If M is symmetrical, this gives the same answer, but accesses memory
differently
>> tic;(v'*M)';toc
elapsed_time =

    0.2350

I have done similar matrix multiplication experiments in Java, with
similar results. Although in Java you don't have very good control
over how and where matrix elements are stored in memory, it is still
often possible by re-arranging the order in which elements are
accessed, to speed up things considerably.


Niko Brummer

[ojAlgo-user] Performance tests

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

I regularly test performance and make comparisons between ojAlgo and 
Jama (also part of ojAlgo).

The MatrixDecomposition interface has two major methods: compute() and 
solve().

Here are example figures using 1000x1000 matrices and performing each 
operation 10 times.

compute() ojAlgo/Jama

Chol: 8,15/7,09
LU: 20,39/14,56
QR: 98,68/104,51

solve() ojAlgo/Jama

Chol: 39,88/197,55
LU: 41,28/61,69
QR: 177,58/268,45


Comments
--------------

Don't use jama cholesky solve, it's very (unnecessarily) slow!

Apart from the cholesky case, solve takes about 2 to 4 times longer than 
compute.

Jama performs better with compute, but ojAlgo does solve faster. Doing 
both compute and solve (which is often what you want) ojAlgo is 20-25% 
faster than Jama (77% in the Cholesky case).

ojAlgo, and QR in particular, is favored by large matrices when 
comparing to Jama. The two QR implementations are about equally fast 
when using 400x400 matrices.

For SVD and Eigenvalue decompositions ojAlgo delegates to Jama - there 
is nothing to compare.

The source for these tests are in CVS.

You can see more of the results here:
http://ojalgo.org/generated/comparison.xml


Don't forget!!! When using ojAlgo you can easily switch between using 
the different implementations.


/Anders

Re: [ojAlgo-user] OjAlgo exception in SVD

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

On 1 maj 2007, at 14.09, Anders Peterson wrote:

> Maybe PhysicalFactory needs another method. I'll think about that.
> Currently you have two ways to avoid explicit looping:
>
> 1)
>
> PrimitiveMatrix.FACTORY.make(double[][]).toPrimitiveStore();
>
> 2)
>
> PrimitiveDenseStore.FACTORY.makeArrayCopy(Array2Dim.makePrimitive 
> (double[][]).getDelegate());

3)

RawStore.makePrimitive(double[][]).toPhysicalStore();

/Anders

Re: [ojAlgo-user] OjAlgo exception in SVD

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

Read my answers below...

Dimitri Pourbaix wrote:
> Dear Anders,
>
> You asked me for test cases of SVD.  Here is one ... and the problem I
> have with it.  
You need use the latest code from CVS. The solve() method in the SVD 
implementation was simply not yet implemented when I released Version 
19, AND there was a problem with the getPseudoinverse() method. This is 
now fixed in CVS, and will of course be included with Version 20.
> Still, your implementation is very elegant and the resul-
> ting much more straightforward to read.
Thank you.
>
> With my best regards,
>  Dim.
>
> Using the following class:
>
>     class OjAlgoTest {
>         private final 
> org.ojalgo.matrix.factory.PhysicalFactory<Double> _factory
>             = org.ojalgo.matrix.store.PrimitiveDenseStore.FACTORY;
>         private org.ojalgo.matrix.store.MatrixStore<Double> _a;
>         private org.ojalgo.matrix.store.MatrixStore<Double> _b;
>         private org.ojalgo.matrix.store.MatrixStore<Double> _x;
>
>         public OjAlgoTest(double[][] a,
>                           double[][] b) {
>             _a = _factory.makeEmpty(a.length, a[0].length);
>             _b = _factory.makeEmpty(b.length, b[0].length);
>
>             for (int i = 0, maxI = _a.getRowDim(); i < maxI; i++) {
>                 for (int j = 0, maxJ = _a.getColDim(); j < maxJ; j++) {
>                     _a.toPhysicalStore().set(i, j, a[i][j]);
>                 }
>             }
>             for (int i = 0, maxI = _b.getRowDim(); i < maxI; i++) {
>                 for (int j = 0, maxJ = _b.getColDim(); j < maxJ; j++) {
>                     _b.toPhysicalStore().set(i, j, b[i][j]);
>                 }
>             }
>         }
>
>         public void svd() {
>             
> org.ojalgo.matrix.decomposition.MatrixDecomposition<Double> dec
>                 = new org.ojalgo.matrix.jama.JamaSingularValue();
>             if (dec.compute(_a)) {
>                 _x = dec.solve(_b);
>             } else {
>                 throw new org.ojalgo.ProgrammingError("Matrix is not 
> solvable");
>             }
>         }
>     }
>
> with "ojalgo-19.0.jar", the method "svd()" triggers an exception:
>
> Exception in thread "main" org.ojalgo.ProgrammingError: Don't use this 
> method/constructor!
>         at 
> org.ojalgo.ProgrammingError.throwForIllegalInvocation(ProgrammingError.java:36) 
>
>         at 
> org.ojalgo.matrix.jama.JamaSingularValue.solve(JamaSingularValue.java:193) 
>
>         at 
> org.ojalgo.matrix.jama.JamaAbstractDecomposition.solve(JamaAbstractDecomposition.java:69) 
>
>         at 
> my.MatrixComparisons$OjAlgoTest.svd(MatrixComparisons.java:308)
>         at my.MatrixComparisons.<init>(MatrixComparisons.java:88)
>         at my.StandAlone.main(StandAlone.java:31)
>
> Another question: Why isn't there a factory method to create a matrix 
> from a
> two-dimensional array (which would avoid the explicit loop in the above
> constructor)?
Maybe PhysicalFactory needs another method. I'll think about that. 
Currently you have two ways to avoid explicit looping:

1)

PrimitiveMatrix.FACTORY.make(double[][]).toPrimitiveStore();

2)

PrimitiveDenseStore.FACTORY.makeArrayCopy(Array2Dim.makePrimitive(double[][]).getDelegate());

/Anders

[ojAlgo-user] The upcoming Version 20

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

Hi,

I'd just like to say a few words about the upcoming version 20.

There wont be many new features, but a lot of things will change. The 
next version will not be api-compatible with the current. The most 
important change is to make PhysicalStore no longer "extends 
BasicArray". The BasicMatrix interface is safe. I have changed exactly 1 
(minor) thing and no other changes are planned. (Apart from what was 
already deprecated.)

If there are things you wished were implemented/named/structured 
differently, now is a good time to let me know.

/Anders

Re: [ojAlgo-user] new to sf

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

Nick Wexler wrote:
> "What do you think about the fact that PhysicalStore extends both
> MatrixStore and BasicArray?"
>
> Unless the PhysicalStore contract states a different implementation of 
> a BasicArray than what BasicArray states, it should not extend 
> BasicArray.  When necessary, I would let the appropriate classes 
> implement BasicArray instead of gaining those methods through 
> implementing PhysicalStore. 
>
> During this change, I think documenting the Contract differences 
> between a MatrixStore and a PhysicalStore would be extremely helping 
> in determining the proper usage of the interfaces.

I think my original idea was something like:

BasicArray is arbitrary-dimensional, and PhysicalStore is two-dimesnional.

MatrixStore is basic and immutable, PhysicalStore is more feature rich 
and mutable.


Currently I really feel I should disconnect PhysicalStore from 
BasicArray, but the required code changes are a bit messy. I need a good 
day to do it.

/Anders

Re: [ojAlgo-user] Future of Jama

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

Anders Peterson wrote:
>> part, I do not clearly see its advantage with respect to Jama.  The 
>> names
>> of the methods are different ... but, in SVD for instance, I would 
>> not get
>> any functionality in its present version.  That is exactly where new 
>> methods to the SVD part of ojAlgo would be very useful.  E.g., solving a
>> overdetermined system of linear equation with SVD.
> The other aspect is that, if one restricts ojAlgo to the linear algebra
> I've added a fair bit of "OO" (abstractions and extensibility) to 
> ojAlgo compared to Jama, and I've manged to do that without loosing 
> performance.
>
> I also think that using BasicMatrix is as easy as using Jama, but you 
> have the option to start using BasicArray and MatrixStore directly if 
> need to.
>
> The ojAlgo SVD interface gives you the pseudoinverse.
>
> http://ojalgo.org/generated/org/ojalgo/matrix/decomposition/SingularValue.html#getPseudoinverse() 
>
>> If you want me to be more specific, let me know.
> Give me code examples (typical to what you want to do) where Jama, or 
> some other package, performs better and I'll try to "fix" the problem.

I forgot to mention that ojAlgo is multi-threaded when doing matrix 
multiplication.

/Anders

Re: [ojAlgo-user] Future of Jama

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

Can I ask you to join the ojAlgo mailing list?

https://lists.sourceforge.net/lists/listinfo/ojalgo-user

Dimitri Pourbaix wrote:
> Dear Anders,
>> Did you look at ojAlgo? What did you think?
> Yes, I did look at ojAlgo.  One thing that worries me (potentially a lot)
> is the overhead due to your 'Number' basic element rather than simply
> 'double'.  As I wrote in my very first mail, we are considering 6-month
> long intense computations.  So, any millisecond wasted in two much abs-
> traction can kill us.
Don't worry too much - look at the source code. Calculations are done 
using 'double' unless you choose to work with BigDecimal or 
ComplexNumber instead. I regularly benchmark ojAlgo against Jama - it 
performs very well!

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

Please write your own tests. If you want best possible performance and 
full control over which code is being executed you should work with 
MatrixStore instead of BasicMatrix.

http://ojalgo.org/generated/org/ojalgo/matrix/store/MatrixStore.html
http://ojalgo.org/generated/org/ojalgo/matrix/BasicMatrix.html

I recommend you get the latest source code from CVS. The only module you 
need is DevProj - it has no dependencies (other than Java5).

http://sourceforge.net/cvs/?group_id=79000
> The other aspect is that, if one restricts ojAlgo to the linear algebra
> part, I do not clearly see its advantage with respect to Jama.  The names
> of the methods are different ... but, in SVD for instance, I would not 
> get
> any functionality in its present version.  That is exactly where new 
> methods to the SVD part of ojAlgo would be very useful.  E.g., solving a
> overdetermined system of linear equation with SVD.
I've added a fair bit of "OO" (abstractions and extensibility) to ojAlgo 
compared to Jama, and I've manged to do that without loosing performance.

I also think that using BasicMatrix is as easy as using Jama, but you 
have the option to start using BasicArray and MatrixStore directly if 
need to.

The ojAlgo SVD interface gives you the pseudoinverse.

http://ojalgo.org/generated/org/ojalgo/matrix/decomposition/SingularValue.html#getPseudoinverse()
> If you want me to be more specific, let me know.
Give me code examples (typical to what you want to do) where Jama, or 
some other package, performs better and I'll try to "fix" the problem.

/Anders

> With my best regards,
>  Dim.

Re: [ojAlgo-user] new to sf

[Nick W. <nw...@us...>]

"I see your point. Not sure I like the name suggestions though. To me
they imply the methods are making BasicMatrix or MatrixStore instances."
-- You are right on the naming.


"What do you think about the fact that PhysicalStore extends both
MatrixStore and BasicArray?"

Unless the PhysicalStore contract states a different implementation of a
BasicArray than what BasicArray states, it should not extend BasicArray.
When necessary, I would let the appropriate classes implement BasicArray
instead of gaining those methods through implementing PhysicalStore.

During this change, I think documenting the Contract differences between a
MatrixStore and a PhysicalStore would be extremely helping in determining
the proper usage of the interfaces.

Thank you for the quick response.
Nick

On 4/16/07, Anders Peterson <an...@op...> wrote:
>
> On 16 apr 2007, at 16.29, Nick Wexler wrote:
>
> > Hey,
> > I'm new to Sourceforge and this mailing list.  I read in the
> > version 19 post that major changes are coming in the next version.
> > I had some small recommendations that may cause significant changes
> > downstream on any dependent classes.  I wasn't sure if I should
> > just make my check out with version 19 or wait till version 20.
>
> It's best to express opinions/ideas as early as possible. When (if)
> they're implemented is a different matter.
>
> > From quickly looking at the classes, I saw in the
> > PrimitiveDenseStore the PhysicalFactory static nested class and
> > it's makeCopy methods.  I would recommend not overriding the
> > methods and instead have three methods that are defined by their
> > name and not just the parameters.  Since the parameters are just
> > interfaces and it's possible that a class may implement more than
> > one of the interfaces, no matter how illogical, it might be better
> > to have them be separate method names, say, makeBasicMatrix and
> > makeMatrixStore.
>
> I see your point. Not sure I like the name suggestions though. To me
> they imply the methods are making BasicMatrix or MatrixStore instances.
>
> > Perhaps this will be changed with version 20.  Anyway, my math
> > skills aren't fantastic, but I'm interested in this project and I'd
> > like to help out.  I'm open to advice and critiques as well.  I
> > hope that this will be a good Open Source experience (my first).
>
> Yes, I think I will change this. I'll just have to think about the
> method names. You're very welcome to help any way you can or want.
> What do you think about the fact that PhysicalStore extends both
> MatrixStore and BasicArray?
>
> /Anders
>
>
>
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>

Re: [ojAlgo-user] new to sf

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

On 16 apr 2007, at 16.29, Nick Wexler wrote:

> Hey,
> I'm new to Sourceforge and this mailing list.  I read in the  
> version 19 post that major changes are coming in the next version.   
> I had some small recommendations that may cause significant changes  
> downstream on any dependent classes.  I wasn't sure if I should  
> just make my check out with version 19 or wait till version 20.

It's best to express opinions/ideas as early as possible. When (if)  
they're implemented is a different matter.

> From quickly looking at the classes, I saw in the  
> PrimitiveDenseStore the PhysicalFactory static nested class and  
> it's makeCopy methods.  I would recommend not overriding the  
> methods and instead have three methods that are defined by their  
> name and not just the parameters.  Since the parameters are just  
> interfaces and it's possible that a class may implement more than  
> one of the interfaces, no matter how illogical, it might be better  
> to have them be separate method names, say, makeBasicMatrix and  
> makeMatrixStore.

I see your point. Not sure I like the name suggestions though. To me  
they imply the methods are making BasicMatrix or MatrixStore instances.

> Perhaps this will be changed with version 20.  Anyway, my math  
> skills aren't fantastic, but I'm interested in this project and I'd  
> like to help out.  I'm open to advice and critiques as well.  I  
> hope that this will be a good Open Source experience (my first).

Yes, I think I will change this. I'll just have to think about the  
method names. You're very welcome to help any way you can or want.  
What do you think about the fact that PhysicalStore extends both  
MatrixStore and BasicArray?

/Anders

[ojAlgo-user] new to sf

[Nick W. <nw...@us...>]

Hey,
I'm new to Sourceforge and this mailing list.  I read in the version 19 post
that major changes are coming in the next version.  I had some small
recommendations that may cause significant changes downstream on any
dependent classes.  I wasn't sure if I should just make my check out with
version 19 or wait till version 20.


>From quickly looking at the classes, I saw in the PrimitiveDenseStore the
PhysicalFactory static nested class and it's makeCopy methods.  I would
recommend not overriding the methods and instead have three methods that are
defined by their name and not just the parameters.  Since the parameters are
just interfaces and it's possible that a class may implement more than one
of the interfaces, no matter how illogical, it might be better to have them
be separate method names, say, makeBasicMatrix and makeMatrixStore.

Perhaps this will be changed with version 20.  Anyway, my math skills aren't
fantastic, but I'm interested in this project and I'd like to help out.  I'm
open to advice and critiques as well.  I hope that this will be a good Open
Source experience (my first).

Nick

Re: [ojAlgo-user] QuadradicSolver.getValue()

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

You're right. Guess I never needed the "value" before...

The fix is in CVS. I'm not releasing anything until I'm done with what 
will become version 20.

Thanks for pointing out the bug to me!

/Anders

to...@st... wrote:
> QuadradicSolver.getValue() seems to return:
> x'Qx + c'x
>
> instead of:
> 0.5x'Qx + c'x
>
> Tore
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>   

[ojAlgo-user] QuadradicSolver.getValue()

[<to...@st...>]

QuadradicSolver.getValue() seems to return:
x'Qx + c'x

instead of:
0.5x'Qx + c'x

Tore

Re: [ojAlgo-user] [ojAlgo Release] Version 19

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

Hi,

For version 20 I am planning a major API breaking change. Currently 
PhysicalStore extends both MatrixStore and BasicArray. I intend to 
simply have it extend MatrixStore. This will break a lot of Optimatika's 
current code, and potentially some of yours. If the consequences  are 
too severe I may not go through with this, but the plan is to make this 
change.

/Anders

Anders Peterson wrote:
> http://ojalgo.org/change_log.html
>
> SourceForge.net wrote:
>   
>> Project: ojAlgo  (ojalgo)
>> Package: ojAlgo
>> Date   : 2007-04-02 15:01
>>
>> Project "ojAlgo" ('ojalgo') has released the new version of package 'ojAlgo'.
>> You can download it from SourceForge.net by following this link:
>> <https://sourceforge.net/project/showfiles.php?group_id=79000&release_id=498291>
>> or browse Release Notes and ChangeLog by visiting this link:
>> <https://sourceforge.net/project/shownotes.php?release_id=498291> 
>>
>> You receive this email because you requested to be notified when new versions
>> of this package were released. If you don't wish to be notified in the future,
>> please login to SourceForge.net and click this link:
>> <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=80289>
>> If you lost your SourceForge.net login name or password, refer to this document:
>> <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1>
>>
>> Note that you may receive this message indirectly via one of your mailing list
>> subscriptions. Please review message headers before reporting unsolicited
>> mailings.
>>   
>>     
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>   

[ojAlgo-user] [ojAlgo Release] Version 19

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

http://ojalgo.org/change_log.html

SourceForge.net wrote:
> Project: ojAlgo  (ojalgo)
> Package: ojAlgo
> Date   : 2007-04-02 15:01
>
> Project "ojAlgo" ('ojalgo') has released the new version of package 'ojAlgo'.
> You can download it from SourceForge.net by following this link:
> <https://sourceforge.net/project/showfiles.php?group_id=79000&release_id=498291>
> or browse Release Notes and ChangeLog by visiting this link:
> <https://sourceforge.net/project/shownotes.php?release_id=498291> 
>
> You receive this email because you requested to be notified when new versions
> of this package were released. If you don't wish to be notified in the future,
> please login to SourceForge.net and click this link:
> <https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=80289>
> If you lost your SourceForge.net login name or password, refer to this document:
> <https://sourceforge.net/docman/display_doc.php?docid=760&group_id=1>
>
> Note that you may receive this message indirectly via one of your mailing list
> subscriptions. Please review message headers before reporting unsolicited
> mailings.
>   

Re: [ojAlgo-user] Black-Litterman Model Prototype Application URL

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

Our ISP has had all sorts of problems today. I think everything works 
now. Please try again...

/Anders

Raul Lacaci wrote:
> Hi,
>  
> I am interesting in take a look to Prototype Application. I have tried 
> http://213.64.190.169:8080/BLApp/ but it doesn't works, Can anyone 
> plese send me the correct url?
>  
>  
> Thanks in advance
>  
>  
> Raul Lacaci
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>