Hi
I love my desire. The HTC calculator is nice with the finger friendly buttons with haptic feedback, and I love the fact it's respecting the operator priorities. But what's wrong with the calculator?
100 - 99,9 = 0,09999999999999999
100 - 99,8 = 0,2
100 - 99,7 = 0,2999999999
100 -99,6 = 0,4
100 - 99,5 = 0,5
100 - 99,4 = 0,599999999
100 - 99,3 = 0,7
100 - 99,2= 0,7999999999
100 - 99,1 = 0,9
is this a known issue?
Do you know another calculator where you can review all the line you typed and correct it if needed, that has big buttons, has parenthesis, and that give accurate results? I used to use HiCalc on WinMo, but I can't seem to find a good substitute on android.
Turn the phone to landscape and more functions are available like parentheses. Not sure about your other points!
funny - i needed this calculator for my school time
100 - 99,2= 0,7999999999
i have same result
br stupsi
stupsi99 said:
100 - 99,2= 0,7999999999
Click to expand...
Click to collapse
Google floating point precision
nparley said:
Google floating point precision
Click to expand...
Click to collapse
Most likely this.
And I use RealCalc which seems to correct for it.
This is mad.
My calculated is screwed too. Lol
Sent from my HTC Desire using XDA App
Why are you putting commas in not decimal points? 99.7 not 99,7
^^^^ Other people in the world write things differently to us
ok...this is new...lol
do you guys think a solution is possible? or should we all get another calculator?lol
You need to get another calculator.
Seems that HTC's calculator is using floating point rather than fixed point or decimal floating point.
Regards,
Dave
it is also a problem on the Vanilla calculator.
I'm using OpenDesire and it also has this problem.
bedeabc said:
^^^^ Other people in the world write things differently to us
Click to expand...
Click to collapse
they might, but if the calculator is configured to work with points not commas I'm not surprised it fails
Edit
Wrong! Is the same with points as commas. My bad
When we use the calculator we press the . button, as there is no comma.
FYI when in the UK you write 1,002.50 the rest of the world writes 1 000,50.
HTC answered me to find another calculator on the maket, cause the HTC calculator is a basic one. LMAO I know it won't solve complex equations, but 100 - 99.9 should be solved by any basic calculator, even by a 7 year old pupil...so I guess it should be solved by a calculator that displays basic trigonometry buttons, shouldn't it?
It fails with points as well.
100-99.9=0.0999999999
So it's not a localisation thing, it's just a rubbish calculator.
This happens to any substraction having the following pattern:
n-((n-1)+p), where p = {0.9, 0.7, 0.4, 0.2}
And it doesn't matter whether the Calculator uses '.' or ',' for digits.
Very strange...
Benj555 said:
FYI when in the UK you write 1,002.50 the rest of the world writes 1 000,50.
Click to expand...
Click to collapse
That depends on your definition of the rest of the world.
The two most populous nations on the planet, namely China and India, use the point as the decimal separator, as does the US, Japan, and most of the ex-British empire.
For the most part, the "Decimal Comma" is in use in mainland Europe and most of South America.
Regards,
Dave
Benj555 said:
When we use the calculator we press the . button, as there is no comma.
FYI when in the UK you write 1,002.50 the rest of the world writes 1 000,50.
Click to expand...
Click to collapse
The 'rest of the world' write: 1.000,50 (they use the '.' to group thousands - e.g. 154.234.345,243)
nparley said:
Google floating point precision
Click to expand...
Click to collapse
Don't see why floating point should have anything to do with this. Floating point is relevant where there is a greater number of digits required to do the calculation than would normally be displayed. This is a simple subtraction of a number with one decimal place. This is just plain wrong!
norm2002 said:
Don't see why floating point should have anything to do with this. Floating point is relevant where there is a greater number of digits required to do the calculation than would normally be displayed. This is a simple subtraction of a number with one decimal place. This is just plain wrong!
Click to expand...
Click to collapse
nparley is correct.
Whomever wrote the HTC calc app used binary floating point data types. The subtraction is being performed "correctly" within the limitations imposed by the use of that data type. 0.1 cannot be exactly represented by that data type, which is why this issue shows up.
Regards,
Dave
No, in the UK we would use . to indicate decimal and , to indicate thousands. Which I think is standard?
Related
The application list next to the home screen, has anyone heard if any updates are coming? I always assumed it would have a skiplist functionality like the contacts. It's kind of raw the way it is now, and we're getting closer and closer to an RC.
Anyone know if you can search through the list using the Search button?
lordcanti86 said:
Anyone know if you can search through the list using the Search button?
Click to expand...
Click to collapse
Yep, you can. Uniform search ftw.
Windcape said:
Yep, you can. Uniform search ftw.
Click to expand...
Click to collapse
Incorrect. There is no unified search. Search is contextual.
RustyGrom said:
Incorrect. There is no unified search. Search is contextual.
Click to expand...
Click to collapse
You read the second part wrong
Uniform = Search button does the same everywhere.
I just had to add more words than just "yes" to the sentence. 10 character minimum per post!
Windcape said:
You read the second part wrong
Uniform = Search button does the same everywhere.
I just had to add more words than just "yes" to the sentence. 10 character minimum per post!
Click to expand...
Click to collapse
But you can't search the app list...
RustyGrom said:
But you can't search the app list...
Click to expand...
Click to collapse
It's my understanding it's meant to be possible.
The search-button in the emulator opens Bing for everything but custom loaded application with the search button mapped. So I would be a bit vary about judging to much from the emulator only.
(I also have some faint memory of seen it working in one of the unlocked emulators.)
In the current version of the emulator it's taking me to bing's website. However, I think this is a major gripe noted by many beta testers and developers so we should see something more updated at release.
I'm hoping that the search button becomes contextual here as well as adding in the jump lists. However, with the default number of applications a jump list might become a burden. After almost every other item you'll have a new letter block taking up screen space. It might be best to configure it to only activate the jump lists if you have X applications installed on the phone.
The search button currently allows you to search through your contacts list in the people hub, and allows you to search through locally downloaded emails in your inbox.
I really hope MS gives more options like allowing grids instead of just a list. A jump list in gridded form (like what shows on the Zune HD) would be great.
The calculator calculates wrongly
Try the following:
5+1*5+1
You would think that this equals 11 but not in WP7 land
You could argue that its not a failure and its supposed to work in that way, but then at least the way the calculation is displayed is incorrect.
And even more ridiculous is the whole thing when you turn your phone sideways - then it works like expected
So to sum it up (haha!):
Microsoft seems not to be able to program a simple calculator - a firm with 1000s and 1000s of engineers ;D
Most phone calculators would make it 31, not 11. In landscape, it goes into an engineering mode so begins to work properly.
vangrieg said:
In landscape, it goes into an engineering mode so begins to work properly.
Click to expand...
Click to collapse
Ah! I didn't know that. Nice
Never mind , I get 11
Sent from my GT-I9000 using Tapatalk
the caluclators with no "memorydisplay" would make it 31, but when there is a display at least I had thought that it would calculate like the line in the top of the screen... maybe its me.
vetvito said:
Never mind , I get 11
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
So do I whether in portrait (simple view) or landscape (scientific view)
The android calc shows me also 11
its not only a WP7 bug
Hassan99 said:
The android calc shows me also 11
its not only a WP7 bug
Click to expand...
Click to collapse
How's that a bug, it is supposed to be 11
It was the same in WM. On my HD2 it would act like a "dumb" calculator in portrait and yield 31, and get "smarter" in landscape. So it's hardly a bug.
Maybe its not a bug (thats why I made the " in the topicname), but it is:
1. false (at least in the line on the top)
2. inconsistent and not intuitive (why behaves the calculator different in each view)
001mic said:
Maybe its not a bug (thats why I made the " in the topicname), but it is:
1. false (at least in the line on the top)
2. inconsistent and not intuitive (why behaves the calculator different in each view)
Click to expand...
Click to collapse
It looks like a "feature" that was brought over from WinMo.
I was quoting a person that made it look like other platforms were affected by the same "feature".
001mic said:
Maybe its not a bug (thats why I made the " in the topicname), but it is:
1. false (at least in the line on the top)
2. inconsistent and not intuitive (why behaves the calculator different in each view)
Click to expand...
Click to collapse
Because in portrait mode it's a simple desk-calculator like thousands of people use everyday. They are working like this, one calculation after the other. It would confuse people to see it work "correctly", because they won't understand what's going on.
For people that are used to it, we simply use the engineering mode in landscape and it's working as expected by them.
Portrait mode doesn't even have Pi =)
FWIW, the HTC Calculator for WP7 correctly returns 11 in both portrait and landscape modes.
Tried it on a Trophy. Portrait = 31, landscape = 11.
Was about to ask why it is 11, but then worked it out. No wonder most people are afraid of mathematics.
heh. order of operations..
in portrait, the calculator does the calculations in the order they are entered.
in landscape, it follows the order of operations.
Calculator in windows will behave the same way if you enable scientific mode.
lqaddict said:
I was quoting a person that made it look like other platforms were affected by the same "feature".
Click to expand...
Click to collapse
I think I said "most phones". Every dumbphone I had did the same thing. I remember I had to store intermediate results in memory to get the calculations right.
001mic said:
Maybe its not a bug (thats why I made the " in the topicname), but it is:
1. false (at least in the line on the top)
2. inconsistent and not intuitive (why behaves the calculator different in each view)
Click to expand...
Click to collapse
I don't see any usefulness in this "feature" either. On the other hand, it does seem to be the standard Windows behavior, and since I haven't heard lots of complaints about it, maybe that's what "most" people expect. Who knows.
It does look silly and useless, I agree.
Seems like the expected results to me. If it was like a TI-83 where you could type it on one line and then hit Equals, I would be concerned. It's interesting to know when it's in scientific mode it functions like that.
But since it's just a simple one in portrait mode, it will do 5+1, multiple by 5, plus 1.
" 5 + 1 X 5 + 1"
Normal: 5+1 = 6 > 6 x 5 = 30 > 30 + 1 = 31
Scientific: 5 + (1 x 5 ) + 1 = 5 + 5 + 1 = 11
That's normal, multiplication in first, and after addition.
(Sorry for my English :s )
It doesn't matter how you try to justify it, its still wrong.
I bet every calculator with the result of 31 does not have a line where the calculation shows up - that's where the failure lies in the wp7 calculator.
It shows you, that you have calculated 3+3*4 so far, but in reality he calculated (3+3)*4.
So either they:
-don't show this misleading line
-show it differently (e.g. 3; +3; *4; ...)
-calculate "correct"
What I think imho is that they can not show it in the exact same way in portrait and landscape mode but calculate differently.
Okay I also just noticed that you can "take" the wrong calculation with you to the landscape mode (start making a calculation and then turn it sideways)
Then you have the wrong result to the calculation even in the scientific mode.
This is not excusable in my opinion. Is there any reason that it not should adjust the calculation, either in the result, or in the calculation line? I think not.
I think its a bug
hello,
I'm programming a WP7-App, i have a letter (for example the "A").
How can i recognize the input and match the correct character ?
sorry for my bad english
You can cast chars to ints.
see: http://www.asciitable.com/
In the table in that link, note that 'A' corresponds to a decimal number 65. When you cast your char 'A' to an int, it will turn into 65.
Similarly, (int)'a' is 97. And 'a' - ch, where ch = 'b', is equal to -1. Doing subtraction of chars automatically converts to integers. Casting the whole string to lowercase and then checking (currentChar - 'a' < 26) is a great way to check if you're looking at an alphabetic character (a through z).
Thanks for the answer...
the "A" is only an example caracter.
in the real world example i use japanese caracters.
the user shall be paint the correct caracter in my app, like this on the picture...
CB.NET said:
Thanks for the answer...
the "A" is only an example caracter.
in the real world example i use japanese caracters.
the user shall be paint the correct caracter in my app, like this on the picture...
Click to expand...
Click to collapse
That will be an insanely difficult task. Actually this in general takes years of study in order to accomplish
Handwriting recognition is one of the hardest things to accomplish.
If you do want to give it a shot, my suggestion:
Crop and rescale the images, and than determine patterns for each letter, thus an A can be build from 3 linear formules, check if the drawing matches this structure. You can than compute the derivatives of the drawings and from those derivatives cross check them with a database to determine which letter it is.
But this is extremely difficult, we tried to read digits in a sudoku puzzle which was already quite a difficult task to accomplish (and we tried to reference it against a database with images, as well as checking several characteristic points in a figure etc) this went OK with printed letters, but with handwritten it was a disaster. Not trying to discourage you, maybe there are libraries out there which you can use, but I would reconsider what you are trying to accomplish and determine an approach for yourself.
CB.NET said:
Thanks for the answer...
the "A" is only an example caracter.
in the real world example i use japanese caracters.
the user shall be paint the correct caracter in my app, like this on the picture...
Click to expand...
Click to collapse
I highly recommend making a class of "Cases" this way if it detects "A" it uses the "A" case select opposed to making a ton of "if" and "else" statements.
Better yet... You always could use an if/else statement or have an array of listed recognized items...
Here is something that might help: http://joshsmithonwpf.wordpress.com/2007/06/12/searching-for-items-in-a-listbox.
HI all.
I'm creating application for search ATM with filters:
Bank (List of banks)
Payment System (VISA, MasterCard, Maestro)
Currency (USD, Euro, etc)
Location (Current, Select on the map, Saved Places)
Time (No matter, now, 24hour)
Distance in (yard, mile).
I don't like my UI now, there are many Spinner's. It would be great to get any advise how to make UI more attractive.
Thank everybody!
Tuxper said:
HI all.
I'm creating application for search ATM with filters:
Bank (List of banks)
Payment System (VISA, MasterCard, Maestro)
Currency (USD, Euro, etc)
Location (Current, Select on the map, Saved Places)
Time (No matter, now, 24hour)
Distance in (yard, mile).
I don't like my UI now, there are many Spinner's. It would be great to get any advise how to make UI more attractive.
Thank everybody!
Click to expand...
Click to collapse
You can download some app by search like "atm finder" , "toilet finder", "gas station finder".
And learn from them
Truly try to ask less info and check material design tutorials
here an idea material like..
ive tryed with green color
Like the design of the post above. Hope there is the possibility to search in other length units than yards? European people don't know how to deal with that
Johannes Goß said:
Like the design of the post above. Hope there is the possibility to search in other length units than yards? European people don't know how to deal with that
Click to expand...
Click to collapse
You can code a function to get the device's Country and switch between showing yards and meters based on that.
Final UI
Hi all.
Thank you for your all advices.
Finally I got this UI:
Example the rom name K50a40_S112_150610_ROW_TO_K50a40_S114_150618_ROW_W CDE.zip
Forum setup long word to 50 characters.
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
Yep, this has always been the case, for as long as I can remember. Not sure if the limitation is vBulletin, SQL or something else?
We've encountered the same in our forum & turned out to be vBulletin bug.
@natong
It would be better if you put all those long filenames inside CODE tag.
Titokhan said:
We've encountered the same in our forum & turned out to be vBulletin bug.
@natong
It would be better if you put all those long filenames inside CODE tag.
Click to expand...
Click to collapse
Could you adjust more width and unlimit height for CODE tag ?
Currently it limit to display only 10-20 lines height with scrollbar.
@natong
Sorry, I can't help you with that. But its indeed better to get a CODE window without any horizontal scrollbar.
I known how to post long word now.
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890