Talk:Price fraction: Difference between revisions
→I don't even think this task is correct: new section
(→The task cannot be implemented: Change) |
(→I don't even think this task is correct: new section) |
||
| (3 intermediate revisions by 2 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 118 ⟶ 128:
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)
| |||