Talk:Price fraction: Difference between revisions
→I don't even think this task is correct: new section
(????) |
(→I don't even think this task is correct: new section) |
||
| (6 intermediate revisions by 5 users not shown) | |||
Line 19:
:::Hi Eriksiers, the task description begins: "Task: Given a floating point value between 0.00 and 1.00 ...", so I would assume we don't have to handle it. --[[User:Paddy3118|Paddy3118]] 11:52, 20 March 2010 (UTC)
::::Okay, then I'll leave the BASIC example the way it is and not worry about it. -- [[User:Eriksiers|Eriksiers]] 00:33, 22 March 2010 (UTC)
== what was meant ==
I take it that it was meant (or implied) that: ''given a floating point value between 0.00 and 1.00 <u>(inclusive)</u> ···''
Some people get very picky about the way the end points (and/or the word ''between'') are described (or not described). -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:56, 27 June 2020 (UTC)
== Floating point for money?! ==
Line 28 ⟶ 36:
::::Note that once you have a function which works with integers it should be trivial in most languages to wrap it with something which multiplies floating point numbers by 100 and gets the nearest integer and divides the result by 100. Some languages also let you mark the floating point variant as "obsolete" with a message that points at the other approach. --[[User:Rdm|Rdm]] 19:20, 18 March 2010 (UTC)
:::::That said, there are some efficiency problems with that approach. There are several ways of dealing with these problems. Probably the best would be to coerce numbers to integer values before doing arithmetic on them and convert them back after. If you implement this approach the storage system should probably complain if it is ever given values which deviate too much from values which could plausibly result from this approach -- this would be run-time detection of invalid code. --[[User:Rdm|Rdm]] 14:25, 17 May 2010 (UTC)
:::::: One solution is to use integers with a scale. Another is to use decimal floating point numbers. Not all languages have such features, of course. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 19:59, 27 June 2020 (UTC)
== Representing the data ==
Line 106 ⟶ 116:
:::Then I am afraid I do not understand your claim. But if you could give me a specific example which you believe fails, I can try it in the [[Price_Fraction#J|implementation I wrote]] and see if it works or not. --[[User:Rdm|Rdm]] 19:07, 6 August 2010 (UTC)
::::Since your implementation seem to use floating-point numbers, it fails to return the value 0.26 as the task requires. Float "0.26f" is not 0.26, because the latter cannot be represented as an IEEE 754 float. The problem would disappear if the task stated the accuracy of the result and the comparisons. E.g. 0.26 +/- 0.0005. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 19:23, 6 August 2010 (UTC)
:::::Well, if you look close enough, we are not returning numbers at all -- we are dealing with bit patterns, and it is up to us to determine what they represent. Personally, I would claim that the result I am returning for this case represents 0.26. <lang> priceFraction 0.15
0.26</lang>--[[User:Rdm|Rdm]] 19:27, 6 August 2010 (UTC)
: Not quite Dmitry
Line 113 ⟶ 126:
::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)
I have changed my mind. If the task is about money, and its says use floating point, then I would rather it be changed to not mention floating point at all as the phrase "floating point is the wrong type to use with money" is a very good phrase to follow. --[[User:Paddy3118|Paddy3118]] 19:34, 6 August 2010 (UTC)
== I don't even think this task is correct ==
Ok, this seems to be a task taken from "real life". What should its purpose be? Obviously, to determine the change on the dollar. Hence, the first line (>= 0) doesn't seem correct in the light of "< 1.01".
Let's say you get a price that is right on the dollar: e.g. $9.00. Which rule does apply? The ">= 0" one or the "< 1.01" one? If it is the former, you'll have to pay an extra 10 cents. If it's the latter one, you don't have to pay anything on top of that.
The only way I get this thing consistent is by assuming that the first rule should be "> 0" - and not ">= 0". This doesn't prevent me from making code that works as advertised, but if I were running a pharmacy, I'd be making a phone call to this "government agency" before processing any clients with "x.00" bills.
And yeah, you can express this table by just salting the math with a little binary magic ;-) --[[User:Hansoft|Hans Bezemer]] ([[User talk:Hansoft|talk]]) 12:27, 29 March 2022 (UTC)
| |||