I have been using EmpiricalDistributionImpl from Apache Commons-Math library for quite a while now, upgrading from 2.x to 3.3 I am experiencing some problems.
First off NaNs seem to be causing problems during load() in this version, I am pretty sure they were not problematic before. Then the real problem is that I am getting negative values from my EDI class by getNextValue() even though all of the values I have loaded are strictly positive. Specifically my values are positive ratios in (0, +Inf) range, and if I plot them it's pretty top heavy (i.e like 90-95% values end up in the top 3 bins).
FWIW, I have found the following two bug reports but not sure they are entirely related.
https://issues.apache.org/jira/browse/MATH-1132
https://issues.apache.org/jira/browse/MATH-984
They both appear to be fixed and scheduled for 3.4 release, except there is no ETA on the release date.
Suggestions?
MATH-1132 is unrelated; but MATH-984 likely is related to the data range problem you mention. NaNs should be filtered before data are passed to load, as there is no meaningful way to handle them (without adding support for a NanStrategy, which is not currently supported).
Version 3.4 was just released.
Please open a new ticket if you still have range problems and feel free to open a ticket to get NaNs supported via a NaNStrategy.
Related
I'm trying to sort a collection of AnyLogic GISRegions by their geographical area. Said area is calculated using GISRegion.area(units), which is straightforward enough. The areas I'm using, however, are city-scale and the method returns a double. This appears to cause overflow problems:
I don't think I'm doing anything wrong with my code, so presumably this is an AnyLogic problem. For brevity, I've included a line that prints each region's area rather than the sorting steps:
// For each region of the Australian Capital Territory, print its area in km^2:
areas.forEach(next -> traceln(""+next.name+": " + next.gisRegion.area(SQ_KILOMETER)));
Has anyone encountered this issue? How did you get around it?
For non-AnyLogic users, I have all the lat-long points in each geoshape. How might I calculate the area using those points?
[Not really a full answer, but the ideas are too long for a comment.]
I assume you've raised an AnyLogic support request since it seems 100% a bug. Since this is just a basic 'calculate area' function, I can't see any way round it other than, as you suggest, calculating it in an alternative manner from the vertex lat/longs that you have, and can get via getPoints() on the GISRegion.
Since this is just an N-sided polygon, surely there must be standard Java libraries that could calculate that, though that's not allowing for the GIS projection (not sure what level of error that might introduce); you'd expect open GIS libraries to cope with the latter. Since a GISRegion has a createOMGraphicObject() method to create an OpenMap standard(?) format graphic, that could be useful if that's a standard format other libraries can work with.
There's code on glennon's answer to this GIS StackOverflow question that claims to perform the calculation (or you make be able to hook in to PostGIS as in fmark's answer).
I wrote a class that, given a seed and difficulty, will return a playing field to my game. The generation is consistent (no matter what, the same seed & difficulty level will always result in the same play field). As far as I know all android devices use Java 1.6 so here goes my question(s):
Is it safe to send only the seed and difficulty to other devices in a multiplayer environment?
Do I need to worry about when Google updates Java version level form 1.6? or will they likely update all android devices to that version level (I am assuming the Random class will have been changed)? And if not what would be a good way to detect if Random class is different?
Rephrased, what precautionary measures should be in place to ensure that the class java.util.Random, which my field generation class uses heavily, will result in the same play field for every device? Or, alternatively, would it be more wise to consider sending all play field data to the non-hosting device(s)?
I could probably accomplish the latter with a reliable message with size of:
byte[ROWS * COLUMNS]
In advance, I appreciate any guidance/suggestions in this matter. This is a difficult issue to search for so some links for future views may be appropriate.
There are a few options here, but I guess I was hoping for some magic JVM property defining the java.util.Random class revision version.
First option is to check the java version and compare it against the other device's version. If they are the same it is safe (as far as I know) to assume that the Random class is the same and thus the seed and difficulty can be sent. If, however, they are different you either send all the data or check the documentation/version release notes yourself to see when the Random class was changed and then determine if all the data should be sent based on previously acquired java version identifier.
The second option is to simply always send all the data. Which is what I will personally be doing.
If you're not as lucky as I and your data exceeds the value of Multiplayer.MAX_RELIABLE_MESSAGE_LEN (in bytes) you may have to break the data into multiple messages which could get ugly but is entirely doable.
I would like to determine the distance of an object from my Nexus 5 camera, preferably without using an object like a coin for scale. I figured the Camera.Parameters getFocusDistances function would work for this.
I attempted to do this via something like the following in my takePicture() jpeg callback:
Parameters params = camera.getParameters();
Float focusDistances[] = new float [3];
params.getFocusDistances( focusDistances );
I tried running this a few times with objects of different distances from the camera, though each time, focusDistances[FOCUS_DISTANCE_NEAR_INDEX], focusDistances[FOCUS_DISTANCE_OPTIMAL_INDEX], and focusDistances[FOCUS_DISTANCE_FAR_INDEX] all contained the value positive infinity.
It's possible I'm doing something wrong, in which case please let me know if there is a specific way I'm which this will work on the Nexus 5. However the android API specifically states you can call getParameters() (and then getFocusDistances()) at any time to get the latest focus distances and therefore I think this should work. One thing I haven't tried yet is doing the above in an on auto focus handler, however I don't see why this should matter.
I did some research to try and see what was going on, and I found several questions regarding this sort of behavior from getFocusDistances() and typically the answer, if there was one, was that the function is not supported by the android API and/or the hardware manufacturer. Now a lot of these discussions I found online were from several years ago, and dispite the questionable feelings it gives me about getFocusDistances, I've still seen this function suggested to be used for getting the focus distance so I figure it must work on SOME device for SOME android API version.
Does anybody know if getFocusDistances() works for any particular version of android on the Nexus 5? If not, does anybody know ANY device it does work on?
EDIT:
Since posting, I have tried obtaining the focus distances in the onAutoFocus handler, as well as trying a bit more extensively for objects atvarious distances. The results have been consistent - positive infinity is always returned for all 3 focus distances (NEAR, OPTIMAL, and FAR). I even tried this with a Nexus 7 and getFocusDistances always returns the constant values (0.95, 1.9, and infinity), so apparently getFocusDistances isn't implemented on that device either.
Therefore, I really have two questions:
Is there any way to get somewhat accurate focus distances using the android Camera API with the Nexus 5? I'm even wondering if there is custom android version where getFocusDistances is actually implemented, since otherwise I may attempt to do so myself depending on what I find when examining the API code.
Are there any android capable devices that are known to implement getFocusDistances in a somewhat accurate manner?
First of all, It's very difficult to measure the object distance from one single shot/view. You would find many research papers which tried to employ vision based techniques to judge the object distance. I can refer you one such paper. They tried to implement a positioning system that would solely work on mobile camera+sensors. You would probably realize how non-trivial it is to measure the object distance from one single camera view. They finally used a method called "structure from motion" vision technique to calculate the distance (From multiple photos taken from multiple angle).
Even traditional apps like SmartDistance and SmartMeasure needs to use geometric tricks to measure the distance. None of them could only rely on camera parameters. Sorry for the elongated introduction. I have done a project of this sort before and I am telling you all these based on my experience.
To answer your query, I haven't found any Android device yet which returns realistic values of focus distances. They are either returned as some constant values or sometimes 0 and infinity. I found someone reporting that it worked for Galaxy Nexus but only within 30cm object distance, it doesn't work for distances more than that. The bottom line is that you cannot rely on this function from camera API which is heavily dependent on the device drivers. And, phone camera's are not well-known for their lens/sensor qualities. It would be very very difficult for you to work on any optics based formula for mobile-phone cameras. I would suggest you to rather go for some sensor based geometric tricks.
I'm trying to import .spl files from Slidebook v4.2 into Matlab but I've run into problems.
I downloaded the functions and loci_tools.jar from here. I used them to import one file with minor problems (it got the Z planes and the time points backwards as well as misnaming some of the files with the wrong acquisition channel) but I figured out the pattern to the problems and was able to work around them.
Then I tried to import another file and I got this error which I haven't been able to solve. Any ideas would be greatly appreciated. I'm new to working with java and java in matlab. Here is the error I get:
I = bfopen(‘filename.spl’);
Finding offsets to pixel data
Determining dimensions
Reading series #1
.Error using loci.formats.ChannelSeparator/openBytes
Java exception occurred:
java.lang.IllegalArgumentException: Negative position
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:600)
at loci.common.NIOByteBufferProvider.allocateDirect(NIOByteBufferProvider.java:133)
at loci.common.NIOByteBufferProvider.allocate(NIOByteBufferProvider.java:118)
at loci.common.NIOFileHandle.buffer(NIOFileHandle.java:532)
at loci.common.NIOFileHandle.seek(NIOFileHandle.java:254)
at loci.common.RandomAccessInputStream.seek(RandomAccessInputStream.java:140)
at loci.formats.in.SlidebookReader.openBytes(SlidebookReader.java:130)
at loci.formats.ImageReader.openBytes(ImageReader.java:414)
at loci.formats.ChannelFiller.openBytes(ChannelFiller.java:197)
at loci.formats.ChannelSeparator.openBytes(ChannelSeparator.java:226)
at loci.formats.ChannelSeparator.openBytes(ChannelSeparator.java:159)
Error in bfGetPlane (line 75)
plane = r.openBytes(iPlane - 1, ip.Results.x - 1, ip.Results.y - 1, ...
Error in bfopen (line 144)
arr = bfGetPlane(r, i, varargin{:});
Please try the latest version of Bio-Formats 5. You can easily use it in Fiji by enabling the Bio-Formats 5 update site, or in MATLAB using the latest loci_tools.jar from Jenkins.
If you still get an error, feel free to report a bug. That said, the recommended approach is to export your data from the Slidebook software to OME-TIFF format.
Unfortunately, though popular, 3i Slidebook is probably the most arcane and difficult format we try to support in Bio-Formats. We have met with the Slidebook developers on multiple occasions to discuss how best to handle the issue. But the SLD format was never intended for public consumption and it continues to evolve with each iteration of the Slidebook software. So the compromise we settled on is for the Slidebook software to support robust export to OME-TIFF format, which preserves rich microscopy-related metadata. From the Bio-Formats 3i Slidebook page:
We strongly encourage users to export their .sld files to OME-TIFF using the SlideBook software. Bio-Formats is not likely to support the full range of metadata that is included in .sld files, and so exporting to OME-TIFF from SlideBook is the best way to ensure that all metadata is preserved.
I know that is not entirely satisfactory, but it is unlikely to change any time soon. Maybe if many customers expressed a strong preference to the Slidebook team to make the SLD format work better in Bio-Formats, they would take some steps to rework the format...
See also: Bio-Formats FAQ: Why do my Slidebook files take a long time to open?
I'm using the Solr 3.6.1 Webapp with the SOLR-2155 Patch for geohash field support.
I set everything up like described here: https://github.com/dsmiley/SOLR-2155
Now and then the search returns a totally false distance for every hit. Refreshing the result won't help. If I change the offset of the search (e.g. listing the 2nd page) it's all fine again. Even going back to the first page now shows up the right distance.
It's not the webapp because the json stream I get directly from Solr contains the same distances as result score. In my case it's always 20015,12km.
Here is my Query:
fq={!geofilt}
&fl=internalid,score
&start=0
&rows=10
&sort=geodist()+asc
&sfield=location
&pt=53.6,10.11
&d=50
&q={!func}geodist()
I wrote SOLR-2155. I'm not particularly happy with the distance sorting code therein; there seems to be something I overlooked. It shouldn't be some sort of math issue, it's some sort of Lucene internals issue, I think. If you have just one point per document, then use solr.LatLonType. If you have multiple then.... :-( I don't know what the problem is. In Solr 4, the replacement code for this called SpatialRecursivePrefixTreeFieldType and it uses different code but it is similar, so I'm not sure if the problem will go away or not. But even in that case, again, I'm not at all happy with the implementation. I know how I want to do it right, but it's not on the top of my TODO list right now.
BTW, you are basically reporting a bug, and the proper place to report a bug would be the issue tracker of the project in question -- in this case, that's GitHub SOLR-2155. StackOverflow doesn't make sense for that.