ojalgo-user

[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] 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

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. <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