[jira] [Created] (LANG-1444) NumberUtils.createNumber() does not create BigDecimal for decimal fractions tending to zero
Costa Theodosiou created LANG-1444:
--
Summary: NumberUtils.createNumber() does not create BigDecimal for
decimal fractions tending to zero
Key: LANG-1444
URL: https://issues.apache.org/jira/browse/LANG-1444
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.8.1
Reporter: Costa Theodosiou
The following code demonstrates the issue:
{{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
{{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
will print:
{{java.lang.Float}}
{{java.lang.Float}}
{{java.lang.Float}}
{{java.lang.Float}}
{{java.lang.Double}}
{{java.lang.Double}}
{{java.lang.Double}}
{{java.lang.Double}}
{{java.lang.Float}}
{{java.lang.Float}}
{{java.lang.Float}}
{{java.lang.Float}}
It seems the problem is towards the bottom of the createNumber method that
compares the float to double string representation:
f.toString().equals(d.toString())
For the misbehaving tests, the string "1.0".equals("1.0")
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-98) Port commons-math.linear to commons-numbers.linear
[ https://issues.apache.org/jira/browse/NUMBERS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812020#comment-16812020 ] Eric Barnhill commented on NUMBERS-98: -- I do not have another take on it, and agree with Gilles. This proposal is as they say "short on specifics". It is mostly just a rewrite of the ticket. But what is needed for the proposal is a strategy for solving the problem the ticket describes. And this Ting's proposal does not provide. > Port commons-math.linear to commons-numbers.linear > -- > > Key: NUMBERS-98 > URL: https://issues.apache.org/jira/browse/NUMBERS-98 > Project: Commons Numbers > Issue Type: Task >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019 > > Apache commons is one of the most widely used supplementary resources by Java > programmers and its mathematical functions are widely used. > Basic operations of linear algebra such as matrix factorization are not only > in use in scientific and technical fields but widely in industry, and an > accessible and standalone library for this functionality would have a wide > potential audience. > This ticket is in three parts: > # Port the libraries from commons-math.linear into commons-numbers.linear, > removing unnecessary layers of abstraction and creating a simple, intuitive, > standalone library. > # The developer should familiarize themselves with best bractices in linear > algebra such as those in the EJML, and redevelop the linear library to > contain best practice implementations. > # The developer should work with developers of other math and statistics > projects to integrate their work where it can benefit those projects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[
https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812011#comment-16812011
]
Mukul chand yadav commented on STATISTICS-7:
[~ericbarnhill] [~virendrasinghrp]
Myself Mukul pursuing master's in computer science majoring in ML, would love
to contribute to overhaul of {{org.apache.commons.math4}} package using Java
8's functional APIs where I can leverage my experience of developing stream
based APIs.
Based on discussion here, please let me know if I need to consider any other
details before making a formal proposal on GSOC19 portal.
> Stream-based Java statistical processing
>
>
> Key: STATISTICS-7
> URL: https://issues.apache.org/jira/browse/STATISTICS-7
> Project: Apache Commons Statistics
> Issue Type: New Feature
>Reporter: Eric Barnhill
>Priority: Major
> Labels: GSoC2019, gsoc2019, statistics, streams
>
> The new component aims to be a library of commons statistics functions
> synchronized with the latest developments in the Java language, in particular
> Java's functional programming syntax.
> The library will make commonly used statistical functions available to an end
> user through a simple grammar comparable to commons-math-statistics or
> scikit-learn, while under the hood will implement Java's mapping, streaming,
> and other producer and consumer functions to ensure the statistical methods
> run optimally in new Java implementations.
> As functional programming grows increasingly central to big data applications
> we believe these libraries will play an important function in the data
> engineering ecosystem. In particular, data engineering is widely done with
> Java, then passed to other languages for data-scientific analyses; however,
> the common availability of functionally implemented statistical mapping and
> reductions in Java could prove very useful at the interface of data science
> and engineering, by enabling teams to more easily perform reductions on the
> engineering side before handing off to the analysis side.
> Developers working on the project will have the opportunity to demonstrate
> Java programming, functional programming, algorithm design, and data science
> skills and receive authorship on a commons project that is likely to be
> widely used.
> The ideal contributor will also be able to help with important architectural
> decision making. The old source of these libraries, commons-math, grew too
> large, hierarchically complex and interdependent for the commons mission. The
> developers on this project need to make architectural choices that will
> enable the statiscal code to be lightweight and reusable, with a minimum of
> outside dependencies while avoiding redundancy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811962#comment-16811962 ] Virendra Singh commented on STATISTICS-7: - Yes, [~ericbarnhill] I received your feedback & I am studying the topics you mentioned in the mail. I've already forked the repositories from GitHub and once I finish studying and designing the flow, I'll start contributing. As of now, I've submitted the draft as my final proposal. Is that okay? If you recommend any change, I'll do that. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > As functional programming grows increasingly central to big data applications > we believe these libraries will play an important function in the data > engineering ecosystem. In particular, data engineering is widely done with > Java, then passed to other languages for data-scientific analyses; however, > the common availability of functionally implemented statistical mapping and > reductions in Java could prove very useful at the interface of data science > and engineering, by enabling teams to more easily perform reductions on the > engineering side before handing off to the analysis side. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-98) Port commons-math.linear to commons-numbers.linear
[
https://issues.apache.org/jira/browse/NUMBERS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811878#comment-16811878
]
Gilles commented on NUMBERS-98:
---
Hi [~Ting223].
Thanks a lot for your interest in this project.
We certainly need to tackle the linear algebra issue; however the "how" is not
clear to me; then, somehow, this JIRA ticket escaped my attention, and we don't
have enough time left to discuss/research the implications and their impact on
your GSoC proposal...
Also because some aspects will require more opinions, the discussion must be
brought to the "dev" mailing list of the "Commons" project.
Indeed, the fundamental question is: Do we still want/need/have to implement
linear algebra within Commons, knowing that several alternative matrix algebra
Java projects have appeared (or evolved a lot) since this report collected many
issues of "Commons Math" package {{org.apache.commons.math3.linear}} (a.o. the
mentioned EJML)?
Depending on the answer, your task list would either grow too large
(implementing a full-fledged linear algebra library needs a plan, not just the
intention to "Port and redevelop the libraries of [the linear package]"),
or shrink to almost nothing since we'd just _use_ EJML. [And we might indeed
do that (details TBD) for providing the necessary functionality to advance the
tickets mentioned in the STATISTICS project].
In light of this, and unless [~ericbarnhill] has another take on it, I suggest
that you modify your proposal. A high priority task is to work towards the
first official release of "Commons Numbers". Would you consider the [more
concrete (but diverse) list of tasks that should be
resolved|https://issues.apache.org/jira/issues/?filter=12345517&jql=project%20%3D%20NUMBERS%20AND%20labels%20%3D%20gsoc2019%20AND%20text%20~%20numbers]
to that end?
> Port commons-math.linear to commons-numbers.linear
> --
>
> Key: NUMBERS-98
> URL: https://issues.apache.org/jira/browse/NUMBERS-98
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Eric Barnhill
>Priority: Major
> Labels: GSoC2019, gsoc2019
>
> Apache commons is one of the most widely used supplementary resources by Java
> programmers and its mathematical functions are widely used.
> Basic operations of linear algebra such as matrix factorization are not only
> in use in scientific and technical fields but widely in industry, and an
> accessible and standalone library for this functionality would have a wide
> potential audience.
> This ticket is in three parts:
> # Port the libraries from commons-math.linear into commons-numbers.linear,
> removing unnecessary layers of abstraction and creating a simple, intuitive,
> standalone library.
> # The developer should familiarize themselves with best bractices in linear
> algebra such as those in the EJML, and redevelop the linear library to
> contain best practice implementations.
> # The developer should work with developers of other math and statistics
> projects to integrate their work where it can benefit those projects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (EMAIL-186) Commons Email does not provide automatic module name
[ https://issues.apache.org/jira/browse/EMAIL-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Petrovicky updated EMAIL-186: --- Description: At the moment, commons-email is a thorn in one's side when it comes to JPMS. At the very least, it should give a [stable automatic module name|http://branchandbound.net/blog/java/2017/12/automatic-module-name/] in the JAR file's manifest. I can provide a PR fixing this, but judging by the state of EMAIL-183, this project looks like it is dead and people should instead be discouraged from using it. was: At the moment, `commons-email` is a thorn in one's side when it comes to JPMS. At the very least, it should give a [stable automatic module name|http://branchandbound.net/blog/java/2017/12/automatic-module-name/] in the JAR file's manifest. I can provide a PR fixing this, but judging by the state of EMAIL-183, this project looks like it is dead and people should instead be discouraged from using it. > Commons Email does not provide automatic module name > > > Key: EMAIL-186 > URL: https://issues.apache.org/jira/browse/EMAIL-186 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Lukas Petrovicky >Priority: Critical > Fix For: 1.6 > > > At the moment, commons-email is a thorn in one's side when it comes to JPMS. > At the very least, it should give a [stable automatic module > name|http://branchandbound.net/blog/java/2017/12/automatic-module-name/] in > the JAR file's manifest. > I can provide a PR fixing this, but judging by the state of EMAIL-183, this > project looks like it is dead and people should instead be discouraged from > using it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (EMAIL-186) Commons Email does not provide automatic module name
[ https://issues.apache.org/jira/browse/EMAIL-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Petrovicky updated EMAIL-186: --- Description: At the moment, `commons-email` is a thorn in one's side when it comes to JPMS. At the very least, it should give a [stable automatic module name|http://branchandbound.net/blog/java/2017/12/automatic-module-name/] in the JAR file's manifest. I can provide a PR fixing this, but judging by the state of EMAIL-183, this project looks like it is dead and people should instead be discouraged from using it. was: At the moment, `commons-email` is a thorn in one's side when it comes to JPMS. At the very least, it should give a [stable automatic module name|[http://branchandbound.net/blog/java/2017/12/automatic-module-name/]] in the JAR file's manifest. I can provide a PR fixing this, but judging by the state of EMAIL-183, this project looks like it is dead and people should instead be discouraged from using it. > Commons Email does not provide automatic module name > > > Key: EMAIL-186 > URL: https://issues.apache.org/jira/browse/EMAIL-186 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Lukas Petrovicky >Priority: Critical > Fix For: 1.6 > > > At the moment, `commons-email` is a thorn in one's side when it comes to > JPMS. At the very least, it should give a [stable automatic module > name|http://branchandbound.net/blog/java/2017/12/automatic-module-name/] in > the JAR file's manifest. > I can provide a PR fixing this, but judging by the state of EMAIL-183, this > project looks like it is dead and people should instead be discouraged from > using it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (EMAIL-186) Commons Email does not provide automatic module name
Lukas Petrovicky created EMAIL-186: -- Summary: Commons Email does not provide automatic module name Key: EMAIL-186 URL: https://issues.apache.org/jira/browse/EMAIL-186 Project: Commons Email Issue Type: Bug Affects Versions: 1.5 Reporter: Lukas Petrovicky Fix For: 1.6 At the moment, `commons-email` is a thorn in one's side when it comes to JPMS. At the very least, it should give a [stable automatic module name|[http://branchandbound.net/blog/java/2017/12/automatic-module-name/]] in the JAR file's manifest. I can provide a PR fixing this, but judging by the state of EMAIL-183, this project looks like it is dead and people should instead be discouraged from using it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
