[jira] [Commented] (VFS-422) [SFTP] Allows to create other channels in SftpFileSystem
[ https://issues.apache.org/jira/browse/VFS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435881#comment-13435881 ] Benjamin Piwowarski commented on VFS-422: - Is there any progress on this? [SFTP] Allows to create other channels in SftpFileSystem Key: VFS-422 URL: https://issues.apache.org/jira/browse/VFS-422 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Any Reporter: Benjamin Piwowarski Attachments: 0001-SftpFileSystems-allows-opening-external-channels.patch, vfs-422-v2-by-gg.diff Original Estimate: 3h Remaining Estimate: 3h In the software I am writing, I need to execute commands when the filesystems allows it, i.e. local or via ssh (i.e. sftp filesystem). For a local filesystem, I can easily do this, but for Sftp, there is no way to get a channel different than the SFTP on, so it would be great if other channels could be open. I could submit a patch that would: 1) Allows a call to session.openChannel(String type) [following getChannel()] 2) Overwrite isReleaseable to keep the filesystem open if some external channels are open -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-26) Consider returning a concatenation of the list properties with getString()
[
https://issues.apache.org/jira/browse/CONFIGURATION-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435884#comment-13435884
]
Baris Acar commented on CONFIGURATION-26:
-
Last updates on this issue were in 2007 - did anything happen?
I would argue that {{getString()}} should return the value from the property
file _verbatim_ - not the first item in the list, but not concatenated either -
I'm concerned concatenation could end up slightly changing the format, using
the wrong delimiter, etc. (Ittay's suggestion of returning the string
representation of a List is somewhat ambiguous - does he/she mean
{{List.toString()}}? This may not be what's wanted).
What is the use case for having {{getString}} return the first item of a list
anyway? I have to say as a newcomer to commons config, this is _very_
unexpected behaviour. If someone wants the first item of a list, surely they
_know_ that and can just request {{config.getStringArray(foo)[0]}}, which is
clear and explicit.
As it stands I don't appear to have a way to parse the following config
meaningfully:
{code}
foo=hello, world!
bar=first,second
{code}
with foo as a string (hello, world!) and bar as a list ({first, second}).
Consider returning a concatenation of the list properties with getString()
--
Key: CONFIGURATION-26
URL: https://issues.apache.org/jira/browse/CONFIGURATION-26
Project: Commons Configuration
Issue Type: Bug
Reporter: Ittay Dror
Priority: Minor
Fix For: 2.0
in AbstractConfiguration.resolveContainerStore (javadoc):
* Returns an object from the store described by the key. If the value is a
* List object, replace it with the first object in the list.
but what if getProperty returns a List because this is the type of the
property?
this code will silently grab the first elemen. I don't understand why.
Probably
the reason is that some class extending AbstractConfiguration returns List
for
properties. In this case I think the better approach is to have that class
return the first element instead, rather than returning the List and letting
AbstractConfiguration (which is used by many other implementations, including
outside of the configuration package) handle it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CONFIGURATION-26) Consider returning a concatenation of the list properties with getString()
[
https://issues.apache.org/jira/browse/CONFIGURATION-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435884#comment-13435884
]
Baris Acar edited comment on CONFIGURATION-26 at 8/16/12 9:19 PM:
--
Last updates on this issue were in 2007 - did anything happen?
I would argue that {{getString()}} should return the value from the property
file _verbatim_ - not the first item in the list, but not concatenated either -
I'm concerned concatenation could end up slightly changing the format, using
the wrong delimiter, etc. (Ittay's suggestion of returning the string
representation of a List is somewhat ambiguous - does he/she mean
{{List.toString()}}? This may not be what's wanted).
What is the use case for having {{getString}} return the first item of a list
anyway? I have to say as a newcomer to commons config, this is _very_
unexpected behaviour. If someone wants the first item of a list, surely they
_know_ that and can just request {{config.getStringArray(foo)\[0\]}}, which
is clear and explicit.
As it stands I don't appear to have a way to parse the following config
meaningfully:
{code}
foo=hello, world!
bar=first,second
{code}
with foo as a string (hello, world!) and bar as a list ({first, second}).
was (Author: bacar):
Last updates on this issue were in 2007 - did anything happen?
I would argue that {{getString()}} should return the value from the property
file _verbatim_ - not the first item in the list, but not concatenated either -
I'm concerned concatenation could end up slightly changing the format, using
the wrong delimiter, etc. (Ittay's suggestion of returning the string
representation of a List is somewhat ambiguous - does he/she mean
{{List.toString()}}? This may not be what's wanted).
What is the use case for having {{getString}} return the first item of a list
anyway? I have to say as a newcomer to commons config, this is _very_
unexpected behaviour. If someone wants the first item of a list, surely they
_know_ that and can just request {{config.getStringArray(foo)[0]}}, which is
clear and explicit.
As it stands I don't appear to have a way to parse the following config
meaningfully:
{code}
foo=hello, world!
bar=first,second
{code}
with foo as a string (hello, world!) and bar as a list ({first, second}).
Consider returning a concatenation of the list properties with getString()
--
Key: CONFIGURATION-26
URL: https://issues.apache.org/jira/browse/CONFIGURATION-26
Project: Commons Configuration
Issue Type: Bug
Reporter: Ittay Dror
Priority: Minor
Fix For: 2.0
in AbstractConfiguration.resolveContainerStore (javadoc):
* Returns an object from the store described by the key. If the value is a
* List object, replace it with the first object in the list.
but what if getProperty returns a List because this is the type of the
property?
this code will silently grab the first elemen. I don't understand why.
Probably
the reason is that some class extending AbstractConfiguration returns List
for
properties. In this case I think the better approach is to have that class
return the first element instead, rather than returning the List and letting
AbstractConfiguration (which is used by many other implementations, including
outside of the configuration package) handle it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CONFIGURATION-26) Consider returning a concatenation of the list properties with getString()
[
https://issues.apache.org/jira/browse/CONFIGURATION-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435884#comment-13435884
]
Baris Acar edited comment on CONFIGURATION-26 at 8/16/12 9:19 PM:
--
Last updates on this issue were in 2007 - did anything happen?
I would argue that {{getString()}} should return the value from the property
file _verbatim_ - not the first item in the list, but not concatenated either -
I'm concerned concatenation could end up slightly changing the format, using
the wrong delimiter, etc. (Ittay's suggestion of returning the string
representation of a List is somewhat ambiguous - does he/she mean
{{List.toString()}}? This may not be what's wanted).
What is the use case for having {{getString}} return the first item of a list
anyway? I have to say as a newcomer to commons config, this is _very_
unexpected behaviour. If someone wants the first item of a list, surely they
_know_ that and can just request {{config.getStringArray(foo)\[0\]}}, which
is clear and explicit.
As it stands I don't appear to have a way to parse the following config
meaningfully:
{code}
foo=hello, world!
bar=first,second
{code}
with foo as a string (hello, world!) and bar as a list ({first, second}).
I recently asked about how to do this on SO
http://stackoverflow.com/questions/11973773/can-i-use-both-arrays-and-non-arrays-with-apache-commons-config
was (Author: bacar):
Last updates on this issue were in 2007 - did anything happen?
I would argue that {{getString()}} should return the value from the property
file _verbatim_ - not the first item in the list, but not concatenated either -
I'm concerned concatenation could end up slightly changing the format, using
the wrong delimiter, etc. (Ittay's suggestion of returning the string
representation of a List is somewhat ambiguous - does he/she mean
{{List.toString()}}? This may not be what's wanted).
What is the use case for having {{getString}} return the first item of a list
anyway? I have to say as a newcomer to commons config, this is _very_
unexpected behaviour. If someone wants the first item of a list, surely they
_know_ that and can just request {{config.getStringArray(foo)\[0\]}}, which
is clear and explicit.
As it stands I don't appear to have a way to parse the following config
meaningfully:
{code}
foo=hello, world!
bar=first,second
{code}
with foo as a string (hello, world!) and bar as a list ({first, second}).
Consider returning a concatenation of the list properties with getString()
--
Key: CONFIGURATION-26
URL: https://issues.apache.org/jira/browse/CONFIGURATION-26
Project: Commons Configuration
Issue Type: Bug
Reporter: Ittay Dror
Priority: Minor
Fix For: 2.0
in AbstractConfiguration.resolveContainerStore (javadoc):
* Returns an object from the store described by the key. If the value is a
* List object, replace it with the first object in the list.
but what if getProperty returns a List because this is the type of the
property?
this code will silently grab the first elemen. I don't understand why.
Probably
the reason is that some class extending AbstractConfiguration returns List
for
properties. In this case I think the better approach is to have that class
return the first element instead, rather than returning the List and letting
AbstractConfiguration (which is used by many other implementations, including
outside of the configuration package) handle it
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-422) [SFTP] Allows to create other channels in SftpFileSystem
[ https://issues.apache.org/jira/browse/VFS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435914#comment-13435914 ] Gary D. Gregory commented on VFS-422: - There is a discussion thread here: http://markmail.org/message/lbzqhplulsz2a7a2#query:+page:1+mid:66hcwrqmzlziyssz+state:results This discussion stalled June 22, 2012 though. There appears to be no consensus on which approach to take for adding this kind of feature: implement in the provider itself or with the Operation API. One way to further the discussion is to propose an Operations API implementation, compare it to the cleaned up patch I provided, and argue on the pros and cons of each. [SFTP] Allows to create other channels in SftpFileSystem Key: VFS-422 URL: https://issues.apache.org/jira/browse/VFS-422 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Environment: Any Reporter: Benjamin Piwowarski Attachments: 0001-SftpFileSystems-allows-opening-external-channels.patch, vfs-422-v2-by-gg.diff Original Estimate: 3h Remaining Estimate: 3h In the software I am writing, I need to execute commands when the filesystems allows it, i.e. local or via ssh (i.e. sftp filesystem). For a local filesystem, I can easily do this, but for Sftp, there is no way to get a channel different than the SFTP on, so it would be great if other channels could be open. I could submit a patch that would: 1) Allows a call to session.openChannel(String type) [following getChannel()] 2) Overwrite isReleaseable to keep the filesystem open if some external channels are open -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-255) jsvc cannot find libcap.so on rhel
[
https://issues.apache.org/jira/browse/DAEMON-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436091#comment-13436091
]
John Allison commented on DAEMON-255:
-
Yes, adding the 64 bit locations seems to have worked:
{{
static const char *libcap_locs[] = {
/lib64/libcap.so.2,
/lib64/libcap.so.1,
/lib64/libcap.so,
/lib/libcap.so.2,
/lib/libcap.so.1,
/lib/libcap.so,
/usr/lib64/libcap.so.2,
/usr/lib64/libcap.so.1,
/usr/lib64/libcap.so,
/usr/lib/libcap.so.2,
/usr/lib/libcap.so.1,
/usr/lib/libcap.so,
NULL
};
}}
jsvc cannot find libcap.so on rhel
--
Key: DAEMON-255
URL: https://issues.apache.org/jira/browse/DAEMON-255
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.10
Environment: uname -a
Linux myhost 2.6.18-308.8.2.el5 #1 SMP Tue Jun 12 09:58:12 EDT 2012 x86_64
x86_64 x86_64 GNU/Linux
cat /etc/redhat-release
CentOS release 5.8 (Final)
Reporter: John Allison
Like DAEMON-242 , jsvc will not start:
{{
Attemtping to load library /lib/libcap.so.2
Attemtping to load library /lib/libcap.so.1
Attemtping to load library /lib/libcap.so
Attemtping to load library /usr/lib/libcap.so.2
Attemtping to load library /usr/lib/libcap.so.1
Attemtping to load library /usr/lib/libcap.so
failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared
object file: No such file or directory.
Cannot set group id for user 'tomcat'
set_user_group failed for user 'tomcat'
Service exit with a return value of 4
}}
{{
ls -l /lib*/libcap* /usr/*/libcap*
lrwxrwxrwx 1 root root11 Sep 10 2007 /lib/libcap.so - libcap.so.1
lrwxrwxrwx 1 root root14 Sep 10 2007 /lib/libcap.so.1 - libcap.so.1.10
-rwxr-xr-x 1 root root 11560 Mar 14 2007 /lib/libcap.so.1.10
lrwxrwxrwx 1 root root11 Sep 10 2007 /lib64/libcap.so - libcap.so.1
lrwxrwxrwx 1 root root14 Sep 10 2007 /lib64/libcap.so.1 - libcap.so.1.10
-rwxr-xr-x 1 root root 17384 Mar 14 2007 /lib64/libcap.so.1.10
}}
(formatting doesn't work: that's /usr/STAR/libcapSTAR in the ls)
If I symlink {{/usr/lib/libcap.so - /lib64/libcap.so}} then it starts and
seems to work fine. This did not happen in 1.0.7
Following issue links from DAEMON-242 I tried rerunning autoconf locally. But
there is no -lcap anywhere and ldd doesn't show it.
Perhaps you just need to add /lib64 into the dlopen loop?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-255) jsvc cannot find libcap.so on rhel
[
https://issues.apache.org/jira/browse/DAEMON-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436097#comment-13436097
]
John Allison commented on DAEMON-255:
-
trunk seems to have gone (back?) to {{-lcap}} ??
jsvc cannot find libcap.so on rhel
--
Key: DAEMON-255
URL: https://issues.apache.org/jira/browse/DAEMON-255
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.10
Environment: uname -a
Linux myhost 2.6.18-308.8.2.el5 #1 SMP Tue Jun 12 09:58:12 EDT 2012 x86_64
x86_64 x86_64 GNU/Linux
cat /etc/redhat-release
CentOS release 5.8 (Final)
Reporter: John Allison
Like DAEMON-242 , jsvc will not start:
{{
Attemtping to load library /lib/libcap.so.2
Attemtping to load library /lib/libcap.so.1
Attemtping to load library /lib/libcap.so
Attemtping to load library /usr/lib/libcap.so.2
Attemtping to load library /usr/lib/libcap.so.1
Attemtping to load library /usr/lib/libcap.so
failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared
object file: No such file or directory.
Cannot set group id for user 'tomcat'
set_user_group failed for user 'tomcat'
Service exit with a return value of 4
}}
{{
ls -l /lib*/libcap* /usr/*/libcap*
lrwxrwxrwx 1 root root11 Sep 10 2007 /lib/libcap.so - libcap.so.1
lrwxrwxrwx 1 root root14 Sep 10 2007 /lib/libcap.so.1 - libcap.so.1.10
-rwxr-xr-x 1 root root 11560 Mar 14 2007 /lib/libcap.so.1.10
lrwxrwxrwx 1 root root11 Sep 10 2007 /lib64/libcap.so - libcap.so.1
lrwxrwxrwx 1 root root14 Sep 10 2007 /lib64/libcap.so.1 - libcap.so.1.10
-rwxr-xr-x 1 root root 17384 Mar 14 2007 /lib64/libcap.so.1.10
}}
(formatting doesn't work: that's /usr/STAR/libcapSTAR in the ls)
If I symlink {{/usr/lib/libcap.so - /lib64/libcap.so}} then it starts and
seems to work fine. This did not happen in 1.0.7
Following issue links from DAEMON-242 I tried rerunning autoconf locally. But
there is no -lcap anywhere and ldd doesn't show it.
Perhaps you just need to add /lib64 into the dlopen loop?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-847) Using Rotation to convert Euler angles to Quaternions produces wrong results
M@ Dunlap created MATH-847:
--
Summary: Using Rotation to convert Euler angles to Quaternions
produces wrong results
Key: MATH-847
URL: https://issues.apache.org/jira/browse/MATH-847
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: 1.6
Reporter: M@ Dunlap
import org.apache.commons.math3.geometry.euclidean.threed.Rotation;
import org.apache.commons.math3.geometry.euclidean.threed.RotationOrder;
public class temp {
public static void main(String args[]) {
Rotation r = new Rotation(RotationOrder.XYZ, -Math.PI / 2d, 0, 0);
System.out.println(( + r.getQ0() + + r.getQ1() + + r.getQ2() +
+ r.getQ3() + ));
}
}
Prints (0.707 0.707 0.0 0.0) (in-sig-figs elided), but when I type the same
thing into Wolfram Alpha I get (.707 -.707 0 0) (note the negative) see:
http://www.wolframalpha.com/input/?i=euler+anglesa=*C.euler+angles-_*Formula.dflt-a=*FP.EulerRotation.EAS-_e123f3=-pi%2F2+radf=EulerRotation.th1_-pi%2F2+radf4=0f=EulerRotation.th2_0f5=0f=EulerRotation.th3_0
One of the guys in the lab suggested that if Rotation is assuming the Euler
angle is in a left-handed coordinate space this is an expected result, but if
that's the case the question is, why is the less popular coordinate system the
only option?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FUNCTOR-14) Enhancements on the Generator API
[ https://issues.apache.org/jira/browse/FUNCTOR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436248#comment-13436248 ] Bruno P. Kinoshita commented on FUNCTOR-14: --- Created a branch in SVN to work on this issue. Author: kinow Date: Thu Aug 16 19:09:10 2012 New Revision: 1373984 URL: http://svn.apache.org/viewvc?rev=1373984view=rev Log: Creating a branch to work on FUNCTOR-14 issue: Enhancements on the Generator API Enhancements on the Generator API - Key: FUNCTOR-14 URL: https://issues.apache.org/jira/browse/FUNCTOR-14 Project: Commons Functor Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Priority: Minor Apparently, the Generator API in [functor] was created based on Python generators. However, there is room for enhancements in the current implementation. The Generator interface contains methods to stop its execution. However not all generators are necessarily 'stoppable'. Maybe we could move this behavior to a separate interface. The parameters passed to a generator (from, to, step) are the same that, in Python, can be used to create a Range. Ranges are used in many examples of Generators in Python. We could include Ranges in [functor] and utilize them in Generators. It would be good if we could include/exclude the Range boundary values, i.e. we could create a Range 0..2, and define 0 or 2, as being either inclusive or exclusive. Among the current generators, there is one for Integer's, and another one for Long's. We could create generators for other types too (e.g.: Char, Date, Double, Float, ...). Another feature usually related to Generators in Python is the yield statement. There are some API's in Java that provide a yield implementation. This is not entirely necessary, but could be convenient to include it to [functor] too, combined with Generators. Maybe in [functor] we could create a YieldProcedure. This way, the Generator would yield its values to this procedure. Just food for thought. This issue is quite vague, so feel free to add comments, or criticize. This way we can achieve a common consensus on a new and awesome Generator API for [functor]. No hard feelings :-) Cheers -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-847) Using Rotation to convert Euler angles to Quaternions produces wrong results
[
https://issues.apache.org/jira/browse/MATH-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436256#comment-13436256
]
Luc Maisonobe commented on MATH-847:
This is a question rather than a bug report, so it should be on the users
mailing list, not on Jira.
Nevertheless, the answer to this question is not that we use a left handed
coordinate system, it is that the angles are counted from a vectorial operator
point of view, not from a frame conversion point of view. Please read the
javadoc for all methods and for the class for an explanation.
Using Rotation to convert Euler angles to Quaternions produces wrong results
Key: MATH-847
URL: https://issues.apache.org/jira/browse/MATH-847
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: 1.6
Reporter: M@ Dunlap
import org.apache.commons.math3.geometry.euclidean.threed.Rotation;
import org.apache.commons.math3.geometry.euclidean.threed.RotationOrder;
public class temp {
public static void main(String args[]) {
Rotation r = new Rotation(RotationOrder.XYZ, -Math.PI / 2d, 0, 0);
System.out.println(( + r.getQ0() + + r.getQ1() + + r.getQ2() +
+ r.getQ3() + ));
}
}
Prints (0.707 0.707 0.0 0.0) (in-sig-figs elided), but when I type the same
thing into Wolfram Alpha I get (.707 -.707 0 0) (note the negative) see:
http://www.wolframalpha.com/input/?i=euler+anglesa=*C.euler+angles-_*Formula.dflt-a=*FP.EulerRotation.EAS-_e123f3=-pi%2F2+radf=EulerRotation.th1_-pi%2F2+radf4=0f=EulerRotation.th2_0f5=0f=EulerRotation.th3_0
One of the guys in the lab suggested that if Rotation is assuming the Euler
angle is in a left-handed coordinate space this is an expected result, but if
that's the case the question is, why is the less popular coordinate system
the only option?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-393) Split / Partition a collection into smaller collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436272#comment-13436272 ] Thomas Neidhart commented on COLLECTIONS-393: - The code seems to have been adapted from google guava, which is fair enough as it is under Apache license itself. Similar to guava, I would embed the functionality in ListUtils and hide actual Partition implementation. Split / Partition a collection into smaller collections --- Key: COLLECTIONS-393 URL: https://issues.apache.org/jira/browse/COLLECTIONS-393 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Chris Shayan Fix For: 4.0 Attachments: Partition.java, TestPartition.java Original Estimate: 24h Remaining Estimate: 24h Returns consecutive sublists of a list, each of the same size (the final list may be smaller). For example, partitioning a list containing [a, b, c, d, e] with a partition size of 3 yields [[a, b, c], [d, e]] -- an outer list containing two inner lists of three and two elements, all in the original order. The outer list is unmodifiable, but reflects the latest state of the source list. The inner lists are sublist views of the original list, produced on demand using List.subList(int, int), and are subject to all the usual caveats about modification as explained in that API. Adapted from http://code.google.com/p/google-collections/ Inspired by Lars Vogel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-393) Split / Partition a collection into smaller collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-393: Fix Version/s: 4.0 Split / Partition a collection into smaller collections --- Key: COLLECTIONS-393 URL: https://issues.apache.org/jira/browse/COLLECTIONS-393 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Chris Shayan Fix For: 4.0 Attachments: Partition.java, TestPartition.java Original Estimate: 24h Remaining Estimate: 24h Returns consecutive sublists of a list, each of the same size (the final list may be smaller). For example, partitioning a list containing [a, b, c, d, e] with a partition size of 3 yields [[a, b, c], [d, e]] -- an outer list containing two inner lists of three and two elements, all in the original order. The outer list is unmodifiable, but reflects the latest state of the source list. The inner lists are sublist views of the original list, produced on demand using List.subList(int, int), and are subject to all the usual caveats about modification as explained in that API. Adapted from http://code.google.com/p/google-collections/ Inspired by Lars Vogel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-398) BoundedFifoBuffer could be simplified by keeping a count of the number of entries
[ https://issues.apache.org/jira/browse/COLLECTIONS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436275#comment-13436275 ] Thomas Neidhart commented on COLLECTIONS-398: - The buffer implementations may be removed in favor of the Queue / Deque interfaces / implementation available in java.util. BoundedFifoBuffer could be simplified by keeping a count of the number of entries - Key: COLLECTIONS-398 URL: https://issues.apache.org/jira/browse/COLLECTIONS-398 Project: Commons Collections Issue Type: Improvement Reporter: Sebb Attachments: COLLECTIONS-398-2.patch, COLLECTIONS-398.patch BoundedFifoBuffer could be much simplified by keeping a count of the number of entries, and dropping the boolean full. This would speed up size() and isEmpty() and isFull(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-848) EigenDecomposition fails for certain matrices
Thomas Neidhart created MATH-848:
Summary: EigenDecomposition fails for certain matrices
Key: MATH-848
URL: https://issues.apache.org/jira/browse/MATH-848
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.1
Reporter: Thomas Neidhart
Assignee: Thomas Neidhart
Fix For: 3.1
The Schurtransformation of the following matrix fails, which is a preliminary
step for the Eigendecomposition:
RealMatrix m =
MatrixUtils.DEFAULT_FORMAT.parse({{0.184944928,-0.0646971046,0.0774755812,-0.0969651755,-0.0692648806,0.3282344352,-0.0177423074,0.206313634},{-0.0742700134,-0.028906303,-0.001726946,-0.0375550146,-0.0487737922,-0.2616837868,-0.0821201295,-0.253167},{0.2549910127,0.0995733692,-0.0009718388,0.0149282808,0.1791878897,-0.0823182816,0.0582629256,0.3219545182},{-0.0694747557,-0.1880649148,-0.2740630911,0.0720096468,-0.1800836914,-0.3518996425,0.2486747833,0.6257938167},{0.0536360918,-0.1339297778,0.2241579764,-0.0195327484,-0.0054103808,0.0347564518,0.5120802482,-0.0329902864},{-0.592356,-0.2488721082,0.2357173629,0.0177285473,0.0856630593,-0.35671263,-0.1600668126,-0.1010899621},{-0.0514349819,-0.0854319435,0.1125050061,0.006345356,-0.225688,-0.220934309,0.1964623477,-0.1512329924},{0.0197395947,-0.1997170581,-0.1425959019,-0.274947791,-0.0969467073,0.060368852,-0.2826905192,0.1794315473}});
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-844) HarmonicFitter.ParameterGuesser sometimes fails to return sensible values
[ https://issues.apache.org/jira/browse/MATH-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-844. - Resolution: Fixed As of revision 1374046, the code will generate an exception. HarmonicFitter.ParameterGuesser sometimes fails to return sensible values --- Key: MATH-844 URL: https://issues.apache.org/jira/browse/MATH-844 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Gilles Priority: Minor Fix For: 3.1 Attachments: MATH-844.test.patch The inner class ParameterGuesser in HarmonicFitter (package o.a.c.m.optimization.fitting) fails to compute a usable guess for the amplitude parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-393) Split / Partition a collection into smaller collections
[ https://issues.apache.org/jira/browse/COLLECTIONS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-393. - Resolution: Fixed Added patch in r1374049 with minor modifications to ListUtils. Thanks for the report and patch! Split / Partition a collection into smaller collections --- Key: COLLECTIONS-393 URL: https://issues.apache.org/jira/browse/COLLECTIONS-393 Project: Commons Collections Issue Type: New Feature Components: Collection Reporter: Chris Shayan Fix For: 4.0 Attachments: Partition.java, TestPartition.java Original Estimate: 24h Remaining Estimate: 24h Returns consecutive sublists of a list, each of the same size (the final list may be smaller). For example, partitioning a list containing [a, b, c, d, e] with a partition size of 3 yields [[a, b, c], [d, e]] -- an outer list containing two inner lists of three and two elements, all in the original order. The outer list is unmodifiable, but reflects the latest state of the source list. The inner lists are sublist views of the original list, produced on demand using List.subList(int, int), and are subject to all the usual caveats about modification as explained in that API. Adapted from http://code.google.com/p/google-collections/ Inspired by Lars Vogel -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-841) gcd speed up
[
https://issues.apache.org/jira/browse/MATH-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436337#comment-13436337
]
Gilles commented on MATH-841:
-
Please use more space (around keywords, operators, etc.).
Same style remarks as for
[MATH-845|https://issues.apache.org/jira/browse/MATH-845?focusedCommentId=13434211page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13434211].
Thanks.
gcd speed up
Key: MATH-841
URL: https://issues.apache.org/jira/browse/MATH-841
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Environment: ubuntu 32bits/intel-i5/java6
Reporter: Sebastien Riou
Priority: Trivial
Labels: patch, performance
Fix For: 3.1
Attachments: ArithmeticUtils.java, patchGcdInt3.txt
Original Estimate: 1h
Remaining Estimate: 1h
The gcd(int,int) method of ArithmeticUtils seems 2 times slower than the
naive approach using modulo operator. The following test code runs in 11s
with current version and in 6s with the patch.
public void testApache(){
Random rng=new Random(0);
long checksum=0;
long start=System.nanoTime();
checksum+=gcd(0,Integer.MAX_VALUE);
checksum+=gcd(Integer.MAX_VALUE,0);
checksum+=gcd(Integer.MAX_VALUE,rng.nextInt());
for(int i=0;i1;i++)
checksum+=gcd(rng.nextInt(),Integer.MAX_VALUE);
checksum+=gcd(Integer.MAX_VALUE,Integer.MAX_VALUE);
checksum+=gcd(Integer.MIN_VALUE,130);
checksum+=gcd(130,130);
checksum+=gcd(3 * (120),9 * (115));
for(int i=0;i3000;i++)
checksum+=gcd(rng.nextInt(),rng.nextInt());
long end=System.nanoTime();
long tns=end-start;
long tms=(tns+50)/100;
long ts=(tms+500)/1000;
System.out.println(exec time=+ts+s, (+tms+ms),
checksum=+checksum);
assertEquals(9023314441L,checksum);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-843) Precision.EPSILON: wrong documentation
[
https://issues.apache.org/jira/browse/MATH-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-843:
Fix Version/s: 3.1
Precision.EPSILON: wrong documentation
--
Key: MATH-843
URL: https://issues.apache.org/jira/browse/MATH-843
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dominik Gruntz
Priority: Minor
Labels: documentation
Fix For: 3.1
Original Estimate: 0.5h
Remaining Estimate: 0.5h
The documentation of the Field {{EPSILON}} in class
{{org.apache.commons.math3.util.Precision}} states, that {{EPSILON}} is the
smallest positive number such that {{1 - EPSILON}} is not numerically equal
to 1, and its value is defined as 1.1102230246251565E-16.
However, this is NOT the smallest positive number with this property.
Consider the following program:
{code}
public class Eps {
public static void main(String[] args) {
double e = Double.longBitsToDouble(0x3c91L);
double e1 = 1-e;
System.out.println(e);
System.out.println(1-e);
System.out.println(1-e != 1);
}
}
{code}
The output is:
{code}
% java Eps
5.551115123125784E-17
0.
true
{code}
This proves, that there are smaller positive numbers with the property that
1-eps != 1.
I propose not to change the constant value, but to update the documentation.
The value {{Precision.EPSILON}} is
an upper bound on the relative error which occurs when a real number is
rounded to its nearest Double floating-point number. I propose to update
the api docs in this sense.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-847) Using Rotation to convert Euler angles to Quaternions produces wrong results
[
https://issues.apache.org/jira/browse/MATH-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436347#comment-13436347
]
Gilles commented on MATH-847:
-
Can we close this report?
Using Rotation to convert Euler angles to Quaternions produces wrong results
Key: MATH-847
URL: https://issues.apache.org/jira/browse/MATH-847
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: 1.6
Reporter: M@ Dunlap
import org.apache.commons.math3.geometry.euclidean.threed.Rotation;
import org.apache.commons.math3.geometry.euclidean.threed.RotationOrder;
public class temp {
public static void main(String args[]) {
Rotation r = new Rotation(RotationOrder.XYZ, -Math.PI / 2d, 0, 0);
System.out.println(( + r.getQ0() + + r.getQ1() + + r.getQ2() +
+ r.getQ3() + ));
}
}
Prints (0.707 0.707 0.0 0.0) (in-sig-figs elided), but when I type the same
thing into Wolfram Alpha I get (.707 -.707 0 0) (note the negative) see:
http://www.wolframalpha.com/input/?i=euler+anglesa=*C.euler+angles-_*Formula.dflt-a=*FP.EulerRotation.EAS-_e123f3=-pi%2F2+radf=EulerRotation.th1_-pi%2F2+radf4=0f=EulerRotation.th2_0f5=0f=EulerRotation.th3_0
One of the guys in the lab suggested that if Rotation is assuming the Euler
angle is in a left-handed coordinate space this is an expected result, but if
that's the case the question is, why is the less popular coordinate system
the only option?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-809) Expressions and functions interpreter
[ https://issues.apache.org/jira/browse/MATH-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436352#comment-13436352 ] Gilles commented on MATH-809: - The dev ML [thread|http://markmail.org/message/w5pvo7sp6y67wsbf] did not reach a conclusion. Please revive it if you still think that the feature fits within Commons Math. Expressions and functions interpreter - Key: MATH-809 URL: https://issues.apache.org/jira/browse/MATH-809 Project: Commons Math Issue Type: New Feature Affects Versions: 3.1 Reporter: Guillaume Chauvet Priority: Trivial Attachments: interpreter.patch Expressions and functions interpreter forked from exp4j library (http://projects.congrace.de/exp4j, an Apache 2 project). This implementation use Dijkstra's Shunting Yard Algorithm. The patch also allows parsing of E notation numbers in expressions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-847) Using Rotation to convert Euler angles to Quaternions produces wrong results
[
https://issues.apache.org/jira/browse/MATH-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13436354#comment-13436354
]
M@ Dunlap commented on MATH-847:
Sure. Can we ammend it to ask that the part of the javadoc that describes this
be moved from the one constructor to the whole class since it applies no matter
how the rotation is constructed?
Using Rotation to convert Euler angles to Quaternions produces wrong results
Key: MATH-847
URL: https://issues.apache.org/jira/browse/MATH-847
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: 1.6
Reporter: M@ Dunlap
import org.apache.commons.math3.geometry.euclidean.threed.Rotation;
import org.apache.commons.math3.geometry.euclidean.threed.RotationOrder;
public class temp {
public static void main(String args[]) {
Rotation r = new Rotation(RotationOrder.XYZ, -Math.PI / 2d, 0, 0);
System.out.println(( + r.getQ0() + + r.getQ1() + + r.getQ2() +
+ r.getQ3() + ));
}
}
Prints (0.707 0.707 0.0 0.0) (in-sig-figs elided), but when I type the same
thing into Wolfram Alpha I get (.707 -.707 0 0) (note the negative) see:
http://www.wolframalpha.com/input/?i=euler+anglesa=*C.euler+angles-_*Formula.dflt-a=*FP.EulerRotation.EAS-_e123f3=-pi%2F2+radf=EulerRotation.th1_-pi%2F2+radf4=0f=EulerRotation.th2_0f5=0f=EulerRotation.th3_0
One of the guys in the lab suggested that if Rotation is assuming the Euler
angle is in a left-handed coordinate space this is an expected result, but if
that's the case the question is, why is the less popular coordinate system
the only option?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-98) Add JavaDoc to QueryRunner#insert
Moandji Ezana created DBUTILS-98: Summary: Add JavaDoc to QueryRunner#insert Key: DBUTILS-98 URL: https://issues.apache.org/jira/browse/DBUTILS-98 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Fix For: 1.6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-98) Add JavaDoc to QueryRunner#insert
[ https://issues.apache.org/jira/browse/DBUTILS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moandji Ezana updated DBUTILS-98: - Attachment: QueryRunner_insert_add_javadoc.patch QueryRunner_insert_add_javadoc.patch adds the missing documentation. Add JavaDoc to QueryRunner#insert - Key: DBUTILS-98 URL: https://issues.apache.org/jira/browse/DBUTILS-98 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Fix For: 1.6 Attachments: QueryRunner_insert_add_javadoc.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBUTILS-98) Add JavaDoc to QueryRunner#insert
[ https://issues.apache.org/jira/browse/DBUTILS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moandji Ezana updated DBUTILS-98: - Priority: Minor (was: Major) Add JavaDoc to QueryRunner#insert - Key: DBUTILS-98 URL: https://issues.apache.org/jira/browse/DBUTILS-98 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Priority: Minor Fix For: 1.6 Attachments: QueryRunner_insert_add_javadoc.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
