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) |
|||
| (29 intermediate revisions by 9 users not shown) | |||
Line 15:
What's supposed to happen if you get a negative number, or a number greater than 1.01? -- [[User:Eriksiers|Eriksiers]] 19:13, 15 March 2010 (UTC)
:The calling routine takes care of those details --[[User:Axtens|Axtens]] 02:30, 16 March 2010 (UTC)
::Okay, but if an illegal value gets passed in anyway, what should we do? Return the number as-is? Zero? Error? -- [[User:Eriksiers|Eriksiers]] 20:04, 19 March 2010 (UTC)
:::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 21 ⟶ 34:
:: Two topics on the original wiki, [http://c2.com/cgi/wiki?FloatingPointCurrency Floating Point Currency] and [http://c2.com/cgi/wiki?MoneyObject Money Object], contain many anecdotes, cautionary tales, and useful links. For a toy problem like this, using an integer in units of cents should suffice. --[[User:IanOsgood|IanOsgood]] 01:29, 16 March 2010 (UTC)
:::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 71 ⟶ 88:
In an "strongly specified" sort of problem, the specification would be set in stone and the developers' insights would not be relevant to the specification.
: I'd be open to standardizing on CSV as a format for tabular data, and hold a strong recommendation that tasks that make use of tabular data present it in CSV, and that examples that make use of it import it from such. It depends on it being fairly portable; one would be increasing the complexity of every task to including either processing stream input or file input. --[[User:Short Circuit|Michael Mol]] 21:36, 18 March 2010 (UTC)
:: Real code parses it in whatever idiotic form the local legislature decides to publish it in. These days, that means whatever format one gets when one cuts-n-pastes it out of some PDF… –[[User:Dkf|Donal Fellows]] 22:27, 18 March 2010 (UTC)
: The issues raised are certainly interesting. However after the discussion of the merits of two alternative forms for specifying the table data, it seems to me that the data format chosen by the J implementation (and others) is a nice compromise between them - easily understandable/editable by the "casual maintainer" (especially when the values are lined up) and not bulky or misleading.
:While I think the idea of standardizing on CSV for presenting tablular (and list?) data to be used in a task has some merit, I'm not sure that adding routines to all such tasks for reading/parsing it from a CSV file is desirable. I'm pretty sure there are already tasks for reading and writing files in CSV format.--[[User:Tikkanz|Tikkanz]] 22:48, 18 March 2010 (UTC)
:If the government supplied data then I would copy their description into the program and add a link to the original source too. When things change, the maintainer would have both before and after sources to decide on what has changed and then to implement that change. on how the routine is coded: after learning about bisect it seems right for the job and leaves the raw range and output price data in a nicely displayed way. A competent maintainer who didn't know the bisect model should be able to learn to use it from the Python documentation and a little experimentation as its use in the Python example is straight-forward. <br>
:CSV has its uses but this table of regions I find OK for this task, but see no need to parse it as part of performing the task. --[[User:Paddy3118|Paddy3118]] 09:42, 19 March 2010 (UTC)
::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 reads tab-delimited data. IIRC, give it a .TXT file with TSVs and it parses them into columns automagically. --[[User:Axtens|Axtens]] 14:50, 20 March 2010 (UTC)
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)
| |||