[jira] [Created] (JXPATH-153) Wrong entry IMPORT-PACKAGE in the file MANIFEST.MF for jdom and commons-beanutils
Wrong entry IMPORT-PACKAGE in the file MANIFEST.MF for jdom and commons-beanutils - Key: JXPATH-153 URL: https://issues.apache.org/jira/browse/JXPATH-153 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.3 Reporter: Jens Teutenberg Fix For: 1.4 commons-beanutils and jdom are optional dependencies. But they are configured as required in the entry IMPORT-PACKAGE in the file MANIFEST.MF. -- 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] (PROXY-16) (PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long time in mod_proxy side.
[ https://issues.apache.org/jira/browse/PROXY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved PROXY-16. - Resolution: Invalid Still not the right place for this report ;) Please see : http://httpd.apache.org/bug_report.html (PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long time in mod_proxy side. Key: PROXY-16 URL: https://issues.apache.org/jira/browse/PROXY-16 Project: Commons Proxy Issue Type: Bug Reporter: Wendell L. Hatcher if mod_proxy, but during being FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long time in mod_proxy side. This might be only a small bad effect for this phenomenon, but we think this occurs because of not preferred implementation of Apache httpd mod_proxy. Specifically, mod_prxoy sends FIN by KeepAliveTimeout from backend server side. When it gets it, it returns using FIN and ACK, then wants to release ports that is in use. This is because of the following reasons: *Keeping unnecessary resource for a long time, this might occur some unexpected bugs in the future. *If CLOSE_WAIT condition continues for a long time and then there is Firewall between mod_proxy_http and backend, then you have to keep unnecessary session and this might affect communication session. *If there is FIN and ACK that after there is a long time gap, then it would already be after Firewall destroys that session and Firewall might show warning messages. Also in mod_proxy in Apache 2.0, if client doesn't use KeepAlive, the connection between mod_proxy and backend server ends, and confirms that CLOSE_WAIT doesn't stays. In short, Apache 2.2 doesn't behave good than Apache 2.0. When we compare Apache 2.2 and 2.0 source, in Apache 2.0 mod_proxy, client side TCP session extension of the ending process, it closes TCP session between backend server using apr_socket_close() function. However, in Apache 2.2 mod_proxy_http, it changes as to call connection_clceanup() or socket_cleanup(), and we thiknk this is because it doesn't do apr_socket_close() in the function. In short, 2.2 doesn't close the session that is immediately close when KeepAlive is invalid. We assume that this is a simple bug that forgets to close when mod_proxy's refactoring. (1) Client is HTTP/1.0 and KeepAlive is none, so every time the connection ends by FIN. (2) mod_proxy_http doesn't disconnect after receiving the result of backend server request. (3) Backend server though FIN at 30.007sec by KeepAliveTimeout. mod_proxy_http doesn't return FIN for this. Port 47875 of mod_proxy_http becomes CLOSE_WAIT after this. (4) New request reaches mod_proxy_http at 41.547sec and creating a different new TCP section at 41.546sec. This is also throwing FIN and then disconnecting it, but it's NOT disconnecting in the backend server side. However, it's disconnecting from backend server side at 71,545, but mod_proxy_http doesn't return FIN. After this, Port 47486 of mod_proxy_http becomes CLOSE_WAI.T (5) Client throws a new request to mod_proxy_http at 77.157sec. At this time, at 77.159sec, mod_proxy_http thows FIN and ACK from the above # (3), port 47485, then the first time that (3) session ends here. It took 47 seconds until here, and if we compare it with KeepAliveTimeout that is set at the backend server, there is a big gap. We have done it a few times and found out the following: a) mod_proxy_http uses KeepAlive between backend, although client doesn't use KeepAlive. b) Even if Backend send FIN by KeepAliveTimeout, mod_proxy_http doesn't response and become CLOSE_WAIT. c) mod_proxy_http becomes CLOSE_WAIT when a new request recives. d) However, if a new request doesn't come then it never sends FIN to an old connection and stays as CLOSE_WAIT forever. We assume that b) and d) are not good behaviors for TCP/IP connections. Already connection to client is disconnected; it doesn't depend on client's KeepAlive behavior. -- 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] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126472#comment-13126472
]
Maurizio Cucchiara commented on OGNL-20:
Hi Daniel,
{quote}
First suggestion is ditch the ClassCacheEntryFactory interface, it doesn't do
anything useful, and prevents people from supplying CacheEntryFactoryClass?,
... in its stead.
{quote}
Agreed
{quote}
Also, CacheEntryFactory instances are intended to be flyweights, where you've
actually been instantiating them every time you need them. For example, I
suggest refactoring getConstructors...
{quote}
Unfortunately, not everything turns out as it should, I would have like to use
flyweights, but it is not always a suitable pattern: not every cache has a so
simple miss condition.
Take for example {{getDeclaredMethods}} which, given a property name, returns
the list of the declared methods along the hierarchy.
Now, in this specific case, the miss condition is absolutely
property-dependent, it is not enough that a cache contains information about a
given class.
Even if I don't like much, I am afraid that the only solution is to use
not-anonymous classes. This strongly increases the classes's proliferation, but
it's the only solution I am able to see.
It is not easy to explain for me, I hope I did it well.
Performance - Replace synchronized blocks with ReentrantReadWriteLock
-
Key: OGNL-20
URL: https://issues.apache.org/jira/browse/OGNL-20
Project: OGNL
Issue Type: Improvement
Environment: ALL
Reporter: Greg Lively
Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
these synchronized blocks are controlling access to HashMaps, etc. I believe
this could be done far better using ReentrantReadWriteLocks.
ReentrantReadWriteLock allows unlimited concurrent access, and single threads
only for writes. Perfect in an environment where the ratio of reads is far
higher than writes; which is typically the scenario for caching. Plus the
access control can be tuned for reads and writes; not just a big
synchronized{} wrapping a bunch of code.
--
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-689) Breaking up MathUtils
[
https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126494#comment-13126494
]
Sébastien Brisard commented on MATH-689:
{quote}
Can we change ArithmeticsUtils to ArithmeticUtils.
{quote}
Sure. Done in rev 1182787. I forgot to set an entry log for this rev, and do
not know if it's possible to do it now.
Breaking up MathUtils
---
Key: MATH-689
URL: https://issues.apache.org/jira/browse/MATH-689
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Priority: Trivial
Labels: api-change
Fix For: 3.0
Issue related to this
[proposal|http://www.mail-archive.com/dev@commons.apache.org/msg25617.html].
There seemed to be a global agreement on the following break-up:
* Arithmetics (for addAndCheck, factorial, gcd, ...)
* Precision (for equals, compare, ...)
* Binomial (for binomialCoefficient)
* MathArrays (for linearCombination, distance, safeNorm,
sortInPlace, copyOf, ...)
I think that ordinary mathematical functions (pow, cosh, ...) should go
into FastMath (if not already available there).
Those who are willing to work on this issue, please coordinate here.
--
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] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126518#comment-13126518
]
Simone Tripodi commented on OGNL-20:
Hi Mau,
How can I check which are the differences between the branch and the current
trunk?
TIA?
Performance - Replace synchronized blocks with ReentrantReadWriteLock
-
Key: OGNL-20
URL: https://issues.apache.org/jira/browse/OGNL-20
Project: OGNL
Issue Type: Improvement
Environment: ALL
Reporter: Greg Lively
Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
these synchronized blocks are controlling access to HashMaps, etc. I believe
this could be done far better using ReentrantReadWriteLocks.
ReentrantReadWriteLock allows unlimited concurrent access, and single threads
only for writes. Perfect in an environment where the ratio of reads is far
higher than writes; which is typically the scenario for caching. Plus the
access control can be tuned for reads and writes; not just a big
synchronized{} wrapping a bunch of code.
--
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] (SANDBOX-341) [functor] New components: summarize and aggregate
[ https://issues.apache.org/jira/browse/SANDBOX-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126523#comment-13126523 ] Simone Tripodi commented on SANDBOX-341: Hi Liviu, how things are going? Do you need any help from my side to finalize it? TIA, Simo [functor] New components: summarize and aggregate - Key: SANDBOX-341 URL: https://issues.apache.org/jira/browse/SANDBOX-341 Project: Commons Sandbox Issue Type: Improvement Components: Functor Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly 1.4 though I haven't tested). Reporter: Liviu Tudor Priority: Minor Labels: features Attachments: commons-functor-aggregate+summarizer.zip, commons-functor.patch.bz2 This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 -- as instructed I'm finally hoping to get the code in the right place and hopefully this is something that the functor component could do with. Whereas initially I just started with the summarizer component, I have added now the second one, the aggregator as they are somehow related. If this code proves to be useful to functor in any way, it would actually be good to get some feedback on these 2 to see if the class hierarchy can in fact be changed to share some common functionality as I feel (probably due to the similar needs that lead to writing/using these components) that somehow they should share a common base. In brief, the 2 components: * aggregator: this just allows for data to be aggregated in a user defined way (e.g. stored in a list for the purpose of averaging, computing the arithmetic median etc). The classes provided actually offer the implementation for storing data in a list and computing the above-mentioned values or summing up everything. * timed summarizer: this is another variation of the aggreator, however, it adds the idea of regular flushes, so based on a timer it will reset the value and start summing/aggregating the data again. Rather than using an aggregator which would store the whole data series (possibly for applying more complex formulas), this component just computes on the fly on each request the formula and stores the result of it. (Which does mean things like computing arithmetic mean, median etc would be difficult to compute without knowing upfront how many calls will be received -- i.e. how many elements we will be required to summarize/aggregate.) So the memory footprint of running this is much smaller -- even though, as I said, it achieves similar results. I have only provided a summarizer which operates on integers, but obviously others for float, double etc can be created if we go ahead with this design. Hopefully the above make sense; this code has resulted from finding myself writing similar components to these a few times and because it's always been either one type (e.g. aggregator) or another (summarizer) I haven't given quite possibly enough thought to the class design to join these 2. Also, unfortunately, the time I sat down to make these components a bit more general and submitted issue 340 was nearly 3 months ago so I'm trying to remember myself all the ideas I had at a time so bear with me please if these are still a bit fuzzy :) However, if you can make use of these I'm quite happy to elaborate on areas that are unclear and obviously put some effort into getting these components to the standards required to put these into a release. -- 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] (COMPRESS-158) Empty directories missing in zip archive
[ https://issues.apache.org/jira/browse/COMPRESS-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126638#comment-13126638 ] Daniel Spicar commented on COMPRESS-158: Hi Stefan, the Problem persists in my environment. I will try to investigate further. I use Sun's JDK, but I will try OpenJDK as well. Empty directories missing in zip archive Key: COMPRESS-158 URL: https://issues.apache.org/jira/browse/COMPRESS-158 Project: Commons Compress Issue Type: Bug Affects Versions: 1.2 Environment: Java 1.6, Ubuntu Linux (ext4 fs) Reporter: Daniel Spicar Priority: Minor Attachments: CompressionUtil.java, output.zip, test.zip When zipping a directory that contains several files and subdirectories of which some can be empty, I am missing empty directories. When using a tar archive format empty directories are present. I have found https://issues.apache.org/jira/browse/COMPRESS-105 which describes a similar issue, however I am unable to reproduce the solution suggested there. -- 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-690) Remove methods from MathUtils
Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126729#comment-13126729 ] Gilles commented on MATH-690: - For byte, short, int, long, do we keep sign or indicator? Another alternative would be to replace them with signum or copySign in order to have a consistent naming with their counterpart in FastMath. Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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] (VFS-368) SFTP documentation implies that userDirIsRoot defaults to true (but it defaults to false)
SFTP documentation implies that userDirIsRoot defaults to true (but it defaults to false) --- Key: VFS-368 URL: https://issues.apache.org/jira/browse/VFS-368 Project: Commons VFS Issue Type: Bug Reporter: Brendan Long Priority: Minor On this documentation page: http://commons.apache.org/vfs/filesystems.html#SFTP It says: SFTP Provides access to the files on an SFTP server (that is, an SSH or SCP server). URI Format sftp://[ username[: password]@] hostname[: port][ absolute-path] Examples sftp://myusername:mypassword@somehost/pub/downloads/somefile.tgz The default is actually that the path is relative from the user's home directory. This can be changed by running: SftpFileSystemConfigBuilder .getInstance() .setUserDirIsRoot(options, false); I suggest changing the documentation to say [ relative-path ] and adding a note about absolute paths (but I'm not sure how to make it fit the style of this page). -- 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-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126747#comment-13126747 ] Luc Maisonobe commented on MATH-690: Yes, consistency is better. Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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] (SANSELAN-58) Streamlined TIFF strip reader reduces load time by a factor of 5
Streamlined TIFF strip reader reduces load time by a factor of 5
Key: SANSELAN-58
URL: https://issues.apache.org/jira/browse/SANSELAN-58
Project: Commons Sanselan
Issue Type: Improvement
Reporter: Gary Lucas
Testing reveals that streamlining the DataReaderStrip.java operations for 8 and
24 bit-per-pixel TIFF images reduces the TIFF file load time by a factor of 5.
For each pixel in images of these types, the interpretStrip() method of
DataReaderStrip makes calls to a generic bit extractor using its
getSamplesAsBytes() method. Internally, this method simply copies the
requisite number of bytes (8 or 24), but it executes a lot of conditional
statements to do so. Under most architectures, conditionals tend to take 2 to
3 times as long to execute as simple arithmetic statements, so this approach is
expensive (especially since an image may contain millions of pixels). While
the implementation is very generic, the majority of TIFF files out there appear
to fall into two simple categories. By implementing specialized code for these
two cases, the loading time for TIFF images is dramatically reduced.
The following snippet shows the code I used for testing. It was added right at
the beginning of the interpretStrip() method.
// Oct 2011 changes.
// The general case decoder is based on the idea of using a
// generic bit-reader to unpack the number of bytes that are
// needed. Although it is efficiently implemented, it does
// require performing at least three conditional branches per sample
// extracted (and often more). This change attempts to bypass that
// overhead by implementing specialized blocks of extraction code
// for commonly used 8 bitsPerPixel and 24 bitsPerPixel cases.
// In other cases, it will simply fall through to the original code.
//note that when promoting a byte to an integer, it is necessary
//to mask it with 0xff because the Java byte type is signed
//an this implementation requires an unsigned value
if(x=width)
{
// this may not be required. it was coded based on the
// original implementation. But looking at the TIFF 6.0 spec,
// it looks like the rows always evenly fill out the strip,
// so there should never be a partial row in a strip and x
// should not be anything except zero.
x = 0;
y++;
}
if(y=height)
{
// we check it once before starting, so that we don't have
// to check it redundantly for each pixel
return;
}
if(predictor==-1 this.bitsPerPixel==8)
{
int [] samples = new int[1];
for(int i=0; ipixels_per_strip; i++)
{
samples[0] = bytes[i]0x00ff;
photometricInterpreter.interpretPixel(bi, samples, x, y);
x++;
if(x=width)
{
x = 0;
y++;
if(y=height)
return; // any remaining bytes are not needed
}
}
return;
}
else if(predictor==-1 this.bitsPerPixel==24)
{
int [] samples = new int[3];
int k = 0;
for(int i=0; ipixels_per_strip; i++)
{
samples[0] = bytes[k++]0x00ff;
samples[1] = bytes[k++]0x00ff;
samples[2] = bytes[k++]0x00ff;
photometricInterpreter.interpretPixel(bi, samples, x, y);
x++;
if(x=width)
{
x = 0;
y++;
if(y=height)
return; // any remaining bytes are not needed
}
}
return;
}
// original code before Oct 2011 modification
ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
BitInputStream bis = new BitInputStream(bais);
etc.
--
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] (SANSELAN-58) Streamlined TIFF strip reader reduces load time by a factor of 5
[
https://issues.apache.org/jira/browse/SANSELAN-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126949#comment-13126949
]
Matt Benson commented on SANSELAN-58:
-
Hi,Gary. What you typically want to do when submitting code to an ASF project
is:
* obtain the latest code from subversion
* apply your changes to the checked-out code
* ensure your changes don't affect any existing tests, or be prepared to
explain why their doing so is correct
* use `svn diff` to create a patchfile and attach it to this JIRA issue,
checking the box declaring that you own the IP contained in the patch and grant
license to the ASF for its use
Thanks for your interest!
Matt (a Commons developer, not of [sanselan] per se)
Streamlined TIFF strip reader reduces load time by a factor of 5
Key: SANSELAN-58
URL: https://issues.apache.org/jira/browse/SANSELAN-58
Project: Commons Sanselan
Issue Type: Improvement
Reporter: Gary Lucas
Original Estimate: 1h
Remaining Estimate: 1h
Testing reveals that streamlining the DataReaderStrip.java operations for 8
and 24 bit-per-pixel TIFF images reduces the TIFF file load time by a factor
of 5.
For each pixel in images of these types, the interpretStrip() method of
DataReaderStrip makes calls to a generic bit extractor using its
getSamplesAsBytes() method. Internally, this method simply copies the
requisite number of bytes (8 or 24), but it executes a lot of conditional
statements to do so. Under most architectures, conditionals tend to take 2
to 3 times as long to execute as simple arithmetic statements, so this
approach is expensive (especially since an image may contain millions of
pixels). While the implementation is very generic, the majority of TIFF
files out there appear to fall into two simple categories. By implementing
specialized code for these two cases, the loading time for TIFF images is
dramatically reduced.
The following snippet shows the code I used for testing. It was added right
at the beginning of the interpretStrip() method.
// Oct 2011 changes.
// The general case decoder is based on the idea of using a
// generic bit-reader to unpack the number of bytes that are
// needed. Although it is efficiently implemented, it does
// require performing at least three conditional branches per sample
// extracted (and often more). This change attempts to bypass that
// overhead by implementing specialized blocks of extraction code
// for commonly used 8 bitsPerPixel and 24 bitsPerPixel cases.
// In other cases, it will simply fall through to the original code.
//note that when promoting a byte to an integer, it is necessary
//to mask it with 0xff because the Java byte type is signed
//an this implementation requires an unsigned value
if(x=width)
{
// this may not be required. it was coded based on the
// original implementation. But looking at the TIFF 6.0 spec,
// it looks like the rows always evenly fill out the strip,
// so there should never be a partial row in a strip and x
// should not be anything except zero.
x = 0;
y++;
}
if(y=height)
{
// we check it once before starting, so that we don't have
// to check it redundantly for each pixel
return;
}
if(predictor==-1 this.bitsPerPixel==8)
{
int [] samples = new int[1];
for(int i=0; ipixels_per_strip; i++)
{
samples[0] = bytes[i]0x00ff;
photometricInterpreter.interpretPixel(bi, samples, x, y);
x++;
if(x=width)
{
x = 0;
y++;
if(y=height)
return; // any remaining bytes are not needed
}
}
return;
}
else if(predictor==-1 this.bitsPerPixel==24)
{
int [] samples = new int[3];
int k = 0;
for(int i=0; ipixels_per_strip; i++)
{
samples[0] = bytes[k++]0x00ff;
samples[1] = bytes[k++]0x00ff;
samples[2] = bytes[k++]0x00ff;
photometricInterpreter.interpretPixel(bi, samples, x, y);
x++;
if(x=width)
{
x = 0;
y++;
if(y=height)
return; // any remaining bytes are not needed
[jira] [Commented] (MATH-675) MathUtils should have a static method which checks whether an array of doubles or Comparables is monotone
[ https://issues.apache.org/jira/browse/MATH-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126983#comment-13126983 ] Gilles commented on MATH-675: - All remarks implemented as part of MATH-689 (revisions 1182134, 1182137, 1182147) and in revision 1183119. MathUtils should have a static method which checks whether an array of doubles or Comparables is monotone -- Key: MATH-675 URL: https://issues.apache.org/jira/browse/MATH-675 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Environment: Java Reporter: greg sterijevski Assignee: greg sterijevski Priority: Minor Labels: MathUtils Fix For: 3.0 Original Estimate: 24h Remaining Estimate: 24h The static method checkOrder in MathUtils is a useful piece of code which checks for monotonically increasing or decreasing elements in an array. It would be useful to have a similar method for Comparable. Furthermore, this new method would just return true or false. Unlike the current checkOrder, no exception would be thrown if monotonicity did not exist. -- 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-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13126995#comment-13126995 ] Gilles commented on MATH-690: - sinh and cosh removed in revision 1183128. Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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-690) Remove methods from MathUtils
[ https://issues.apache.org/jira/browse/MATH-690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13127035#comment-13127035 ] Gilles commented on MATH-690: - sign removed in revision 1183138. Remove methods from MathUtils --- Key: MATH-690 URL: https://issues.apache.org/jira/browse/MATH-690 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Labels: api-change Fix For: 3.0 I propose to remove the following methods from MathUtils: public static double sign(final double x) public static float sign(final float x) public static double sinh(double x) public static double cosh(double x) Also, sign and indicator functions seem redundant (and the float and double versions are not dealing correctly with -0.0). -- 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
