I found a strange bug. I have a class derived from ValueBox<Double> to display numbers. I add some styling to it to make it prettier using setStyleName();
It has worked well for some time now, but just now I noticed a strange bug. If I set a value greater than 999 the display is blanked.
I figured out that if I remove my call this.getElement().setAttribute("type", "number"); everything works as it should.
I suspect the problem is that values over 999 is displayed as 1.000 and that is not acceptable as a number.
It work in Firefox, but fails in Chrome/Chromium. No wonder since Firefox ignores the type attribute anyway.
So there are two ways to solve it.
get it accepted as a number
change the formatting to leave out or change the separator
But how?
Related
its my first question here and maybe i'm just blind or extremely stupid, but i haven't found a matching answer to my problem in the past three days. Currently i'm coding an Idlegame (just to learn more about OOP and such stuff) and obviously there will be some numbers that are too big for int or long (sth like "1500000000000" (1.5E12)). So i decided to go along with floats for two reasons:
Every other type that can store way more than int or long (like BigInteger or BigDecimal) wouldn't solve my problem of shortening my shown numbers in the ui.
I like the numberformatting of float with the exponent shown at the end.
Because of some issues with the length of the outcoming number (1.50000003E12 (i think the ...03 at the end of the number comes from the Float.toString() which i use to set it onto a javafx label)) i thought about formatting them in an uniform way (in my opinion it should look like 1.23E45) so i googled a lot, read a lot, tried a lot, but still got no working solution. on SO i read multiple ways to format floats with "String.format()" and "DecimalFormat", but the outcome wasn't as expected. the float value is written completely what in fact is the opposite of that, what i wanna achieve.
So my wish would be a working solution, or a hint that would help me further to achieve my goal to only show the first three digits of a float and add the exponent.
If anything is missing that would help to find the best solution for my problem feel free to ask for it.
I have been coding for a while now and as far as I'm aware, once you've outputted a line to System.out.println in Java; you cannot change it.
The reason I ask this question is because of some very strange results from my program. The program records the time of the bubble sort and merge sort algorithms in sorting different kinds of int arrays and prints the average of these times at different sizes of n, where n is the size of the array.
Now I've had a litany of problems with this program thus far, but I do not understand how the following is possible:
...
At 200000, randomly-sorted takes:
NaN //Expected output, since I did not activate the random arrays.
...
However, at the same line, and in an unpredictable manner, the program occasionally does this:
...
At 200000, randomly-sorted takes:
75683.45
...
And then swaps back again after a while!
So the program is somehow managing to replace the outputted line, which I have never experienced before.
Any help or clarification very much appreciated! If you need the code, I am more than happy to share.
EDIT: To clarify, this is on a Macbook Air running Java SE 6. As for the code, please refer to my Github account with the entire project at the following link - https://github.com/danielsoutar/complexityPractical.
Side-note: One other thing. For bubble sort, the randomly-generated arrays apparently take longer to sort than a reverse-sorted array, which is clearly nonsense. Not sure if that matters to this problem but it is something to note.
the question was kinda unclear to me, but as far as I understand you could take a look at RegEx for filtering out on a String or clear the Console and put your output back in.
Clear console:
Runtime.getRuntime().exec("cls");
RegEx example:
yourString.replaceAll("[yourCharactersToReplace]","");
System.out refers to a PrintStream instance. In the abstract, a PrintStream object represents a place where you can send text. Period. Once the text is sent, that's the end of the story.
But in reality the text actually goes somewhere. If you are invoking your Java program from a command line, then it's very likely that the place where the text goes is a terminal emulator window or a console window; and it's also very likely that the console recognizes certain codes that your program can embed in the text that tell it to do things.
Things like, change the color of the text, move the cursor around in the window, and over-write text that already was there.
There have been literally hundreds of different coding systems to let a computer program do those things on a terminal screen/window, but one is supported by almost all consoles and terminal emulators. Google for "ANSI escape codes" to learn more about it.
If you want your program to purposefully move the cursor around, change the text color, etc. Then you might want to use a 3rd party library like jcurses (google for that too) to handle the possibility of a console that does not accept (or is not configured to accept) ANSI escape codes.
I've started using Selenide recently, and I'm loving the fluent code it allows.
I do have strange issue with ElementsCollection, however.
$$("some ref").filterBy(not(attribute("an-attr-that-should-not-be"))).getTexts()
This query intermittently returns stringified StaleElementReferenceExceptions, and I can't understand why.
If I run the query in the debugger, it returns valid values, while during normal runtime (single thread application), this is what I get.
The target element is a GWT combo box results list.
Could someone please point me in the right direction?
Update: if it's relevant, I'm using InternetExplorerDriver.
Chrome and ChromeDriver specifically fire off StaleElementReferenceException like its the point of your test - any time an element is no longer visible the WebElement reference you have to it becomes invalid and you must look it up again. If the combo is showing/hiding or changing those could cause this (need more details on which combo and what seems to cause it for more specific) - try looking up the element when you expect to use it instead of reusing the reference again and again.
Found the problem. Apparently, the Selenide ElementsCollection cached a previous version of the element list, which updated a lot slower than anticipated, and was trying to access this ghost data when retrieving texts.
Fixed by using $$ where the list is iterated, instead of the usual static constants in class header.
My solution for this problem was very simple and straight. I just set the timeout for the search of an element around 10 seconds and it worked. It can be done only with one string:
Configuration.timeout=10000
The value is in milliseconds, of course.
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.
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.