On 05/04/2009, Luc Maisonobe <luc.maison...@free.fr> wrote: > sebb a écrit : > > > On 05/04/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > >> sebb wrote: > >> > >>> On 04/04/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > >>> > >>> > >>>> sebb wrote: > >>>> > >>>> > >>>> > >>>>> On 04/04/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Luc Maisonobe wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> A lot of work has been done on [math] last months. > >>>>>>> There are 9 issues still open in Jira with a target set to 2.0. > >> Some > >>>>>>> > >>>> of > >>>> > >>>> > >>>>>>> them have already been almost processed, some could be finished > >> soon, > >>>>>>> some could be postponed to 2.1. > >>>>>>> > >>>>>>> What do you think about preparing to release 2.0 in the next few > >> weeks > >>>>>>> > >>>> ? > >>>> > >>>> > >>>>>>> I volunteer to do the realese work. For those of you who have > >> taken > >>>>>>> > >>>> the > >>>> > >>>> > >>>>>>> burden of the remaining issues, do you intend to complete your > >> work on > >>>>>>> them or do you prefer I assign them to me and close what I can do > >> ? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> I am +1 on pushing out 2.0. Here are some comments on the issues > >>>>>> > >>>>>> > >>>> assigned > >>>> > >>>> > >>>>>> to me. My geologic-time progress is unfortunately not likely to > >> improve > >>>>>> over the next couple of weeks, so I am more than happy to let others > >>>>>> > >>>>>> > >>>> jump > >>>> > >>>> > >>>>>> in. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> Math is now dependent on Java 1.5 (according to the pom), but there > >>>>> seem to be quite a few missing @Override annotations. There are also > >>>>> some raw types. Of course these are not essential, but they would > >>>>> help. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> I don't see either of these as essential and regarding the raw types, I > >>>> would prefer to limit the changes that are not backward-compatible. > >>>> > >>>> > >>> What do you mean by backward-compatible here? > >>> Do you mean compile-time or run-time? > >>> > >>> > >>> > >> Both. I want to minimize the impact of the upgrade to users. > > > > The code already uses some 1.5 features, e.g. enum and autoboxing. It > > also already uses parameterized types, just not everywhere. I think > > it's too late for compile-time compatibility with 1.4. > > > > Regarding raw types, the types are erased at run-time anyway. I think > > the only affect on user code would be to generate some compile-time > > warnings. I don't think it will stop code working. Anyway, the code > > already uses non-raw types, it's just that some raw types have yet to > > be converted. > > > I'll get the @Override annotation fixed soon. > > Regarding raw types, I've tried to fix some of them some months ago and > stopped when I reached a problem with Frequency.java. In this specific > case, I found no solution (even using <?>) since the class already > handles its content specifically. Getting a completely type safe class > would require changing the semantics and perhaps using dedicated > internal storages of which only one could be active once the first > element has been put in (one for int, one for char, one for long and one > for Object). This seemed weird to me so I stopped thinking about it. > > How do you suggest to address the issue for this specific class ?
I see what you mean about the Frequency class. [I'd not noticed, but it is now the only one with raw types] I feel it ought to be possible without changing the API, but I've not yet tried. After all, HashMap can still be used with raw types, or one can use the type-safe version. Assumimg that it is possible to parameterize the class, the the test cases would need to be extended to add type-safe versions of the existing test cases. But first one would need to ensure that the exisiting test cases are complete - I don't think this is so. For example, there's no check to show what happens when int and char are mixed. Depending on how one reads the class Javadoc, this should be allowed, as one can compare "int" and "char" in the same way that one can compare "int" and "long" - i.e. both are "comparable". Now "int" and "char" are not Comparable, but then neither are "int" and "long". I think the Javadoc needs to make the intention clear, and then the tests can be enhanced to enforce the documented behaviour. > > > Luc > > > > > >> Phil > >> > >> > >>>>> Also, what about thread-safety? There are a few Synchronized classes, > >>>>> which are presumably intended to be thread-safe. I'm not sure it's > >>>>> particularly necessary to have thread-safe Math classes, so long as > >>>>> the classes are not thread-hostile (there's at least one such; I'll > >>>>> file a JIRA shortly), but it would be useful to document which classes > >>>>> are which. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> +1 to add general comments to user guide and web site. > >>>> > >>>> > >>> I'd like to see the individual class Javadoc include the details as > >>> well, but that could be added in due course as it will take a while. > >>> > >>> > >>> > >>>>> > >>>>>> MATH-207 - I am close to committing David's great patch with only > >> minor > >>>>>> modifications and that should make us pretty much complete from code > >>>>>> perspective for the initial genetics release, modulo comments on the > >> API > >>>>>> that may still come in. What will remain on this is user guide > >> update. > >>>>>> Patches welcome! > >>>>>> MATH-114 - User guide update is all that remains. I should be able > >> to > >>>>>> > >>>> do > >>>> > >>>> > >>>>>> that. > >>>>>> MATH-136 - I would like to get this in, but there is some work > >>>>>> > >>>>>> > >>>> involved. > >>>> > >>>> > >>>>>> +0 to moving to 2.1 > >>>>>> MATH-169 - pushed to 2.1 > >>>>>> > >>>>>> I will look at MATH-197 if Brent does not catch this. > >>>>>> > >>>>>> MATH-194 is a can of worms that we should collectively open and > >> clean > >>>>>> > >>>> up. > >>>> > >>>> > >>>>>> I suppose I should open an issue to track it, but the general > >> problem > >>>>>> > >>>> of > >>>> > >>>> > >>>>>> the multiple regression API being incomplete and the GLS class being > >>>>>> numerically suspect makes me think we may want to hold at least the > >> GLS > >>>>>> class from the release. I will see what I can do. I am leaning > >> toward > >>>>>> flattening the hierarchy, adding some basic stuff to the OLS class > >> and > >>>>>> releasing just that class. I will start a separate thread on this > >> issue > >>>>>> when I have a plan. > >>>>>> > >>>>>> > >>>>>> Thanks for volunteering for the RM duty! > >>>>>> > >>>>>> Phil > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Luc > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> --------------------------------------------------------------------- > >>>> > >>>>>> > >>>>>>> To unsubscribe, e-mail: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> dev-unsubscr...@commons.apache.org > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >> --------------------------------------------------------------------- > >>>> > >>>>>> To unsubscribe, e-mail: > >>>>>> > >>>>>> > >>>> dev-unsubscr...@commons.apache.org > >>>> > >>>> > >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >> --------------------------------------------------------------------- > >>>> > >>>>> To unsubscribe, e-mail: > >>>>> > >>>>> > >>>> dev-unsubscr...@commons.apache.org > >>>> > >>>> > >>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: > >> dev-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>> > >>>> > >>>> > >>>> > >>> > >> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: > >> dev-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
