[jira] [Comment Edited] (LANG-1627) BooleanUtils.xor not behaving as expected with any odd number of true's
[
https://issues.apache.org/jira/browse/LANG-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252209#comment-17252209
]
Avijit Chakraborty edited comment on LANG-1627 at 12/20/20, 12:25 PM:
--
Hi [~alb-i986],
I had a look into the code of BooleanUtils#xor() methods and at first glance,
the implementations looked correct to me.
When Exclusive OR is applied to 2 inputs then the output becomes true when only
one of the inputs is true.
The definition of multi-input exclusive OR gates says that the final output is
a 1 when the number of 1s at its inputs is odd, and a 0 when the number of
incoming 1s is even. I referred to
[https://en.wikipedia.org/wiki/XOR_gate#More_than_two_inputs]
So, going by this definition (true ^ true ^ true) = true sounds good.
Although I agree with you that the Javadoc of these 2 methods can be improved
by including the fact that output will be true if the number of incoming trues
are odd.
was (Author: aviprogrammer):
Hi [~alb-i986],
I had a look into the code of BooleanUtils#xor() methods and at first instance,
the implementations looked correct to me.
When Exclusive OR is applied to 2 inputs then the output becomes true when only
one of the inputs is true.
The definition of multi-input exclusive OR gates says that the final output is
a 1 when the number of 1s at its inputs is odd, and a 0 when the number of
incoming 1s is even. I referred to
[https://en.wikipedia.org/wiki/XOR_gate#More_than_two_inputs]
So, going by this definition (true ^ true ^ true) = true sounds good.
Although I agree with you that the Javadoc of these 2 methods can be improved
by including the fact that output will be true if the number of incoming trues
are odd.
> BooleanUtils.xor not behaving as expected with any odd number of true's
> ---
>
> Key: LANG-1627
> URL: https://issues.apache.org/jira/browse/LANG-1627
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Alberto Scotto
>Priority: Major
>
> Hi,
> I was expecting a xor function that takes a variable number of arguments to
> *return true if and only if exactly one among all of the arguments is true*,
> regardless of the number of arguments.
> This holds true given three false's:
> {code:java}
> @Test
> public void threeFalse() {
> boolean[] bools = new boolean[]{Boolean.FALSE, Boolean.FALSE, Boolean.FALSE};
> assertFalse(BooleanUtils.xor(bools));
> }{code}
>
> It also holds true given 4 true's, as well as for any even number of trues.
> {code:java}
> @Test
> public void fourTrue() {
> boolean[] bools = new boolean[]{Boolean.TRUE, Boolean.TRUE,
> Boolean.TRUE, Boolean.TRUE};
> assertFalse(BooleanUtils.xor(bools));
> }
> {code}
> The above tests pass.
> But with any odd number of true's that doesn't hold anymore:
>
> {code:java}
> @Test
> public void threeTrue() {
> boolean[] bools = new boolean[]{Boolean.TRUE, Boolean.TRUE, Boolean.TRUE};
> assertFalse(BooleanUtils.xor(bools));
> }
> {code}
> This test fails.
> That was totally unexpected to me.
> But as it turns out, even
> {noformat}
> true ^ true ^ true{noformat}
> evaluates to true. That was unexpected too to me, at a first sight.
> The thing is that xor (I mean the original boolean operator) is a binary
> operator, so if you want to make it n-ary, one simple solution is to apply it
> in two by two: ((a ^ b) ^ c) ^ d
> And that's what is done in the implementation of the method BooleanUtils#xor.
> But that brings to BooleanUtils.xor(true, true, true) == true, and at the
> same time BooleanUtils.xor(true, true, true, true) == false, which just
> doesn't sound right to me.
> Whether or not you agree with me that that is a bug of the method, please at
> least update the Javadoc, because right now it is not providing the user
> enough information. Look:
> {code:java}
> Performs an xor on a set of booleans.
> BooleanUtils.xor(true, true) = false
> BooleanUtils.xor(false, false) = false
> BooleanUtils.xor(true, false) = true
> {code}
>
> Thanks.
> Cheers
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (LANG-1629) DurationFormatUtils.formatPeriod is infinite repetition when parameter is negative number
[
https://issues.apache.org/jira/browse/LANG-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1725#comment-1725
]
Avijit Chakraborty edited comment on LANG-1629 at 12/19/20, 4:55 PM:
-
Hi [~helloJuhyun],
I also tried to reproduce the infinite loop, but unable to do so like [~kinow] .
This below code of yours is causing the existing validation to be failed and I
am getting the expected error message "startMillis must not be greater than
endMillis"
{code:java}
DurationFormatUtils.formatPeriod(160837740, -6217018920,
"HH:mm:ss");{code}
Could you do a recheck and perhaps debug formatPeriod() from your project code
to check how it is going to the while loops down the line even if endMillis
argument is less than startMillis.
If you are able to find out the reason, I will be happy to know the same, so
please share your thoughts.
was (Author: aviprogrammer):
Hi [~helloJuhyun],
I also tried to reproduce the infinite loop, but unable to do so like [~kinow] .
This below code of yours is causing the existing validation to be failed and I
am getting the expected error message "startMillis must not be greater than
endMillis"
DurationFormatUtils.formatPeriod(160837740, -6217018920, "HH:mm:ss");
Could you do a recheck and perhaps debug formatPeriod() from your project code
to check how it is going to the while loops down the line even if endMillis
argument is less than startMillis.
If you are able to find out the reason, I will be happy to know the same, so
please share your thoughts.
> DurationFormatUtils.formatPeriod is infinite repetition when parameter is
> negative number
> -
>
> Key: LANG-1629
> URL: https://issues.apache.org/jira/browse/LANG-1629
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.11
>Reporter: LeeJuHyun
>Priority: Major
> Fix For: Discussion
>
>
> if parameter number(*startMillis*, *endMillis*) is negative number then below
> while loop is infinite repetition. (278 line ~)
> {code:java}
> public static String formatPeriod(final long startMillis, final long
> endMillis, final String format, final boolean padWithZeros,
> final TimeZone timezone) {
> Validate.isTrue(startMillis <= endMillis, "startMillis must not be
> greater than endMillis");
> // Used to optimise for differences under 28 days and
> // called formatDuration(millis, format); however this did not work
> // over leap years.
> // TODO: Compare performance to see if anything was lost by
> // losing this optimisation.
> final Token[] tokens = lexx(format);
> // ...
> while (start.get(Calendar.YEAR) != target) {
> days += start.getActualMaximum(Calendar.DAY_OF_YEAR) -
> start.get(Calendar.DAY_OF_YEAR);
> // Not sure I grok why this is needed, but the brutal tests show it is
> if (start instanceof GregorianCalendar &&
> start.get(Calendar.MONTH) == Calendar.FEBRUARY &&
> start.get(Calendar.DAY_OF_MONTH) == 29) {
> days += 1;
> }
> start.add(Calendar.YEAR, 1);
> days += start.get(Calendar.DAY_OF_YEAR);
> }{code}
>
> How about putting in a validation to determine whether it's negative or
> positive?
>
> thank you :)
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1629) DurationFormatUtils.formatPeriod is infinite repetition when parameter is negative number
[
https://issues.apache.org/jira/browse/LANG-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1725#comment-1725
]
Avijit Chakraborty commented on LANG-1629:
--
Hi [~helloJuhyun],
I also tried to reproduce the infinite loop, but unable to do so like [~kinow] .
This below code of yours is causing the existing validation to be failed and I
am getting the expected error message "startMillis must not be greater than
endMillis"
DurationFormatUtils.formatPeriod(160837740, -6217018920, "HH:mm:ss");
Could you do a recheck and perhaps debug formatPeriod() from your project code
to check how it is going to the while loops down the line even if endMillis
argument is less than startMillis.
If you are able to find out the reason, I will be happy to know the same, so
please share your thoughts.
> DurationFormatUtils.formatPeriod is infinite repetition when parameter is
> negative number
> -
>
> Key: LANG-1629
> URL: https://issues.apache.org/jira/browse/LANG-1629
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.11
>Reporter: LeeJuHyun
>Priority: Major
> Fix For: Discussion
>
>
> if parameter number(*startMillis*, *endMillis*) is negative number then below
> while loop is infinite repetition. (278 line ~)
> {code:java}
> public static String formatPeriod(final long startMillis, final long
> endMillis, final String format, final boolean padWithZeros,
> final TimeZone timezone) {
> Validate.isTrue(startMillis <= endMillis, "startMillis must not be
> greater than endMillis");
> // Used to optimise for differences under 28 days and
> // called formatDuration(millis, format); however this did not work
> // over leap years.
> // TODO: Compare performance to see if anything was lost by
> // losing this optimisation.
> final Token[] tokens = lexx(format);
> // ...
> while (start.get(Calendar.YEAR) != target) {
> days += start.getActualMaximum(Calendar.DAY_OF_YEAR) -
> start.get(Calendar.DAY_OF_YEAR);
> // Not sure I grok why this is needed, but the brutal tests show it is
> if (start instanceof GregorianCalendar &&
> start.get(Calendar.MONTH) == Calendar.FEBRUARY &&
> start.get(Calendar.DAY_OF_MONTH) == 29) {
> days += 1;
> }
> start.add(Calendar.YEAR, 1);
> days += start.get(Calendar.DAY_OF_YEAR);
> }{code}
>
> How about putting in a validation to determine whether it's negative or
> positive?
>
> thank you :)
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1627) BooleanUtils.xor not behaving as expected with any odd number of true's
[
https://issues.apache.org/jira/browse/LANG-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252209#comment-17252209
]
Avijit Chakraborty commented on LANG-1627:
--
Hi [~alb-i986],
I had a look into the code of BooleanUtils#xor() methods and at first instance,
the implementations looked correct to me.
When Exclusive OR is applied to 2 inputs then the output becomes true when only
one of the inputs is true.
The definition of multi-input exclusive OR gates says that the final output is
a 1 when the number of 1s at its inputs is odd, and a 0 when the number of
incoming 1s is even. I referred to
[https://en.wikipedia.org/wiki/XOR_gate#More_than_two_inputs]
So, going by this definition (true ^ true ^ true) = true sounds good.
Although I agree with you that the Javadoc of these 2 methods can be improved
by including the fact that output will be true if the number of incoming trues
are odd.
> BooleanUtils.xor not behaving as expected with any odd number of true's
> ---
>
> Key: LANG-1627
> URL: https://issues.apache.org/jira/browse/LANG-1627
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.11
>Reporter: Alberto Scotto
>Priority: Major
>
> Hi,
> I was expecting a xor function that takes a variable number of arguments to
> *return true if and only if exactly one among all of the arguments is true*,
> regardless of the number of arguments.
> This holds true given three false's:
> {code:java}
> @Test
> public void threeFalse() {
> boolean[] bools = new boolean[]{Boolean.FALSE, Boolean.FALSE, Boolean.FALSE};
> assertFalse(BooleanUtils.xor(bools));
> }{code}
>
> It also holds true given 4 true's, as well as for any even number of trues.
> {code:java}
> @Test
> public void fourTrue() {
> boolean[] bools = new boolean[]{Boolean.TRUE, Boolean.TRUE,
> Boolean.TRUE, Boolean.TRUE};
> assertFalse(BooleanUtils.xor(bools));
> }
> {code}
> The above tests pass.
> But with any odd number of true's that doesn't hold anymore:
>
> {code:java}
> @Test
> public void threeTrue() {
> boolean[] bools = new boolean[]{Boolean.TRUE, Boolean.TRUE, Boolean.TRUE};
> assertFalse(BooleanUtils.xor(bools));
> }
> {code}
> This test fails.
> That was totally unexpected to me.
> But as it turns out, even
> {noformat}
> true ^ true ^ true{noformat}
> evaluates to true. That was unexpected too to me, at a first sight.
> The thing is that xor (I mean the original boolean operator) is a binary
> operator, so if you want to make it n-ary, one simple solution is to apply it
> in two by two: ((a ^ b) ^ c) ^ d
> And that's what is done in the implementation of the method BooleanUtils#xor.
> But that brings to BooleanUtils.xor(true, true, true) == true, and at the
> same time BooleanUtils.xor(true, true, true, true) == false, which just
> doesn't sound right to me.
> Whether or not you agree with me that that is a bug of the method, please at
> least update the Javadoc, because right now it is not providing the user
> enough information. Look:
> {code:java}
> Performs an xor on a set of booleans.
> BooleanUtils.xor(true, true) = false
> BooleanUtils.xor(false, false) = false
> BooleanUtils.xor(true, false) = true
> {code}
>
> Thanks.
> Cheers
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1628) Javadoc for RandomStringUtils.random() letters, numbers parameters is wrong
[
https://issues.apache.org/jira/browse/LANG-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252140#comment-17252140
]
Avijit Chakraborty commented on LANG-1628:
--
Correction of the Javadoc has been done and PR created.
https://github.com/apache/commons-lang/pull/677
> Javadoc for RandomStringUtils.random() letters, numbers parameters is wrong
> ---
>
> Key: LANG-1628
> URL: https://issues.apache.org/jira/browse/LANG-1628
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.11
>Reporter: Jarkko Rantavuori
>Priority: Minor
>
> For two of the random() methods, these:
> public static String random(int count, int start, int end, boolean letters,
> boolean numbers, char... chars)
> public static String random(int count, int start, int end, boolean letters,
> boolean numbers, char[] chars, Random random)
> the javadoc for letters, numbers parameters is
> {{letters}} - only allow letters?
> {{numbers}} - only allow numbers?
> when it should be like in other random() methods:
> {{letters}} - if {{true}}, generated string may include alphabetic characters
> {{numbers}} - if {{true}}, generated string may include numeric characters
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
