[jira] [Updated] (MATH-749) Convex Hull algorithm
[ https://issues.apache.org/jira/browse/MATH-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-749: - Attachment: MATH-749.tar.gz Attached patch containing implementation of Graham's scan method for 2D. > Convex Hull algorithm > - > > Key: MATH-749 > URL: https://issues.apache.org/jira/browse/MATH-749 > Project: Commons Math > Issue Type: Sub-task >Reporter: Thomas Neidhart >Assignee: Thomas Neidhart >Priority: Minor > Labels: 2d, geometric > Attachments: MATH-749.tar.gz > > > It would be nice to have convex hull implementations for 2D/3D space. There > are several known algorithms > [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: > * Graham scan: O(n log n) > * Incremental: O(n log n) > * Divide and Conquer: O(n log n) > * Kirkpatrick-Seidel: O(n log h) > * Chan: O(n log h) > The preference would be on an algorithm that is easily extensible for higher > dimensions, so *Incremental* and *Divide and Conquer* would be prefered. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-341) [NumberUtils] Please add number <> byte[] methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882429#comment-13882429
]
Duncan Jones commented on LANG-341:
---
The patch looks good, thank for submitting and apologies that it's laid
stagnant for so long. If you are willing, it would be easier to get this into
trunk if you submit an [Individual Contributor License
Agreement|http://www.apache.org/licenses/#clas] to avoid any doubts over IP
issues with this code.
bq. Should we check the buffer length? (in addittion to the null checking)
Yes. Much better to have an {{IllegalArgumentException}} with a clear message
than attempt to access an invalid array index.
bq. Should we add other methods with a default value? (toPrimitive(byte[] buff,
primitive default))
In what situation would the default value be used?
Finally, if you wanted to add Javadoc comments to the non-test methods that
would save us a little bit of work when it comes to adding this.
> [NumberUtils] Please add number <> byte[] methods
> -
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.math.*
>Reporter: Lilianne E. Blaze
> Fix For: Review Patch
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> {code:java}
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (MATH-1094) Incorrect linear system solution
[ https://issues.apache.org/jira/browse/MATH-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Bezpartochnyy closed MATH-1094. -- Resolution: Invalid > Incorrect linear system solution > > > Key: MATH-1094 > URL: https://issues.apache.org/jira/browse/MATH-1094 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: Oracle JDK7 > Linux x86-64 >Reporter: Bogdan Bezpartochnyy > Labels: patch > Attachments: Main.java > > > Firstly I would like to point out that I'm not very proficient in linear > algebra, but in my opinion the following behavior should not occur. When I > solve the following linear system by hand it has no solution, but in commons > math using QRDecomposition it outputs x1= 7.5 x2 = 5.5 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-916:
-
Labels: patch time (was: patch)
> CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
> certain situations
>
>
> Key: LANG-916
> URL: https://issues.apache.org/jira/browse/LANG-916
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
>Reporter: Christian P. MOMON
> Labels: patch, time
> Fix For: Review Patch
>
> Attachments: LANG-916.patch
>
>
> In LANG-538 issue, there is an unit test:
> {noformat}
> public void testFormat_CalendarIsoMsZulu() {
> final String dateTime = "2009-10-16T16:42:16.000Z";
> GregorianCalendar cal = new
> GregorianCalendar(TimeZone.getTimeZone("GMT-8"));
> cal.clear();
> cal.set(2009, 9, 16, 8, 42, 16);
> cal.getTime();
> FastDateFormat format =
> FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("GMT"));
> assertEquals("dateTime", dateTime, format.format(cal));
> }
> {noformat}
> This test passes successfully in lang-2.6 but failed in lang3-3.1:
> {noformat}
> org.junit.ComparisonFailure: dateTime expected:<2009-10-16T[16]:42:16.000Z>
> but was:<2009-10-16T[08]:42:16.000Z>
> {noformat}
> Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
> 3.9.10-100.fc17.i686.PAE).
> Moreover, I wrote another unit test showing that the timeZone parameter seems
> to be ignored :
> {noformat}
> public void test() {
> Calendar cal =
> Calendar.getInstance(TimeZone.getTimeZone("Europe/Paris"));
> cal.set(2009, 9, 16, 8, 42, 16);
> //
> System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
> System.out.println("long");
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar");
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getDefault()));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Asia/Kolkata")));
> System.out.println(DateFormatUtils.format(cal,
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
> TimeZone.getTimeZone("Europe/London")));
> System.out.println("calendar fast");
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/Paris")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Asia/Kolkata")).format(cal));
>
> System.out.println(FastDateFormat.getInstance("-MM-dd'T'HH:mm:ss.SSS'Z'",
> TimeZone.getTimeZone("Europe/London")).format(cal));
> }
> {noformat}
> Gives the following console logs:
> {noformat}
> long
> 2009-10-16T08:42:16+02:00
> 2009-10-16T12:12:16+05:30
> 2009-10-16T07:42:16+01:00
> calendar
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> 2009-10-16T08:42:16+02:00
> calendar fast
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> 2009-10-16T08:42:16.975Z
> {noformat}
> When DateFormatUtils.format takes a long parameter, the time string is good.
> When DateFormatUtils.format takes a Calendar parameter, the time string is
> wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (LANG-341) [NumberUtils] Please add number <> byte[] methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-341:
-
Description:
Hello,
I need a set of methods to convert Long to or from a byte[] array, as if
writing / reading from Data(Input/Output)Stream(
ByteArray(Input/Output)Stream ).
First, doing it with Streams seems a bit wasteful, second, it seems a
pretty general use. Would it be possible to add something like that to,
for example,
org.apache.commons.lang.math.NumberUtils?
Example code:
{code:java}
static public long toLong(byte[] b)
{
return toLong(b, 0);
}
static public long toLong(byte[] b, int offset)
{
return (((long)b[offset] << 56) +
((long)(b[offset + 1] & 255) << 48) +
((long)(b[offset + 2] & 255) << 40) +
((long)(b[offset + 3] & 255) << 32) +
((long)(b[offset + 4] & 255) << 24) +
((b[offset + 5] & 255) << 16) +
((b[offset + 6] & 255) << 8) +
((b[offset + 7] & 255) << 0));
}
static public byte[] longToByteArray(long l)
{
byte b[] = new byte[8];
longToByteArray(l, b, 0);
return b;
}
static public void longToByteArray(long l, byte b[], int offset)
{
b[offset] = (byte)(l >>> 56);
b[offset + 1] = (byte)(l >>> 48);
b[offset + 2] = (byte)(l >>> 40);
b[offset + 3] = (byte)(l >>> 32);
b[offset + 4] = (byte)(l >>> 24);
b[offset + 5] = (byte)(l >>> 16);
b[offset + 6] = (byte)(l >>> 8);
b[offset + 7] = (byte)(l >>> 0);
}
{code}
was:
Hello,
I need a set of methods to convert Long to or from a byte[] array, as if
writing / reading from Data(Input/Output)Stream(
ByteArray(Input/Output)Stream ).
First, doing it with Streams seems a bit wasteful, second, it seems a
pretty general use. Would it be possible to add something like that to,
for example,
org.apache.commons.lang.math.NumberUtils?
Example code:
static public long toLong(byte[] b)
{
return toLong(b, 0);
}
static public long toLong(byte[] b, int offset)
{
return (((long)b[offset] << 56) +
((long)(b[offset + 1] & 255) << 48) +
((long)(b[offset + 2] & 255) << 40) +
((long)(b[offset + 3] & 255) << 32) +
((long)(b[offset + 4] & 255) << 24) +
((b[offset + 5] & 255) << 16) +
((b[offset + 6] & 255) << 8) +
((b[offset + 7] & 255) << 0));
}
static public byte[] longToByteArray(long l)
{
byte b[] = new byte[8];
longToByteArray(l, b, 0);
return b;
}
static public void longToByteArray(long l, byte b[], int offset)
{
b[offset] = (byte)(l >>> 56);
b[offset + 1] = (byte)(l >>> 48);
b[offset + 2] = (byte)(l >>> 40);
b[offset + 3] = (byte)(l >>> 32);
b[offset + 4] = (byte)(l >>> 24);
b[offset + 5] = (byte)(l >>> 16);
b[offset + 6] = (byte)(l >>> 8);
b[offset + 7] = (byte)(l >>> 0);
}
> [NumberUtils] Please add number <> byte[] methods
> -
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.math.*
>Reporter: Lilianne E. Blaze
> Fix For: Review Patch
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> {code:java}
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (MATH-1071) Improve genetic algorithms section of user guide
[ https://issues.apache.org/jira/browse/MATH-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-1071: -- Issue Type: Sub-task (was: Task) Parent: MATH-982 > Improve genetic algorithms section of user guide > > > Key: MATH-1071 > URL: https://issues.apache.org/jira/browse/MATH-1071 > Project: Commons Math > Issue Type: Sub-task >Reporter: Thomas Neidhart >Assignee: Thomas Neidhart > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (MATH-985) BicubicSpline interpolation returns unexpected values (BicubicSplineInterpolator/BicubicSplineInterpolationFunction)
[
https://issues.apache.org/jira/browse/MATH-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved MATH-985.
--
Resolution: Fixed
Fix Version/s: 3.3
Added changelog entry in r1561510.
For the remaining tests which are ignored atm I would suggest to create a
separate ticket.
> BicubicSpline interpolation returns unexpected values
> (BicubicSplineInterpolator/BicubicSplineInterpolationFunction)
>
>
> Key: MATH-985
> URL: https://issues.apache.org/jira/browse/MATH-985
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: Windows 7 64 bit, 64 bit JVM
>Reporter: Johnathan Kool
> Fix For: 3.3
>
> Attachments: math985.png
>
>
> I've been testing out the Tricubic spline functions, and have been getting
> some strange values. I dug down a bit, and it seems like they start at the
> Bicubic level. SplineInterpolator/PolynomialSplineFunction seem to be
> returning correct values. I set up a block of data that increases linearly,
> so you'd expect the interpolated values to follow the same trend, except the
> values tend to overshoot to half the distance between knot points, and then
> undershoot for the remaining half. Probably the easiest thing would be to
> show some tests. First - 1D which works fine:
> {code:title=SplineTest.java|borderStyle=solid}
> import org.apache.commons.math3.analysis.interpolation.SplineInterpolator;
> import org.apache.commons.math3.analysis.polynomials.PolynomialSplineFunction;
> public class SplineTest {
> double[] x = new double[]{.52,.54,.56,.58,.6};
> double[] y = new double[]{76,77,78,79,80};
>
> public static void main(String[] args){
> SplineTest st = new SplineTest();
> st.go();
> }
>
> public void go(){
> SplineInterpolator si = new SplineInterpolator();
> PolynomialSplineFunction sf = si.interpolate(x, y);
>
> System.out.println(sf.value(0.52));
> System.out.println(sf.value(0.5225));
> System.out.println(sf.value(0.525));
> System.out.println(sf.value(0.5275));
> System.out.println(sf.value(0.53));
> System.out.println(sf.value(0.5325));
> System.out.println(sf.value(0.535));
> System.out.println(sf.value(0.5375));
> System.out.println(sf.value(0.54));
> System.out.println(sf.value(0.5425));
> System.out.println(sf.value(0.545));
> System.out.println(sf.value(0.5475));
> System.out.println(sf.value(0.55));
> System.out.println(sf.value(0.5525));
> System.out.println(sf.value(0.555));
> System.out.println(sf.value(0.5575));
> System.out.println(sf.value(0.56));
> }
> }
> {code}
> and next, 2D which doesn't:
> {code:title=BicubicSplineTest.java|borderStyle=solid}
> import
> org.apache.commons.math3.analysis.interpolation.BicubicSplineInterpolatingFunction;
> import
> org.apache.commons.math3.analysis.interpolation.BicubicSplineInterpolator;
> public class BicubicSplineTest {
> double[] x = new double[]{0,1,2};
> double[] y = new double[]{.52,.54,.56,.58,.6};
> double[] v1 = new double[]{76,77,78,79,80};
> double[][] v2 = new double[][]{v1,v1,v1};
>
> public static void main(String[] args){
> BicubicSplineTest bt = new BicubicSplineTest();
> bt.go();
> }
>
> public void go(){
> BicubicSplineInterpolator bi = new BicubicSplineInterpolator();
> BicubicSplineInterpolatingFunction bf = bi.interpolate(x, y,
> v2);
>
> System.out.println(bf.value(1, 0.52));
> System.out.println(bf.value(1, 0.5225));
> System.out.println(bf.value(1, 0.525));
> System.out.println(bf.value(1, 0.5275));
> System.out.println(bf.value(1, 0.53));
> System.out.println(bf.value(1, 0.5325));
> System.out.println(bf.value(1, 0.535));
> System.out.println(bf.value(1, 0.5375));
> System.out.println(bf.value(1, 0.54));
> System.out.println(bf.value(1, 0.5425));
> System.out.println(bf.value(1, 0.545));
> System.out.println(bf.value(1, 0.5475));
> System.out.println(bf.value(1, 0.55));
> System.out.println(bf.value(1, 0.5525));
> System.out.println(bf.value(1, 0.555));
> System.out.println(bf.value(1, 0.5575));
> System.out.println(bf.value(1, 0.56));
>
[jira] [Resolved] (MATH-1072) AbstractListChromosome should support a constructor that does not copy
[ https://issues.apache.org/jira/browse/MATH-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1072. --- Resolution: Fixed Fix Version/s: 3.3 Added in r1561508. > AbstractListChromosome should support a constructor that does not copy > -- > > Key: MATH-1072 > URL: https://issues.apache.org/jira/browse/MATH-1072 > Project: Commons Math > Issue Type: Improvement >Reporter: Thomas Neidhart >Priority: Minor > Fix For: 3.3 > > > AbstractListChromosome always copies the input arguments to a new list in its > constructor. At the same time, subclasses implementing > newFixedLengthChromosome() create a new instance with a new list, thus the > list has to be created twice, which is inefficient. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (BEANUTILS-332) Getter-/Setter-Detection does not work on inner default visible level classes
[
https://issues.apache.org/jira/browse/BEANUTILS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated BEANUTILS-332:
--
Description:
There seem to be a problem for the BeanUtils copyProperties method, if origin
oder destination´s class is only default visible.
I stepped over that when I wrote a unit test, that includes two bean classes
with equal properties. I declared them static but not public by accident and
wondered why it didn´t worked. After some debugging I found it to fail while
checking for readable source and writeable target properties.
See this code sample - Putting public in front of the inner classes static
class let it work again:
{code:java}
import junit.framework.TestCase;
public class BeanUtilsTest extends TestCase {
public void testCopyPropertiesObjectObject() {
SourceBean source = new SourceBean();
FullTargetBean fullTarget = new FullTargetBean();
BeanUtils.copyProperties(fullTarget, source);
assertEquals("My World!", fullTarget.getName()); // Fails since it is
still "Hello World!"
}
static class SourceBean {
private long id = 10L;
private String name = "My World!";
private Boolean fullMoon = true;
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Boolean getFullMoon() {
return fullMoon;
}
public void setFullMoon(Boolean fullMoon) {
this.fullMoon = fullMoon;
}
}
static class FullTargetBean {
private long id = 16L;
private String name = "Hello World!";
private Boolean fullMoon = false;
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Boolean isFullMoon() {
return fullMoon;
}
public void setFullMoon(Boolean fullMoon) {
this.fullMoon = fullMoon;
}
}
}
{code}
was:
There seem to be a problem for the BeanUtils copyProperties method, if origin
oder destination´s class is only default visible.
I stepped over that when I wrote a unit test, that includes two bean classes
with equal properties. I declared them static but not public by accident and
wondered why it didn´t worked. After some debugging I found it to fail while
checking for readable source and writeable target properties.
See this code sample - Putting public in front of the inner classes static
class let it work again:
import junit.framework.TestCase;
public class BeanUtilsTest extends TestCase {
public void testCopyPropertiesObjectObject() {
SourceBean source = new SourceBean();
FullTargetBean fullTarget = new FullTargetBean();
BeanUtils.copyProperties(fullTarget, source);
assertEquals("My World!", fullTarget.getName()); // Fails since it is
still "Hello World!"
}
static class SourceBean {
private long id = 10L;
private String name = "My World!";
private Boolean fullMoon = true;
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Boolean getFullMoon() {
return fullMoon;
}
public void setFullMoon(Boolean fullMoon) {
this.fullMoon = fullMoon;
}
}
static class FullTargetBean {
private long id = 16L;
private String name = "Hello World!";
private Boolean fullMoon = false;
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Boolean isFullMoon() {
return fullMoon;
}
public void setFullMoon(Boolean fullMoon) {
this.fullMoon = fullMoon;
}
}
}
> Getter-/Setter-Detection does not work on inner default visible level classes
> -
>
> Key: BEANUTILS-332
> URL: https://issues.apache.org/jira/browse/BEANUTILS-332
> Project: Commons BeanUtils
> Issue Type: Bug
> Co
[jira] [Commented] (MATH-1094) Incorrect linear system solution
[ https://issues.apache.org/jira/browse/MATH-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882277#comment-13882277 ] Luc Maisonobe commented on MATH-1094: - I think the behaviour is correct. The getSolver method for QR decomposition provides a solver for A X = B in the least squares sense. This means the X comuted by the solver is minimizes || A X - B ||, it does not find 0, only a minumum norm. In your case, the system is rectangular, so there is no way a true solution can be achieved. I have verified (using simple loops and gnuplot countour plots) that indeed the x = 7.5, y = 5.5 does minimizes the norm, which is 39.0. > Incorrect linear system solution > > > Key: MATH-1094 > URL: https://issues.apache.org/jira/browse/MATH-1094 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: Oracle JDK7 > Linux x86-64 >Reporter: Bogdan Bezpartochnyy > Labels: patch > Attachments: Main.java > > > Firstly I would like to point out that I'm not very proficient in linear > algebra, but in my opinion the following behavior should not occur. When I > solve the following linear system by hand it has no solution, but in commons > math using QRDecomposition it outputs x1= 7.5 x2 = 5.5 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
