Anonymous user
Talk:Price fraction: Difference between revisions
→The task cannot be implemented: Fixed point also?
(→The task cannot be implemented: Have you checked?) |
(→The task cannot be implemented: Fixed point also?) |
||
Line 102:
: These values certainly can be implemented. If your language's floating point implementation does not include any provisions for representing decimal fractions using floating point you can multiply the numbers by 100 and use integers, internally, in your code. (Multiplying by 100 and rounding would be good practice, also, if you were performing sums on these numbers.) --[[User:Rdm|Rdm]] 18:28, 6 August 2010 (UTC)
::That would not help, because you still cannot compare non-existent numbers. The problem will persist so long the input is required to be floating-point. You cannot input 0.6, or 0.600000000000001, or 0.599999999999 for that matter. The technique you described is in essence what ''fixed-point'' numbers are. Does the task require floating-point numbers or permits any numeric representations? What is the required accuracy? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:50, 6 August 2010 (UTC)
: Not quite Dmitry
Line 107 ⟶ 109:
:# I mentioned this point and provided an integer Python solution that scaled input to be in cents.
:--[[User:Paddy3118|Paddy3118]] 18:35, 6 August 2010 (UTC)
::This is what I meant. It is not floating point, it is fixed point, and the required accuracy is 0.01. So? --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:50, 6 August 2010 (UTC)
| |||