[jira] [Created] (SANDBOX-461) FloatToString
Brad Davis created SANDBOX-461:
--
Summary: FloatToString
Key: SANDBOX-461
URL: https://issues.apache.org/jira/browse/SANDBOX-461
Project: Commons Sandbox
Issue Type: Bug
Components: Convert
Affects Versions: Nightly Builds
Reporter: Brad Davis
FloatToString seems to return unexpected results.
Test Case:
@Test
public void testFloatFormat() throws Exception {
Float testFloat = new Float(100.1878783420);
FloatToString fts = new FloatToString();
String format = "###.##";
String v1 = fts.convert(new Float(100.1878783420), Locale.US,
TimeZone.getDefault(), format);
NumberFormat nf = new DecimalFormat("###.##");
String v2 = nf.format(testFloat.floatValue());
Assert.assertEquals("100.19", v1);
Assert.assertEquals("100.19", v2);
}
This class may be the cause:
public static abstract class AbstractNumberConverter extends
AbstractLocalizedConverter {
It seems to drop the "format" string.
Also, the method:
protected String format(Float obj, NumberFormat nf) throws ConversionException {
Should be made public to work around the issue if you want to , for example,
provide the DecimalFormat to the converter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-970) Provide a way to retrieve the best solution found so far when reaching the maxIteration limit in SimplexSolver
[ https://issues.apache.org/jira/browse/MATH-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13766744#comment-13766744 ] Thomas Neidhart commented on MATH-970: -- The disadvantage of this approach is that the user has no means to know if the solution is optimal (within the given epsilon bounds), or the optimizer has just returned the last valid solution before exceeding the max iteration count. I would prefer a SolutionCallback which contains the last valid solution. For some optimizers this is very straight-forward, e.g. for the SimplexSolver you just need a reference to the SimplexTableau and can derive from it the solution. For other optimizers this may not be so simple. > Provide a way to retrieve the best solution found so far when reaching the > maxIteration limit in SimplexSolver > -- > > Key: MATH-970 > URL: https://issues.apache.org/jira/browse/MATH-970 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Thomas Neidhart > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-398) listener.fileRotated() will be invoked more than one time in a real rotate activity
[
https://issues.apache.org/jira/browse/IO-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13766626#comment-13766626
]
Sebb commented on IO-398:
-
On Windows when the Tailer has the file open for read, it's not possible to
delete the file. I've not tested (yet), but I don't think it's possible to
rename the file either. The locking issue is why the reOpen option was added.
Your unit test requires the file to be deleted/renamed. On Windows this can
only be done whilst the Tailer is sleeping.
When it wakes up, it throws FileNotFoundException and stops processing. So it's
not possible to run the unit test on Windows.
But it's not only on Windows that this behaviour will occur. If the Tailer is
set to reOpen, the same can happen on Un*x.
Try it and see (I assume you are not testing on Windows).
So I think we need to fix the reOpen behaviour first, and then this bug can be
addressed.
> listener.fileRotated() will be invoked more than one time in a real rotate
> activity
> ---
>
> Key: IO-398
> URL: https://issues.apache.org/jira/browse/IO-398
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Lantao Jin
> Attachments: IO-398.patch, IO398_with_ut.patch
>
>
>When Tailer considers file rotation is occurred,
> listener.fileRotated() will be execute, and file will re-open by "reader =
> new RandomAccessFile(file, RAF_MODE);". However, the new file may not be
> created yet, FileNotFoundException would be caught and while loop would be
> executed again and again until the new file is actually created, which cause
> listener.fileRotated() triggered repeatedly.
> This is the piece of code causing the problem:
> {noformat}
> while (getRun()) {
> final boolean newer = isFileNewer(file, last); // IO-279, must be done
> first
> // Check the file length to see if it was rotated
> final long length = file.length();
> if (length < position) {
> // File was rotated
> listener.fileRotated();
> // Reopen the reader after rotation
> try {
> // Ensure that the old file is closed iff we re-open it
> successfully
> final RandomAccessFile save = reader;
> reader = new RandomAccessFile(file, RAF_MODE);
> /* some code */
> } catch (final FileNotFoundException e) {
> // in this case we continue to use the previous reader and
> position values
> listener.fileNotFound();
> }
> continue;
> {noformat}
> While condition checkes can be deployed in listener.fileRotated() to
> correct the sematic of fileRotate, it is better to prevent multiple
> invocation of listener.fileRotated() on this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-398) listener.fileRotated() will be invoked more than one time in a real rotate activity
[
https://issues.apache.org/jira/browse/IO-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13766421#comment-13766421
]
Lantao Jin commented on IO-398:
---
I basically know what you mean. But I am not quite understand the mechanism of
file lock in Windows OS.
For this patch, does it mean that it will be accepted after IO-399 has been
fixed? Or, should I provide another unit test to avoid the case on Windows.
> listener.fileRotated() will be invoked more than one time in a real rotate
> activity
> ---
>
> Key: IO-398
> URL: https://issues.apache.org/jira/browse/IO-398
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Lantao Jin
> Attachments: IO-398.patch, IO398_with_ut.patch
>
>
>When Tailer considers file rotation is occurred,
> listener.fileRotated() will be execute, and file will re-open by "reader =
> new RandomAccessFile(file, RAF_MODE);". However, the new file may not be
> created yet, FileNotFoundException would be caught and while loop would be
> executed again and again until the new file is actually created, which cause
> listener.fileRotated() triggered repeatedly.
> This is the piece of code causing the problem:
> {noformat}
> while (getRun()) {
> final boolean newer = isFileNewer(file, last); // IO-279, must be done
> first
> // Check the file length to see if it was rotated
> final long length = file.length();
> if (length < position) {
> // File was rotated
> listener.fileRotated();
> // Reopen the reader after rotation
> try {
> // Ensure that the old file is closed iff we re-open it
> successfully
> final RandomAccessFile save = reader;
> reader = new RandomAccessFile(file, RAF_MODE);
> /* some code */
> } catch (final FileNotFoundException e) {
> // in this case we continue to use the previous reader and
> position values
> listener.fileNotFound();
> }
> continue;
> {noformat}
> While condition checkes can be deployed in listener.fileRotated() to
> correct the sematic of fileRotate, it is better to prevent multiple
> invocation of listener.fileRotated() on this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
