Talk:Price fraction: Difference between revisions
→I don't even think this task is correct: new section
No edit summary |
(→I don't even think this task is correct: new section) |
||
| (19 intermediate revisions by 7 users not shown) | |||
Line 18:
:::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 26 ⟶ 35:
:::All good points. However, (1) I'm the maintenance programmer, and (2) to work in integers would require a significant rewrite, something I have neither the time nor the patience for (I don't get paid for the work, and have to fit it in wherever and whenever possible.) --[[User:Axtens|Axtens]] 02:30, 16 March 2010 (UTC)
::::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 85 ⟶ 97:
::Given the regularity of the data, I'd go for TSV (tab-separated values) rather than CSV (comma-separated values). TSV's whitespace makes things clearer than a comma. --[[User:Axtens|Axtens]] 13:48, 20 March 2010 (UTC)
:::I thought about that, but realized that CSV has broader existing support in spreadsheet tools and the like. --[[User:Short Circuit|Michael Mol]] 14:40, 20 March 2010 (UTC)
::::Excel
The goal of the task description is to communicate to human programmers, not programs. CSV/TSV are textual, which is good; but they don't convey as much information as the explicit depiction of the ranges that we have now. Yes it may be harder to cut-n-paste values into the source for your program, but that use is secondary. When all the examples are completed, you want a task desccription that reads well. --[[User:Paddy3118|Paddy3118]] 11:26, 21 March 2010 (UTC)
:Good point and well made. --[[User:Axtens|Axtens]] 14:25, 21 March 2010 (UTC)
::<blush>I try.</blush> --[[User:Paddy3118|Paddy3118]] 16:16, 21 March 2010 (UTC)
== Rounding? ==
How conversion [0.0,0.06[->0.1, [0.06,0.11[->0.18 can be named ''rounding''? It is certainly not, because any rounding function must be idempotent, i.e. ''f''(''f''(''x''))=''f''(''x''). The function defined by the table violates this requirement. Consequent "rounding" yields: 0.05->0.1->0.18->0.32 and so on. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:22, 6 August 2010 (UTC)
: I changed the task description to remove the word "rounding". --[[User:Rdm|Rdm]] 18:33, 6 August 2010 (UTC)
== The task cannot be implemented ==
Another issue with this task is that all provided implementations are broken. The problem is that some of the values from the table simply cannot be represented in the floating-point format based on either 2 or 16 radix. This covers basically all known modern machines. Since these values are non-existent the task cannot be implemented. The moral: don't use floating-point numbers in place of the fixed point ones. --[[User:Dmitry-kazakov|Dmitry-kazakov]] 18:22, 6 August 2010 (UTC)
: 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)
:::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
:# You would have to demonstrate that floating point math would fail for the particular case of this range of values and "cut points", remember, we are dealing with whole cents or their representation as fractions of a dollar up to less than two dollars.
:# 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)
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)
| |||