[jira] [Commented] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651665#comment-13651665 ] maurel jean francois commented on COMPRESS-111: --- Hi, For your information MinGW project uses lzma compression. http://sourceforge.net/projects/mingw/files/MinGW/Base/mingw-rt/mingwrt-4.0/ Regards > support for lzma files > -- > > Key: COMPRESS-111 > URL: https://issues.apache.org/jira/browse/COMPRESS-111 > Project: Commons Compress > Issue Type: New Feature > Components: Compressors >Affects Versions: 1.0 >Reporter: maurel jean francois > Attachments: compress-trunk-lzmaRev0.patch, > compress-trunk-lzmaRev1.patch > > > adding support for compressing and decompressing of files with LZMA algoritm > (Lempel-Ziv-Markov chain-Algorithm) > (see > http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- 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] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651609#comment-13651609 ] Stefan Bodewig commented on COMPRESS-111: - We've decided to use the "store in memory" approach in the pack200 case which has the same problem. As an alternative there is a temp-file solution - write the stream to disk and re-read it from there. This can be used for big inputs and is offered for pack200 as well. We briefly discussed the thread model back then, it could probably be added as a third strategy. We already depend on XZ for Java for the XZ streams, so any solution based on Lasse's code wouldn't require us to use any other external dependency which would be great. Lasse responded to this issue about two years ago so he'll likely see our comments :-) > support for lzma files > -- > > Key: COMPRESS-111 > URL: https://issues.apache.org/jira/browse/COMPRESS-111 > Project: Commons Compress > Issue Type: New Feature > Components: Compressors >Affects Versions: 1.0 >Reporter: maurel jean francois > Attachments: compress-trunk-lzmaRev0.patch, > compress-trunk-lzmaRev1.patch > > > adding support for compressing and decompressing of files with LZMA algoritm > (Lempel-Ziv-Markov chain-Algorithm) > (see > http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- 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] (CODEC-140) isBase64 returns true for any UTF8 string
[
https://issues.apache.org/jira/browse/CODEC-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651596#comment-13651596
]
btpka3 commented on CODEC-140:
--
Should enhance Base64.isBase64(byte[]) to check (1) lengh%4==0 after remove
whitespace (2) '=' can not occured in the middle ?
> isBase64 returns true for any UTF8 string
> -
>
> Key: CODEC-140
> URL: https://issues.apache.org/jira/browse/CODEC-140
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: windows/linux
>Reporter: Mohit Anchlia
>Assignee: Julius Davies
>
> I just called Base64.isBase64("Hello") for instance and it returns true. I
> thought it would return true only if it is valid base64 encoded string.
--
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-973) Geometric distribution support
[ https://issues.apache.org/jira/browse/MATH-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651341#comment-13651341 ] Mauro Tortonesi commented on MATH-973: -- Dear Thomas, thank you very much for your prompt response! > Geometric distribution support > -- > > Key: MATH-973 > URL: https://issues.apache.org/jira/browse/MATH-973 > Project: Commons Math > Issue Type: Improvement >Reporter: Mauro Tortonesi >Priority: Minor > Labels: distribution > Fix For: 4.0 > > Attachments: apache-commons-math-geometric-distribution-support.diff > > > The included patch implements support for the geometric probability > distribution function: > http://en.wikipedia.org/wiki/Geometric_distribution > http://mathworld.wolfram.com/GeometricDistribution.html -- 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] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651308#comment-13651308 ] Damjan Jovanovic commented on COMPRESS-111: --- The fundamental problem is that Commons Compress does decompression via CompressorInputStream’s read() methods, which are a pull-model interface, while the LZMA SDK (in the public domain) does it with Decoder.code(), a method that takes a compressed input stream and an output stream to decompress to, then reads, decompresses, and writes, only returning when the entire file is decompressed. There is no way to convert this to a pull-model CompressorInputStream: either you have to pull in one thread while pushing from another, or push everything into a ByteArrayInputStream (which needs O\(n) memory!!) and then pull from that afterwards. Both are really ugly solutions: thread per stream is heavy and creating new threads is not allowed in some environments (eg. unsigned Applets and Java EE servers), while trying to allocate O\(n) memory can OutOfMemoryError the entire JVM. The Java LZMA attempts out there rate as follows: Maurel’s patch here uses O\(n) memory, and decompresses the entire stream in the constructor and stores it in a ByteArrayInputStream which is then copied from on each read(). http://jponge.github.io/lzma-java/ is licensed ASLv2 and states how it solved the push/pull problem: “Although not a derivate work, the streaming api classes were inspired from the work of Christopher League. I reused his technique of fake streams and working threads to pass the data around between encoders/decoders and "normal" Java streams.” In other words, it pushes in one thread and pulls in another. Actual decompression in the other thread is still done with the LZMA SDK, which it just wraps into an InputStream subclass. http://contrapunctus.net/league/haques/lzmajio/ was done by Christopher League, it’s under “LGPL or the Common Public License” and has the same push in one thread pull in another story. It’s also just a wrapper of the LZMA SDK. http://tukaani.org/xz/java.html is in the public domain and is already used by Commons Compress to provide XZ compression support. It supports XZ and LZMA2 only and supports them well - proper pull-model InputStream with no O\(n) memory or background threads. LZMA2 is a different file format from LZMA. But then again LZMA2 uses LZMA internally. I’ll have to investigate in detail. > support for lzma files > -- > > Key: COMPRESS-111 > URL: https://issues.apache.org/jira/browse/COMPRESS-111 > Project: Commons Compress > Issue Type: New Feature > Components: Compressors >Affects Versions: 1.0 >Reporter: maurel jean francois > Attachments: compress-trunk-lzmaRev0.patch, > compress-trunk-lzmaRev1.patch > > > adding support for compressing and decompressing of files with LZMA algoritm > (Lempel-Ziv-Markov chain-Algorithm) > (see > http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- 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-740) Some "FastMath" functions are slow
[ https://issues.apache.org/jira/browse/MATH-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651281#comment-13651281 ] Thomas Neidhart commented on MATH-740: -- fyi: I used jafama at my work (lots of geodetic calculations) and it was quite successful. I do not yet have objective figures, but for example a complex simulation (normally takes ~27 min) could be reduced by 3 min by delegating the math implementation to jafama. > Some "FastMath" functions are slow > -- > > Key: MATH-740 > URL: https://issues.apache.org/jira/browse/MATH-740 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 4.0 > > Attachments: jafamatests.zip > > > From the two benchmarks we currently have in "FastMathTestPerfomance", we > have that the following functions are much slower in "FastMath" than in > either "Math" or "StrictMath" (the performance *loss*, for each of the > benchmarks, is given in parentheses): > * log10 (46%, 36%) > * log1p (68%, 112%) > * tan (11%, 61%) > * atan (26%, 125%) > * atan2 (44%, 40%) -- 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] (COMPRESS-54) Add 7zip or RAR archive support
[ https://issues.apache.org/jira/browse/COMPRESS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651277#comment-13651277 ] Damjan Jovanovic commented on COMPRESS-54: -- As of revision 1480055, I've committed read-only support for 7z archives to SVN trunk. But we have no LZMA compression support yet, so it can only read archives made with special options - see the Javadoc for SevenZFile for details. > Add 7zip or RAR archive support > --- > > Key: COMPRESS-54 > URL: https://issues.apache.org/jira/browse/COMPRESS-54 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers > Environment: N/A >Reporter: Tim Pinet >Priority: Minor > Original Estimate: 30h > Remaining Estimate: 30h > > Has anyone looked into adding support for 7zip and RAR file types? Using the > j7zip and junrar libraries I was able to get a rough protoype working with > commons-compress but only with extract support for RAR (due to licencing > issues). Also, my prototype performance is poor so I definately need to > improve it. -- 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] [Resolved] (MATH-973) Geometric distribution support
[ https://issues.apache.org/jira/browse/MATH-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-973. -- Resolution: Fixed Fix Version/s: 4.0 Thanks for the patch and report! Applied it together with minor changes in r1480064. I also changed the input validation check for the probability to (0, 1] as the geometric distribution is defined for this range, although a value of 1 will not produce very useful results. > Geometric distribution support > -- > > Key: MATH-973 > URL: https://issues.apache.org/jira/browse/MATH-973 > Project: Commons Math > Issue Type: Improvement >Reporter: Mauro Tortonesi >Priority: Minor > Labels: distribution > Fix For: 4.0 > > Attachments: apache-commons-math-geometric-distribution-support.diff > > > The included patch implements support for the geometric probability > distribution function: > http://en.wikipedia.org/wiki/Geometric_distribution > http://mathworld.wolfram.com/GeometricDistribution.html -- 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] [Resolved] (MATH-968) Pareto distribution is missing
[ https://issues.apache.org/jira/browse/MATH-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-968. -- Resolution: Fixed Fix Version/s: 4.0 Added patch in r1480056. > Pareto distribution is missing > -- > > Key: MATH-968 > URL: https://issues.apache.org/jira/browse/MATH-968 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.2 >Reporter: Alex Gryzlov >Priority: Minor > Fix For: 4.0 > > Attachments: MATH-968.zip > > > Seems that org.apache.commons.math3.distribution lacks a ParetoDistribution > for some reason. This is a real common type of distribution, so providing it > would be very nice! -- 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] [Updated] (MATH-973) Geometric distribution support
[ https://issues.apache.org/jira/browse/MATH-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Tortonesi updated MATH-973: - Attachment: apache-commons-math-geometric-distribution-support.diff All the tests pass. I have not defined a serialVersionUID, though. > Geometric distribution support > -- > > Key: MATH-973 > URL: https://issues.apache.org/jira/browse/MATH-973 > Project: Commons Math > Issue Type: Improvement >Reporter: Mauro Tortonesi >Priority: Minor > Labels: distribution > Attachments: apache-commons-math-geometric-distribution-support.diff > > > The included patch implements support for the geometric probability > distribution function: > http://en.wikipedia.org/wiki/Geometric_distribution > http://mathworld.wolfram.com/GeometricDistribution.html -- 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] [Created] (MATH-973) Geometric distribution support
Mauro Tortonesi created MATH-973: Summary: Geometric distribution support Key: MATH-973 URL: https://issues.apache.org/jira/browse/MATH-973 Project: Commons Math Issue Type: Improvement Reporter: Mauro Tortonesi Priority: Minor The included patch implements support for the geometric probability distribution function: http://en.wikipedia.org/wiki/Geometric_distribution http://mathworld.wolfram.com/GeometricDistribution.html -- 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-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650965#comment-13650965 ] oskar_hertwig commented on MATH-972: Ok, That's clear. Thank you for your time. The issue is closed for me. > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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] [Resolved] (CSV-98) Line number counting is confusing
[ https://issues.apache.org/jira/browse/CSV-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-98. - Resolution: Fixed Resolved by adjusting the EOL count if reader is currently processing a line and has yet to reach EOL. Renamed the methods and adjusted the single test case that relied on the odd numbering scheme. URL: http://svn.apache.org/r1479936 Log: CSV-98 Line number counting is confusing Modified: commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVLexer.java commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVParser.java commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/ExtendedBufferedReader.java commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/Lexer.java commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVLexer1.java commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVLexer1306663.java commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVLexer1306667.java commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVLexer3.java commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVParserTest.java commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/ExtendedBufferedReaderTest.java > Line number counting is confusing > - > > Key: CSV-98 > URL: https://issues.apache.org/jira/browse/CSV-98 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb > > The original code counts EOLs only (CR/LF/CRLF), starting from 0. > Thus the line number stays as 0 until the EOL of the first line is seen. > This is confusing: if a parsing error is detected before EOL is reached on > the first line it will be reported as line 0, whereas if the error is > detected after EOL is detected but before any other characters are read it > will be reported as line 1. However as far as the user is concerned in both > cases the syntax error is in line 1. > The current line number should start at 0 (when nothing has been processed) > and be returned as line 1 from the 1st character read up until the end of the > first line. -- 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-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650950#comment-13650950 ] Gilles commented on MATH-972: - bq. [...] about the object returned by LinearInterpolator [...] should not be derivable on the entire domain [...] Strictly speaking it is not, since the "interpolate" method in "UnivariateInterpolator" is defined to return a "UnivariateFunction". The actual object used is an "implementation detail" which users should not rely on. At first sight, your "PiecewiseLinearFunction" is just another name for a special case of our "PolynomialSplineFunction" (where all its components have degree 1). IMHO, it doesn't warrant the code duplication. It seemed that the name "PolynomialSplineFunction" is at the origin of the confusion. > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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] [Created] (CSV-98) Line number counting is confusing
Sebb created CSV-98: --- Summary: Line number counting is confusing Key: CSV-98 URL: https://issues.apache.org/jira/browse/CSV-98 Project: Commons CSV Issue Type: Bug Reporter: Sebb The original code counts EOLs only (CR/LF/CRLF), starting from 0. Thus the line number stays as 0 until the EOL of the first line is seen. This is confusing: if a parsing error is detected before EOL is reached on the first line it will be reported as line 0, whereas if the error is detected after EOL is detected but before any other characters are read it will be reported as line 1. However as far as the user is concerned in both cases the syntax error is in line 1. The current line number should start at 0 (when nothing has been processed) and be returned as line 1 from the 1st character read up until the end of the first line. -- 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] [Updated] (MATH-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] oskar_hertwig updated MATH-972: --- Attachment: (was: PiecewiseLinearFunction.java) > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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] [Updated] (MATH-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] oskar_hertwig updated MATH-972: --- Attachment: (was: Test.java) > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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] [Updated] (MATH-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] oskar_hertwig updated MATH-972: --- Attachment: PiecewiseLinearFunction.java Test.java > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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] [Updated] (MATH-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] oskar_hertwig updated MATH-972: --- Attachment: Test.java PiecewiseLinearFunction.java > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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-972) LinearInterpolator Misconception
[ https://issues.apache.org/jira/browse/MATH-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650888#comment-13650888 ] oskar_hertwig commented on MATH-972: Hi Gilles, First of all tanks for your quick response. I went a little bit too fast in my bug report and it appears I screw up and your code is ok. (The code is in test.java) Nevertheless I am stilling interrogating myself about the object returned by Linear Interpolator. Indeed, the function returned by a linear interpolator should not be derivable on the entire domain (on each knots points) although a Polynomial Spline Function is always derivable inside the definition domain. Consequently your solution allows using the Derivative Method with no restriction although exceptions should be raised in some points. (After test your code returns the derivative number at right) So I am asking to you if it wouldn’t be better that linear Interpolator returns PiecewiseLinearFunction (I add the code is in PiecewiseLinearFunction.java) which implements UnivariateFunction but not DifferentiableUnivariateFunction. In another hand I am aware that my solution doesn’t allow the use of DifferentiableUnivariateSolver. If you find my suggestion is too purist. I have no problem for closing the ticket. Kinds regard. > LinearInterpolator Misconception > > > Key: MATH-972 > URL: https://issues.apache.org/jira/browse/MATH-972 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 > Environment: All >Reporter: oskar_hertwig >Priority: Trivial > Attachments: PiecewiseLinearFunction.java, Test.java > > Original Estimate: 2h > Remaining Estimate: 2h > > The method interpolate() of the class LinearInterpolator return a > polynomialSplineFunction althought a piecewiseContinuousFunction have to be > returned. > This cause a bug. Indeed when the interpolated serie is localy constant the > linear interpolation should lead to constant value between this points. This > is not possible when the returned object is a PolynomialSplineFunction -- 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
