Le 24/03/2012 20:12, Thomas Neidhart a écrit :
> On 03/24/2012 07:33 PM, Luc Maisonobe wrote:
>> Le 24/03/2012 17:35, Thomas Neidhart a écrit :
>>> On 03/24/2012 05:29 PM, Luc Maisonobe wrote:
>>>> Hi all,
>>>>
>>>> I have tried to tell Jira th
Le 24/03/2012 17:35, Thomas Neidhart a écrit :
> On 03/24/2012 05:29 PM, Luc Maisonobe wrote:
>> Hi all,
>>
>> I have tried to tell Jira that version 3.0 of [math] has already been
>> shipped, but I don't find how to do it. Some pages tell me I should
>>
in advance
Luc
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
ce for this.
When the component has reached a state where another release is worth
doing, then asking for such a release on the dev list and helping in
freezing the code and polishing it is greatly appreciated.
>
> We are more than happy to assist in Commons Math releases, if th
equality). */
> +private boolean bIsNull;
> +
> +static {
> +MACH_PREC = Math.ulp(1.);
> +CBRT_MACH_PREC = Math.cbrt(MACH_PREC);
Why not using FastMath ?
Luc
> +}
> +
> /**
> * Creates and inits to k = 1
a third document, these recent notes
should replace the existing pages and get linked to everything else.
Otherwise we would end up with 3 documents and another release manager
candidate would stumble upon an old one, then create a fourth document,
then be pointed to this one and say he didn't
to me, so +1.
Luc
>
> This is a VOTE to release Commons IO 2.2-RC1
>
> This VOTE is open for at least 72 hours until March 19 2012 at 01:30 EST.
>
> The files:
>
> https://repository.apache.org/content/repositories/orgapachecommons-080/
>
> The tag:
>
> h
ot; resulting from the comparison.
This allows for example to retrieve only the shared elements, or only
the ones in the first or the second sequence, or "running" the script,
or whatever.
If you consider this could be a good addition to [lang] or another
component ([graph] ?) I can ask for
y done,
but still access to individual fields) is a must.
>
>> 2. Add a parser returning a Map instead of a String[]
>>
>> // declare the header in the format,
>> // the header line will be parsed automatically
>> CSVFormat format = CSVFormat.DEFAULT.withH
policy on JIRA issues is that we mark them as
resolved when the fix is available in the subversion repository, and we
mark them as closed when the fix has been released in an official version.
Luc
> Best regards,
> Sébastien
>
>
> --
unnecessary. Surely we should only offer Javadoc for
> current releases?
I agree. These versions are really old now and we don't get any requests
from user about them.
Luc
>
> -
> To unsubscribe, e-mail: dev-
vers").
I guess almost the same methods could be used, except either only one
solve method would be needed with a single start value, or min/max
interval definition should be replaced by a two-dimensional rectangle
definition.
Luc
>
>
> Best regards,
> Gilles
>
throw everything they find the binary
distribution in.
> That will have to be done by each component as it will usually require
> an edit to the assembly descriptor.
> But in any case the jars would be available fro
almost don't support serialization. In the
few places where it is supported, we should not guaranteed any
cross-version compatibility.
best regards,
Luc
>
> Sorry if this is a silly question, and thanks in advance for your help!
> Best regards,
> Sébastien
>
> [1] Thinkin
fixes in this release can be found in the
> release notes:
> http://www.apache.org/dist/commons/math/RELEASE-NOTES.txt
>
>
> Best regards,
> Gilles
> on behalf of the Apache Commons community
Great work, Gilles, thanks a lot!
Luc
>
> --
release it because ...
>>
>> This vote will close in 72 hours (2012-3-8 10:30 GMT).
>>
>
> The results are:
>
> ---+-
>Name| Vote
> ---+-
> Luc Maisonobe |+1
> Oliver Heger |
- Handle CSV headers, a CSV API looks incomplete to me without this
> - Examine the feasibility of adding a simple bean mapping feature
> - Extract the unicode unescaping feature as an implementation of
> java.io.Reader, and maybe contribute it to Commons IO
> - Improve the docum
o use in their
> application then it is definitely time to do a release of CSV.
I'll update our report for this month.
Luc
>
> Ralph
>
> On Mar 6, 2012, at 8:51 AM, Emmanuel Bourg wrote:
>
>> The Solr team isn't listening, the issue was closed as "Wo
d library. See
<http://www.apache.org/legal/resolved.html#category-x>.
We have to either implement the code from scratch using only reference
paper or translate code that is published under a compatible license.
Luc
>
>
>
r/math/tags/MATH_3_0_RC3/
>
> Site:
> http://people.apache.org/builds/commons/math/3.0/RC3/
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-053/org/apache/commons/commons-math3/3.0/
>
> [X] +1 Release it.
Thanks Gilles,
Luc
> [
e been solved later on but we failed to bring the reports back.
It would be nice. Would this only mean adding a plugin in the pom ?
Luc
>
> Gary
>
> On Sun, Mar 4, 2012 at 8:27 PM, Gary Gregory wrote:
>
>> On Sun, Mar 4, 2012 at 8:07 PM, sebb wrote:
>>
>>&
experimental in the release notes with some code
paths untested. The other ones are related to encoding but have been
there for years (older findbugs did not detect them). So both can be
considered acceptable for this release.
Luc
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few
Le 04/03/2012 16:10, Luc Maisonobe a écrit :
> Le 04/03/2012 15:30, Gilles Sadowski a écrit :
>> On Sun, Mar 04, 2012 at 08:55:09AM -0500, Gary Gregory wrote:
>>> The RAT report complains about a couple of Java files.
>>
>> Thanks for pointing this out (I had
we could just stamp them
> with the Apache license.
> * CSS files for the Commons web site
The data and css file are no problems.
The Java files are a problem. I'll fix that in trunk so you can copy
them to a new tag.
Luc
>
>
> Please advise,
> Gilles
>
't know if this should be considered a blocker or not, hence the -0.
Also note that Nexus automatically adds md5 and sha1 checksum to the asc
signature files. These signatures on signatures are spurious and should
be manually removed from Nexus staging area.
Anyway, this is a very good job,
ional projects that need it really really soon.
Delaying the release would be a very negative sign.
The current state of 3.0 is good. It has been used for months by
numerous users, but now some of them need an official release, they
cannot rely on a development snapshot any longer.
We must relea
d "setStepsizeControl" (note the spelling) intended to override
> "setStepSizeControl" defined in the parent class?
No, this is a completely different method. The name and signature
similarity was unfortunate ... I have renamed this method.
Fixed in r1295772.
Sorry for the conf
ons, decimals). I would like to contribute this new
> class to CM (3.1). This class could be called Decimal64 (together with
> the corresponding Decimal64Field), and could go to the o.a.c.m3.util
> package.
>
> Do you think this might be a useful addition to Commons-Math?
Yes, I think
e should be
> considered as an API change. If yes, I would recommend we do it before
> releasing 3.0. Otherwise, I can do that in 3.1, together with checkng
> that when an exception is thrown, it is always of the same type.
>
> What do you think?
+1 to remove the statement.
Luc
>
gt; Yes. That's what I said.
>>
>>> But that's not the point;
>>
>> Yes, that's the point.
>>
>>> since the arrays were (at your insistence)
>>> moved out of FastMath itself, this necessarily meant exposing the
>>> contents to
open for at least 72 hours).
>
> Apache Commons Daemon 1.0.10 is
> [X] +1 Release
Luc
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
>
> [1] http://people.apache.org/~mturk/daemon-1.0.10/
> [2] http:
se this release because...
I'm sorry, but I got the following compilation error on a Linux box
running Debian on AMD64:
(lehrin) luc% tar xzf commons-daemon-1.0.10-src.tar.gz
(lehrin) luc% cd commons-daemon-1.0.10-src/src/native/unix
(lehrin) luc% JAVA_HOME=/usr/lib/jvm/java-6-openjdk-amd64 ./co
ay into account (plus one or two days as a safety
margin) and it must be updated as each release candidate is cut.
So there is no predefined release date until the vote finally passes.
At the pace at which you go now, I would say we could target a first
release candidate early next week.
ady a few example of names with non-ASCII characters in
this file.
Luc
>
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
Le 19/02/2012 09:50, Benedikt Ritter a écrit :
>
> Am 18.02.2012 um 19:06 schrieb Ralph Goers :
>
>>
>> On Feb 18, 2012, at 8:54 AM, Luc Maisonobe wrote:
>>
>>> Le 18/02/2012 17:27, Gary Gregory a écrit :
>>>> On Feb 18, 2012, at 11:00, Oliver He
Le 18/02/2012 17:27, Gary Gregory a écrit :
> On Feb 18, 2012, at 11:00, Oliver Heger wrote:
>
>> Am 18.02.2012 15:25, schrieb Ralph Goers:
>>>
>>> On Feb 18, 2012, at 3:20 AM, Luc Maisonobe wrote:
>>>
>>>> Le 17/02/2012 23:30, Ralph Goers a éc
commons use the same
>>> checkstyle configuration.
>>>
>>
>> +1, that would be great, we could put it in the parent POM and be done with
>> it once and for all.
Are we sure all components use the same style ?
The checkstyle.xml file for [math] origin has ev
Le 16/02/2012 11:13, Simone Tripodi a écrit :
> Hi all guys!
>
> does anyone have enough rights on JIRA to add Claudio & Marco in the
> Commons group?
This has already been done when their account has been setup.
Didn't it work ?
Luc
>
> Many thanks in advance, all
ent but
> isn't set by deserialization
> ---CUT---
OK. The consensus seems to be to not make everything serializable.
Do we set Serializable on a case by case basis (hence solving issue
MATH-742) ?
Luc
>
>
> Regards,
> Gilles
>
>
here?
It's a bug.
It's a small one and I'll fix it in a few minutes, don't bother creating
a Jira issue for it.
thanks for the report.
Luc
>
> Best regards,
> Dennis
>
> -
> To unsubscribe
de for
checkstyle, and using findbugs-exclude.xml file for findbugs. I don't
known about PMD.
Luc
> Sébastien
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For addit
ath3"
>
Great, we are going forward!
Thanks to everyone in the team,
Luc
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
to know how to
>>>>>> modify that code so that it will behave correctly when only one of the
>>>>>> bounds is infinite (a valid case allowed by the base class for
>>>>>> optimizers
>>>>>> with simple bounds: "BaseAbstr
Le 11/02/2012 13:17, Benedikt Ritter a écrit :
> Am 10.02.2012 17:34, schrieb Luc Maisonobe:
>> Le 10/02/2012 15:22, Mladen Turk a écrit :
>>> On 02/07/2012 01:52 PM, Mladen Turk wrote:
>>>>
>>>> Votes, please. This vote will close in 72 hours
>>&g
Le 11/02/2012 11:25, sebb a écrit :
> On 11 February 2012 09:26, Luc Maisonobe wrote:
>> Hi,
>>
>> Le 11/02/2012 05:10, Bill Barker a écrit :
>>> While the development team has exploded for [MATH], maintaining
>>> Serializable interfaces is expensive a
nce
again, it's not an absolute rule which should be done in one sweep, it's
more a small low priority regular task to add serialize here and there
as we see.
Luc
>
> -Original Message- From: Gilles Sadowski
> Sent: Friday, February 10, 2012 11:40 AM
> To: de
ppose this release because...
>>
>
> Just to record my vote.
>
> Since 72 hour period exceeded, suppose I'll just
> declare this release as not passed cause I was not been
> able to collect enough +1 votes.
Sorry, I missed that.
+1 fro
ava 5 seems rather out of date
and Java 6 is fully deployed.
Luc
>
> Thank you,
> Gary
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
efully not cluttering the code which they don't have to test very
> often...
The unwritten consensus here for the last few months seems to be: there
are different points of view which cannot be reconciled. So we gave up
on achieving consistency and everyone does as he sees fit.
Thomas and
d a
completete application (an apk). So I don't know if the file would have
been preserved by the complete build tool or not.
>
>> The current directory, lying under META-INF, was stripped out because
>> some build/conversion tools considered they own META-IN
Le 09/02/2012 17:33, Gilles Sadowski a écrit :
> On Thu, Feb 09, 2012 at 05:13:14PM +0100, Luc Maisonobe wrote:
>> Hi,
>>
>> Some times ago, we had a discussion about some issues with Android
>> devices. One issue was that the packaging system for Android did remove
&g
assets/localization, to better match Android (but not completely as we
do not use their specific localization API and associated xml files).
If we need other resources, they should also be put under this "assets"
directory.
What do you th
.xml and contributors in the POM instead.
>>>>
>>> OK, my mistake.
>>> I was conforming with what I saw in existing files. So should the
>>> svn:keywords property read "Id", or "Id Revision"?
>>
>> Both Id and Revision are fine,
e.org/dev/cms>).
There have been several threads about changing our project site skin
recently.
Can we pack all this together and make sure we get ready for this change
? Any volunteers ?
best regards,
Luc
-
To unsubscribe,
Le 09/02/2012 10:50, Sébastien Brisard a écrit :
> Hi Luc,
>>
>> I agree with you, enums are much better. There are other places in
>> [math] where we use boolean or even ints for such things. They mainly
>> came for pre-java 5 era when enums where not available.
>
x only.
I am slightly reluctant to change FieldElement to an abstract class.
What do other people think about this ?
Luc
> * Alternatively, may I introduce a NumberFieldElement which extends
> both Number and FieldElement? In this case, I would recommend that
> BigFraction, BigReal, Complex
], TransformType).
> What do you think?
I agree with you, enums are much better. There are other places in
[math] where we use boolean or even ints for such things. They mainly
came for pre-java 5 era when enums where not available.
Luc
>
> Sébastien
>
> PS: thinkin
you check if it works ?
best regards,
Luc
> -Simo
>
> [1] http://people.apache.org/committer-index.html#stevendolg
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitte
ed to Java 5
and Java 6 about JVM optimization, and small objects are not really
costly now. I do trust JVM implementors here and really like using small
immutable objects.
>
> I remember we recently had this conversation on the ML: one of Gilles
> or Luc argued that for very low-level algor
ather than won't fix, I would prefer simply postponing the issue to 3.1.
Luc
>
> Do you agree with this proposal?
> Sébastien
>
> PS: my lab does not subscribe to ACM. Does anyone have access to this paper
> TRANSACTIONS ON MATHEMATICAL SOFTWARE,
> VOL. 18, NO. 3, SEPTE
se warnings are, and I'm pretty sure that
> those problems were present in 1.3, so I think that means they're
> probably not a blocker!
OK, then +1 from me.
Luc
>
> Nick
>
> -
> To unsubscribe, e-ma
27;d rather
> postpone those remaining changes.
> What do you think?
If the current status seems stable enough for you, then we should
release it in this current state for the time being and discuss once 3.0
is out.
Luc
> Sébastien
>
>
> -
MediumClass org.apache.commons.validator.ValidatorAction defines
> non-transient non-serializable instance field validationMethodBAD_PRACTICE
> SE_BAD_FIELD<http://findbugs.sourceforge.net/bugDescriptions.html#SE_BAD_FIELD>Not
> availableHigh
I'm not sure either about
+1
thanks,
Luc
Le 01/02/2012 07:05, Simone Tripodi a écrit :
> +1 too Oliver, great work!
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
&
-> "UnivariateIntegrator"
>
> Also, the class "UnivariateRealIntegratorImpl.java" should be renamed. In
> addition to removing the "Real" part from the name, I would change it to:
> "BaseAbstractUnivariateIntegrator"
>
e seem to lack the skills to
understand these failures. Perhaps we could ask ourselves for help on
the users list ? We could ask for someone knowledgeable to check our
code, our tests, and the tests that fail in order to identify the
Le 27/01/2012 20:44, Sébastien Brisard a écrit :
> Hi Luc,
> thanks for this answer.
>>>
>>> My problem is that I do not know what getSolverAbsoluteAccuracy()
>>> should return. I see three options
>>> 1. Have getSolverAbsoluteAccuracy() throw an
>>&
of expertise to come
> up with this estimate... Any help would be most welcome!
I don't like UnsupportedOperationException. In this case, I would say
the explicit formula is some kind of "perfect" solver which has a
theoretical accuracy of zero (or 1 ulp). So I would return this v
code so that it will behave correctly when only one of the
>>>> bounds is infinite (a valid case allowed by the base class for optimizers
>>>> with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>>>
>&
take me forever (even if it must be done in the end by one of
> us, I suppose).
As strange as it might seem, I would like to see this code part of 3.0
with a big "experimental" flag on it. People can use it at their own
risk, but they can also help improve it.
Luc
>
>>
Le 26/01/2012 15:39, Gilles Sadowski a écrit :
> Hello.
>
>>> It thus becomes urgent to tackle the remaining blocking issues.
>>> Can we please make a list of those, and of all practical matters that
>>> prevent the preparation of the release?
>>>
>>>
>>> Thanks and best regards,
>>> Gilles
>>>
>>
so we can borrow
some code from Orekit and push it into any Commons components.
Orekit does handle duration, even taking into account non-regular time
scales like UTC (i.e. it knows how to handle leap seconds introduction
for time range that extend across a leap second).
I can help on this if you
%7E+FieldElement%29
>
> it might be the time to work in the proposed direction. As I am not familiar
> with the ACM solution and conclusion finding and decision making, please make
> proposals on how we could work together, if you have interests in the same
Le 15/01/2012 10:26, Sébastien Brisard a écrit :
> Hello Luc and Gilles,
> thank you for taking part in this discussion.
>>
>> Hi Sébastien,
>>
>>>
>>>>
>>>> I used to do that when we still had a single root hierarchy. Changing
>>>&
not
>> interfaces, we can even not declare some intermediate MathThrowable
>> interface that would extend RuntimeException in production distribution
>> and could be changed to extend Exception in developers works spaces to
>> ensure javadoc and throws statements are up to d
must be kept in sync manually; this is a burden and has no benefit.[1]
> Unchecked exceptions must be documented in Javadoc, but should not appear in
> method signatures (at least, not systematically).
>
>
> Best regards,
> Gilles
>
> [1] Luc likes to have the exception in t
st.java
> (with props)
You should probably also change the NOTICE file to include the licence text
from the original code.
Luc
>
> Added:
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java
> URL:
> http://svn.apache.or
Le 08/01/2012 12:11, Christian Grobmeier a écrit :
> On Sun, Jan 8, 2012 at 6:21 AM, Ralph Goers
> wrote:
>>
>> On Jan 7, 2012, at 11:44 AM, Luc Maisonobe wrote:
>>
>>> Le 07/01/2012 15:36, Gary Gregory a écrit :
>>>>>
>>>>
>>>
ahead.
This would be a wonderful thing to have.
Please go ahead !
Luc
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional comman
>>
>> You realize that for submodules this will only work with M3, profile
>> activation fails for M2?
>
> When can we drop support for M2?
I guess there are still a lot of m2 users, and for the next few years
there will still be many. At least when I run an "
Le 04/01/2012 10:06, Sébastien Brisard a écrit :
> 2012/1/4 Luc Maisonobe :
>> Le 04/01/2012 02:21, Sébastien Brisard a écrit :
>>> Hi,
>>> I'm currently working on MATH-677 (cleaning-up o.a.c.m.transforms). I
>>> notice that all classes in this package
where I should move it to?
> Options I can think of are
> 1. org.apache.commons.math.util.MathArrays
> 2. org.apache.commons.math.util.FunctionUtils (to be created)
> 3. your own suggestion
I would propose MathUtils, but if other similar functions arise, maybe a
new FunctionUtils wou
ere are pointers back and forth between various parts (step handlers,
events handlers, integrator ...) many classes in this package must be
serializable. I guess similar rationale may apply to other packages.
Luc
>
> Sébastien
>
>
> -
2/
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-006/
>
> The link above includes checksum files.
>
> [X] +1 release it
Luc
> [ ] +0 almost, please fix:
> [ ] -1 no because:
>
> This VOTE is open for at least 72 h
quare test.
>
> I'm not very familiar with this part of CM, and would very much like
> to know what you think.
I am sorry not to have any time to look at this these days.
Well 1024 has been checked with respect to the reference C
implementation though. Perhaps we should check it again.
L
nit4TestSet.execute(JUnit4TestSet.java:35)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115)
>>at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
>>at sun.reflect.N
I
removed Phil yesterday and the current page takes this change into account).
How is the other page (<http://commons.apache.org/team-list.html>)
generated ? We should update it.
Luc
>
> Cheers
>
> On Tue, Dec 27, 2011 at 7:39 PM, Gary Gregory wrote:
>> Part 1: This
,
these reports should be forwarded to the developers list. This is a way
for the PMC to provide an executive summary to all people interested in
the project development and show the achievements of our community. So
here is the report we sent to board for its December meeting and which
was approved.
Luc
Le 23/12/2011 11:15, Christian Grobmeier a écrit :
> On Fri, Dec 23, 2011 at 10:52 AM, Luc Maisonobe wrote:
>> Le 23/12/2011 09:32, Christian Grobmeier a écrit :
>>> I want to mention that I have reserved the G+ brand page "Apache Commons"
>>> https://
Is this compatible with Apache trademark policy ? I think we should
probably ask Shane about this (he is Apache VP Brand Management).
Luc
>
> Let me know.
>
> Cheers
> Christian
>
-
To unsubscribe, e-mail:
fixed by someone here (Phil?) or do we have to ask INFRA
> for
> help?
Could you check again now ? I have added you to the required group.
Luc
>
> Emmanuel Bourg
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@
g. I don't see being ready for a release as a
> hard requirement, but I do see the need for more than one active
> committer and Ideally 3 or more before something gets promoted. Are
> the people voting +1 planning to commit on [graph]? Are there
> others?
I voted +1 des
rom me). If
later on the community fades away, then the component will move away,
it's OK.
Luc
> I am interested, but I don't know how much
> hands-on time I'll have for it. If we get it to a mature state and let it
> prove itself a bit first, I think it has a better ch
t me know if there
> is anything I should change/correct.
I have only skimmed through it, as I don't have the required skills.
This looks fine to me, and consistent between the several available
transforms.
Great work, thanks!
Luc
> Thanks!
>
> Sébastien
>
>
> ---
Site:
>> http://people.apache.org/~psteitz/pool-1.5.7-rc3/docs
>> (Links, including an added link to the released API docs, will be
>> updated post release)
>>
>> Tag:
>> http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_7_RC3
>>
>> Vot
ess for moving to attic, but I don't think this
is what you want. I think there is also a general process to become a
TLP. This is exactly what commons did some years ago, coming from Jakarta.
Luc
>
> What exactly do you mean? Make JEXL a top level project or move JEXL
> to ano
o others think?
I think it would be OK to release as 2.1, but if anybody else think 3.0 is
better, then go for it.
Luc
>
> Assuming that there are no objections, there is the question of what
> version to use.
>
> The changes clearly require at least a minor version bump,
Le 01/12/2011 20:21, l...@apache.org a écrit :
> Author: luc
> Date: Thu Dec 1 19:21:11 2011
> New Revision: 1209198
>
> URL: http://svn.apache.org/viewvc?rev=1209198&view=rev
> Log:
> Updated patch from original contributor.
>
> Modified:
>
> common
even subnormals do not exist. Our
fractions are both closer to the mathematical Z set and to the computer science
int primitives pairs than to double. There is a conversion method doubleValue,
but it should rather be considered
d stable when I
started. It took 6 RC before pushing it out.
You are quite close now, there was only one comment about the artifacts.
thanks for your efforts,
Luc
>
> Matt
>
>>
>> I always make a mini-mess of RCs. I just try again. And again. Until I get
>> it righ
701 - 800 of 1770 matches
Mail list logo
