You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by er...@apache.org on 2018/04/24 12:48:51 UTC
commons-numbers git commit: NUMBERS-68: Added parse() method to
Complex(). TODO: Add testing.
Repository: commons-numbers
Updated Branches:
refs/heads/master c2fadea8b -> d22b6d863
NUMBERS-68: Added parse() method to Complex(). TODO: Add testing.
Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-numbers/commit/d22b6d86
Tree: http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/d22b6d86
Diff: http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/d22b6d86
Branch: refs/heads/master
Commit: d22b6d86356096afe8d5681c1035a68791470342
Parents: c2fadea
Author: Eric Barnhill <er...@apache.org>
Authored: Tue Apr 24 14:51:51 2018 +0200
Committer: Eric Barnhill <er...@apache.org>
Committed: Tue Apr 24 14:51:51 2018 +0200
----------------------------------------------------------------------
.../apache/commons/numbers/complex/Complex.java | 35 ++++++++++++++++++++
1 file changed, 35 insertions(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/commons-numbers/blob/d22b6d86/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
----------------------------------------------------------------------
diff --git a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
index e65bc10..217c109 100644
--- a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
+++ b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
@@ -20,6 +20,7 @@ package org.apache.commons.numbers.complex;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
+import java.lang.NumberFormatException;
import org.apache.commons.numbers.core.Precision;
/**
* Representation of a Complex number, i.e. a number which has both a
@@ -132,6 +133,40 @@ public final class Complex implements Serializable {
}
/**
+ * Parses a text expression in a String object to produce
+ * a Cartesian complex number. Acceptable formats are:
+ * <p><ul> * <li>Single number (parsed as real). Example: "3.14"
+ * <li>Single number with appended "i" (parsed as imaginary): "1.42i"
+ * <li>Pair of numbers, separated by plus sign and with appended i: "3 + 4i"
+ * </ul>
+ * @throws{ParseException, NumberFormatException}
+ */
+ public static Complex parse(String s) {
+ final String[] terms = s.split("+");
+ if (terms.length == 2) {
+ if (terms[1].indexOf("i") == terms[1].length()) {
+ String imagTerm = (String) terms[1].subSequence(0, terms[1].length()-1);
+ final double real = Double.parseDouble(terms[0]);
+ final double imaginary = Double.parseDouble(imagTerm);
+ return Complex.ofCartesian(real, imaginary);
+ } else {
+ throw new NumberFormatException("Expression must end with unique \"i\"");
+ }
+ } else if (terms.length == 1){
+ if (terms[0].indexOf("i") == terms[0].length()) {
+ String imagTerm = (String) terms[0].subSequence(0, terms[0].length()-1);
+ final double imaginary = Double.parseDouble(imagTerm);
+ return Complex.ofCartesian(0, imaginary);
+ } else {
+ final double real = Double.parseDouble(terms[0]);
+ return Complex.ofReal(real);
+ }
+ } else {
+ throw new NumberFormatException("Invalid expression for Complex. See documentation for further information.");
+ }
+ }
+
+ /**
* Returns true if either real or imaginary component of the Complex
* is NaN
*
Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Wed, 25 Apr 2018 09:55:13 +0200, Eric Barnhill wrote:
> Just to clarify, so the spec for parse() will handle decimal points
> in
> numbers but not commas.
"toString" creates a fixed representation, not Locale-dependent;
"parse" being the inverse function, a decimal comma must be treated
as an error.
For localized representations, there is
https://docs.oracle.com/javase/7/docs/api/java/text/NumberFormat.html
[See the JDK package name...]
> Fine by me.
Thanks.
Gilles
> Eric
>
> On Tue, Apr 24, 2018 at 8:53 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 24 Apr 2018 16:29:58 +0200, Gilles wrote:
>>
>>> On Tue, 24 Apr 2018 16:05:32 +0200, Eric Barnhill wrote:
>>>
>>>> I would prefer to conform toString() to the current formats
>>>> accepted by
>>>> parse() .
>>>>
>>>> The toString() method separates the real and imaginary components
>>>> by
>>>> commas. Separating numbers by commas strikes me as dangerous given
>>>> that
>>>> the
>>>> input expressions to be parsed may also contain commas within the
>>>> numbers.
>>>> The format "x + yi" strikes me as satisfyingly unambiguous.
>>>>
>>>
>> If I'm not mistaken, the current "parse" will choke on "x - yi"...
>>
>> I understand the intent, but I think that there are two issues
>>> on that matter:
>>> 1. "ValJO"
>>> 2. Convenience/Standard notation
>>>
>>> IMHO the former belongs to the "Complex" class, the latter not.
>>>
>>> For the former, I'd favour the KISS principle, which in this
>>> case would be to only accept (i.e. read) only what "toString"
>>> would have written.
>>>
>>> Note that we talk here only about machine input/output, not
>>> all the variations that one would deem necessary for human
>>> (dangerous! ;-) input.
>>>
>>> Flexible (or intended to be) parsing is a can of worm that
>>> is better left for an independent utility defined in another
>>> class; even better in another module that could depend on
>>> another component that would offer advanced interpretation
>>> capabilities (e.g. "Commons Text").
>>> That way we can also create common code for all the "number"
>>> classes, without circular dependencies.
>>>
>>
>> Concretely, for the "ValJO", I suggest the following parsing
>> pseudo-code:
>>
>> Read a '('
>> Read a "double"
>> Read a ','
>> Read a "double"
>> Read a ')'
>>
>> If you agree with the above rationale, I have the code ready
>> (with unit tests).
>>
>> Regards,
>> Gilles
>>
>>
>>
>>> Best,
>>> Gilles
>>>
>>> Eric
>>>>
>>>>
>>>>
>>>> On Tue, Apr 24, 2018 at 3:38 PM, Gilles
>>>> <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> Hi.
>>>>>
>>>>> The contract indicates:[1]
>>>>> ---
>>>>> There must be a static factory method capable of creating an
>>>>> instance from the formal string representation. [...]
>>>>> ---
>>>>>
>>>>> Currently "toString" and "parse" do not match.
>>>>>
>>>>> Regards,
>>>>> Gilles
>>>>>
>>>>> [1] http://blog.joda.org/2014/03/valjos-value-java-objects.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]
Posted by Eric Barnhill <er...@gmail.com>.
Just to clarify, so the spec for parse() will handle decimal points in
numbers but not commas.
Fine by me.
Eric
On Tue, Apr 24, 2018 at 8:53 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 24 Apr 2018 16:29:58 +0200, Gilles wrote:
>
>> On Tue, 24 Apr 2018 16:05:32 +0200, Eric Barnhill wrote:
>>
>>> I would prefer to conform toString() to the current formats accepted by
>>> parse() .
>>>
>>> The toString() method separates the real and imaginary components by
>>> commas. Separating numbers by commas strikes me as dangerous given that
>>> the
>>> input expressions to be parsed may also contain commas within the
>>> numbers.
>>> The format "x + yi" strikes me as satisfyingly unambiguous.
>>>
>>
> If I'm not mistaken, the current "parse" will choke on "x - yi"...
>
> I understand the intent, but I think that there are two issues
>> on that matter:
>> 1. "ValJO"
>> 2. Convenience/Standard notation
>>
>> IMHO the former belongs to the "Complex" class, the latter not.
>>
>> For the former, I'd favour the KISS principle, which in this
>> case would be to only accept (i.e. read) only what "toString"
>> would have written.
>>
>> Note that we talk here only about machine input/output, not
>> all the variations that one would deem necessary for human
>> (dangerous! ;-) input.
>>
>> Flexible (or intended to be) parsing is a can of worm that
>> is better left for an independent utility defined in another
>> class; even better in another module that could depend on
>> another component that would offer advanced interpretation
>> capabilities (e.g. "Commons Text").
>> That way we can also create common code for all the "number"
>> classes, without circular dependencies.
>>
>
> Concretely, for the "ValJO", I suggest the following parsing
> pseudo-code:
>
> Read a '('
> Read a "double"
> Read a ','
> Read a "double"
> Read a ')'
>
> If you agree with the above rationale, I have the code ready
> (with unit tests).
>
> Regards,
> Gilles
>
>
>
>> Best,
>> Gilles
>>
>> Eric
>>>
>>>
>>>
>>> On Tue, Apr 24, 2018 at 3:38 PM, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> Hi.
>>>>
>>>> The contract indicates:[1]
>>>> ---
>>>> There must be a static factory method capable of creating an
>>>> instance from the formal string representation. [...]
>>>> ---
>>>>
>>>> Currently "toString" and "parse" do not match.
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> [1] http://blog.joda.org/2014/03/valjos-value-java-objects.html
>>>>
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 24 Apr 2018 16:29:58 +0200, Gilles wrote:
> On Tue, 24 Apr 2018 16:05:32 +0200, Eric Barnhill wrote:
>> I would prefer to conform toString() to the current formats accepted
>> by
>> parse() .
>>
>> The toString() method separates the real and imaginary components by
>> commas. Separating numbers by commas strikes me as dangerous given
>> that the
>> input expressions to be parsed may also contain commas within the
>> numbers.
>> The format "x + yi" strikes me as satisfyingly unambiguous.
If I'm not mistaken, the current "parse" will choke on "x - yi"...
> I understand the intent, but I think that there are two issues
> on that matter:
> 1. "ValJO"
> 2. Convenience/Standard notation
>
> IMHO the former belongs to the "Complex" class, the latter not.
>
> For the former, I'd favour the KISS principle, which in this
> case would be to only accept (i.e. read) only what "toString"
> would have written.
>
> Note that we talk here only about machine input/output, not
> all the variations that one would deem necessary for human
> (dangerous! ;-) input.
>
> Flexible (or intended to be) parsing is a can of worm that
> is better left for an independent utility defined in another
> class; even better in another module that could depend on
> another component that would offer advanced interpretation
> capabilities (e.g. "Commons Text").
> That way we can also create common code for all the "number"
> classes, without circular dependencies.
Concretely, for the "ValJO", I suggest the following parsing
pseudo-code:
Read a '('
Read a "double"
Read a ','
Read a "double"
Read a ')'
If you agree with the above rationale, I have the code ready
(with unit tests).
Regards,
Gilles
>
> Best,
> Gilles
>
>> Eric
>>
>>
>>
>> On Tue, Apr 24, 2018 at 3:38 PM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>>> Hi.
>>>
>>> The contract indicates:[1]
>>> ---
>>> There must be a static factory method capable of creating an
>>> instance from the formal string representation. [...]
>>> ---
>>>
>>> Currently "toString" and "parse" do not match.
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] http://blog.joda.org/2014/03/valjos-value-java-objects.html
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 24 Apr 2018 16:05:32 +0200, Eric Barnhill wrote:
> I would prefer to conform toString() to the current formats accepted
> by
> parse() .
>
> The toString() method separates the real and imaginary components by
> commas. Separating numbers by commas strikes me as dangerous given
> that the
> input expressions to be parsed may also contain commas within the
> numbers.
> The format "x + yi" strikes me as satisfyingly unambiguous.
I understand the intent, but I think that there are two issues
on that matter:
1. "ValJO"
2. Convenience/Standard notation
IMHO the former belongs to the "Complex" class, the latter not.
For the former, I'd favour the KISS principle, which in this
case would be to only accept (i.e. read) only what "toString"
would have written.
Note that we talk here only about machine input/output, not
all the variations that one would deem necessary for human
(dangerous! ;-) input.
Flexible (or intended to be) parsing is a can of worm that
is better left for an independent utility defined in another
class; even better in another module that could depend on
another component that would offer advanced interpretation
capabilities (e.g. "Commons Text").
That way we can also create common code for all the "number"
classes, without circular dependencies.
Best,
Gilles
> Eric
>
>
>
> On Tue, Apr 24, 2018 at 3:38 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> Hi.
>>
>> The contract indicates:[1]
>> ---
>> There must be a static factory method capable of creating an
>> instance from the formal string representation. [...]
>> ---
>>
>> Currently "toString" and "parse" do not match.
>>
>> Regards,
>> Gilles
>>
>> [1] http://blog.joda.org/2014/03/valjos-value-java-objects.html
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]
Posted by Eric Barnhill <er...@gmail.com>.
I would prefer to conform toString() to the current formats accepted by
parse() .
The toString() method separates the real and imaginary components by
commas. Separating numbers by commas strikes me as dangerous given that the
input expressions to be parsed may also contain commas within the numbers.
The format "x + yi" strikes me as satisfyingly unambiguous.
Eric
On Tue, Apr 24, 2018 at 3:38 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> Hi.
>
> The contract indicates:[1]
> ---
> There must be a static factory method capable of creating an
> instance from the formal string representation. [...]
> ---
>
> Currently "toString" and "parse" do not match.
>
> Regards,
> Gilles
>
> [1] http://blog.joda.org/2014/03/valjos-value-java-objects.html
>
>
[Numbers] Re: [...] NUMBERS-68: parse() [...]
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
The contract indicates:[1]
---
There must be a static factory method capable of creating an
instance from the formal string representation. [...]
---
Currently "toString" and "parse" do not match.
Regards,
Gilles
[1] http://blog.joda.org/2014/03/valjos-value-java-objects.html
On Tue, 24 Apr 2018 12:48:51 +0000 (UTC), ericbarnhill@apache.org
wrote:
> Repository: commons-numbers
> Updated Branches:
> refs/heads/master c2fadea8b -> d22b6d863
>
>
> NUMBERS-68: Added parse() method to Complex(). TODO: Add testing.
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
> Commit:
>
> http://git-wip-us.apache.org/repos/asf/commons-numbers/commit/d22b6d86
> Tree:
> http://git-wip-us.apache.org/repos/asf/commons-numbers/tree/d22b6d86
> Diff:
> http://git-wip-us.apache.org/repos/asf/commons-numbers/diff/d22b6d86
>
> Branch: refs/heads/master
> Commit: d22b6d86356096afe8d5681c1035a68791470342
> Parents: c2fadea
> Author: Eric Barnhill <er...@apache.org>
> Authored: Tue Apr 24 14:51:51 2018 +0200
> Committer: Eric Barnhill <er...@apache.org>
> Committed: Tue Apr 24 14:51:51 2018 +0200
>
>
> ----------------------------------------------------------------------
> .../apache/commons/numbers/complex/Complex.java | 35
> ++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> ----------------------------------------------------------------------
>
>
>
> http://git-wip-us.apache.org/repos/asf/commons-numbers/blob/d22b6d86/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
>
> ----------------------------------------------------------------------
> diff --git
>
> a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
>
> b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
> index e65bc10..217c109 100644
> ---
>
> a/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
> +++
>
> b/commons-numbers-complex/src/main/java/org/apache/commons/numbers/complex/Complex.java
> @@ -20,6 +20,7 @@ package org.apache.commons.numbers.complex;
> import java.io.Serializable;
> import java.util.ArrayList;
> import java.util.List;
> +import java.lang.NumberFormatException;
> import org.apache.commons.numbers.core.Precision;
> /**
> * Representation of a Complex number, i.e. a number which has both
> a
> @@ -132,6 +133,40 @@ public final class Complex implements
> Serializable {
> }
>
> /**
> + * Parses a text expression in a String object to produce
> + * a Cartesian complex number. Acceptable formats are:
> + * <p><ul> * <li>Single number (parsed as real). Example: "3.14"
> + * <li>Single number with appended "i" (parsed as imaginary):
> "1.42i"
> + * <li>Pair of numbers, separated by plus sign and with appended
> i: "3 + 4i"
> + * </ul>
> + * @throws{ParseException, NumberFormatException}
> + */
> + public static Complex parse(String s) {
> + final String[] terms = s.split("+");
> + if (terms.length == 2) {
> + if (terms[1].indexOf("i") == terms[1].length()) {
> + String imagTerm = (String) terms[1].subSequence(0,
> terms[1].length()-1);
> + final double real = Double.parseDouble(terms[0]);
> + final double imaginary =
> Double.parseDouble(imagTerm);
> + return Complex.ofCartesian(real, imaginary);
> + } else {
> + throw new NumberFormatException("Expression must end
> with unique \"i\"");
> + }
> + } else if (terms.length == 1){
> + if (terms[0].indexOf("i") == terms[0].length()) {
> + String imagTerm = (String) terms[0].subSequence(0,
> terms[0].length()-1);
> + final double imaginary =
> Double.parseDouble(imagTerm);
> + return Complex.ofCartesian(0, imaginary);
> + } else {
> + final double real = Double.parseDouble(terms[0]);
> + return Complex.ofReal(real);
> + }
> + } else {
> + throw new NumberFormatException("Invalid expression for
> Complex. See documentation for further information.");
> + }
> + }
> +
> + /**
> * Returns true if either real or imaginary component of the
> Complex
> * is NaN
> *
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org