Talk:Pi

Why "until a key is pressed"? That's an annoyingly non-portable construct. --Rdm 22:20, 25 March 2011 (UTC)

I wrote the break key. Someone else wrote "until a key is pressed". The idea is that the process runs for infinity unless the process is terminated. I have reverted the wording to say "the break key".

Markhobley 22:40, 25 March 2011 (UTC)

Using a keyboard is non-portable? The break key is less portable. I changed it to any key to try to make it more general. Really it should just go forever if you want it to be portable. In general, portability is not necessarily a concern here I don't think. --Mwn3d 02:15, 26 March 2011 (UTC)

I agree. There are computers without a keyboard, and special industrial keyboards with the break key removed. If there is no facility to terminate the process, then it should run for infinity for the purposes of this task. I have updated the wording to clarify this point.

Markhobley 10:57, 26 March 2011 (UTC)

I take it that you are looking for until the process is terminated, in whatever way is normal for the environment, not necessarily with a key labeled “Break”. I have updated the task description to clarify this. —Kevin Reid 13:35, 27 March 2011 (UTC)

Why request "continue for infinity"? There are no computer that has infinity memory so that request will simply not be possible. A practical limit "continue as long as possible" could make more sense. --<Jofur> 11:02, 26 March 2011 (UTC)

Indeed. Infinity here means until the limits of the computer are reached. (So on a system that uses 32 bit registers, calculations would probably cease after 4294967295 digits, unless big numbering was used.)

Markhobley 15:54, 26 March 2011 (UTC)

There are basiclly two ways to calculate Pi that I know of; #1, (traditional) to calculate the sequence in a row & #2 (BBP-Formual) that calculates specific digits in base-16... Both needs huge amount of memory and if you aim for 'infinity' the #1 system will likely crash due to the data arrays and #2 due to the huge polynoms used for the smallest fractions - neither will give anything close to 4294967295 digits on a 32-bit system.

If to behave nice, maybe the program should end before it crash? --<Jofur> 16:28, 26 March 2011 (UTC)

How?

The task should provide at least one method for doing such a calculation I think? --Paddy3118 17:10, 26 March 2011 (UTC)

I left this open for the coder to decide at this stage, but I would probably use bbp to obtain each consecutive digit. (We could always split the task for different methodologies in future).

Markhobley 21:21, 26 March 2011 (UTC)

It can still be left up to the programmer, but maybe offer some suggestions with pseudocode? People don't have to generate infinite digits of pi very often. They probably don't have algorithms lying around in their brains. --Mwn3d 21:25, 26 March 2011 (UTC)

There's an algorithm that allows you to calculate a specific digit of pi. I'd google it, but I'm about to head out the door. It might be possible to memoize some of the intermediate values. --Michael Mol 13:36, 27 March 2011 (UTC)

bbp? --Paddy3118 22:46, 26 March 2011 (UTC)

Deleted GUISS solution

GUISS uses the desktop calculator for this task, and produces the maximum number of digits that the desktop calculator produces. ("Forever" in computing terms means until the maximum value of the registers is reached, or resources are exhausted, rather than "forever" as in the life of the Universe). The GUISS solution provided the closest approximate fit based on its capabilities. Maybe I should have stuck a note that the solution provided produces as many digits as possible for the implementation. (It is not possible to get more digits). The solution was deleted, but I will restore it and pin a note. Markhobley 22:34, 23 July 2011 (UTC)

So "my language can only quote windows calcualator, and windows calculator can only provide 16 digits" is your defense? Assuming that's what you meant by "resources", then your language is incapable of meeting reasonable human expectations of this task, and the decent thing to do is just say so. Why would you rather find some loophole and try to squeeze a "solution" in here, what's the point of that? --Ledrug 00:13, 24 July 2011 (UTC)

So that we can compare the approaches in different langauges. This is a chrestomathy. The only options are to provide a best fit solution or omit, unless you have some other ideas. What do you suggest? Markhobley 01:13, 24 July 2011 (UTC)

I think as long we provide suitable comments explaining that the solution does not meet the task exactly, and give the reasoning, then that should be fine. Markhobley 01:16, 24 July 2011 (UTC)

Give some example wording here if you like, and I will paste it into the description. The reason is as you say: The calculator only provides 16 digits. Markhobley 01:18, 24 July 2011 (UTC)

Every solution on the page will come to a limit, because of the nature of the task. With GUISS, the limit is 16 digits, other solutions may stop after a few thousand digits, but they will stop.Markhobley 01:27, 24 July 2011 (UTC)

I'm not sure using the windows calculator really fits the task because (as far as I know) it doesn't actually calculate anything--it spits out a stored value. Otherwise I could say "System.out.println(Math.PI);" for Java and call it a day. That feels like cheating. --Mwn3d 04:50, 24 July 2011 (UTC)

I don't know Java. Could you set the precision to a high number of digits, and then System.out.println(Math.PI)? I think a two line solution would be cool. Markhobley 11:23, 24 July 2011 (UTC)

Presumably not, because it would be limited to the precision of the conventional floating point, like most other languages, or does it support arbitrary precision? Markhobley 11:27, 24 July 2011 (UTC)

While Java's got arbitrary precision fractions (java.math.BigDecimal), it's π value is just IEEE double precision. That's good enough for most work. –Donal Fellows 21:18, 24 July 2011 (UTC)

Ignoring all of that...the point of that comment was that displaying a stored value isn't in line with what this task is really asking for. I could also store a couple million digits of pi in a file which was created by some other program and then just display the contents of that file. The point is to generate the digits through calculation which is part of the example you post. --Mwn3d 21:32, 24 July 2011 (UTC)

In no way does the GUISS solution fit the spirit of the task and should be removed. In what way does it give successive digits of Pi, "until aborted by the user"? The task description is clearly asking that you use a routine that generates the digits of Pi in sequence - GUISS does not ensure that and so should be removed. The GUISS example does not aid language comparison - it stands out as an anomaly. --Paddy3118 05:37, 24 July 2011 (UTC)

Hmmm, It does generate the digits o Pi in sequence. There is an abort button on the calculator, but I don't know whether it works midflow. By replacing the desktop calculator with one that uses a bigger display to get more digits and supports abortion midflow. The GUISS solution would fit the task. The limitation is with the tool provided, rather than with GUISS. Markhobley 09:11, 24 July 2011 (UTC)

Maybe a "limited solution" marker would be a good idea. (Similar to the "incorrect solution", that reads something like 'The solution provided does not meet the exact specifications of the task, due to limitations of the language or its subcomponents. The author has tried to provide an "approximate fit" solution based on those limitations'.). I know there are other tasks on the wiki, where the solutions are an approximation, rather than an exact fit. This might be quite useful. Markhobley 09:45, 24 July 2011 (UTC)

This is not strictly true. The underlying concept — that each solution has finite limits — is true. However, it's not the case that we can say that all solutions would reach their limit if they were allowed to run indefinitely. A solution could have an time increase between each digit, ensuring that the solution does not terminate before reaching a finite limit (let's say a billion digits before the heat death of the universe) because each successive digit takes so much longer than the previous digit. --Rdm 10:52, 24 July 2011 (UTC)

Don't give him ideas. Now someone will come up with a "solution" that prints 3.14 and claim it's correct because the program sleeps a billion years between digits. --Ledrug 19:02, 24 July 2011 (UTC)

That'd not be answering; that would be being a smartass. No need for that sort of stupidity. –Donal Fellows 21:14, 24 July 2011 (UTC)

Time to delete

Hi Mark, I think it is time you just deleted the GUISS solution. Stating it generates the digits of Pi in sequence does not make it so, and the consensus is against you. --Paddy3118 07:15, 25 July 2011 (UTC)

Task split

I think what's currently at Pi should be moved to Pi/Spigot, to reflect that it's asking for a spigot algorithm for Pi. It may also be a good idea to have Pi/Constant, for language-provided constants representing pi, or some specific approximation thereof. Perhaps Pi itself should be left more general, or as a set of links to other ways to retrieve Pi. Or perhaps be a task which uses pi, which necessitates an example author's obtaining the value somehow. ("Calculate the circumference of the circle whose radius is 1/2π" would probably be sufficient and interesting; the correct answer is 1, but most code would reach that result only through precision loss.) Part of the trouble I'm observing in the hoopla around this task right now appears to be that the GUISS solution doesn't solve the task as stated, but does answer the question "how do I get π into my program," which is a question I'm likely to have if I were to visit a Rosetta Code task page named Pi. --Michael Mol 11:56, 26 July 2011 (UTC)

If we create Pi/Constant it should just redirect to Real constants and functions. I'd be ok with renaming this page to a specific algorithm name. --Mwn3d 12:20, 26 July 2011 (UTC)

"Calculate the circumference of the circle whose radius is 1/2π" seems bad, since specifying how the calculation is done is territory best left alone, and you cannot realistically specify the starting point. "Calculate the circumference of a circle whose radius is 1" would not be too bad, though "Calculate to n digits the circumference of a circle with radius n, show some examples and describe the maximum n supported by your implementation" might be more interesting. --Rdm 12:37, 26 July 2011 (UTC)

I liked the "given a circle with a radius of 1/2π, calculate the diameter of the circle" because it'd didn't require the output of a transcendental number, but did require the transcendental number to be used in calculation. I'm (honestly) puzzled how specifying the unknowns to be found is problematic; another way to say it is "given Failed to parse (syntax error): {\displaystyle c = 2πr} , and Failed to parse (SVG (MathML can be enabled via browser plugin): Invalid response ("Math extension cannot connect to Restbase.") from server "https://wikimedia.org/api/rest_v1/":): {\displaystyle r = 1/(2π)} , solve for c." We have messier solver tasks elsewhere on the site. --Michael Mol 15:03, 26 July 2011 (UTC)

Also, for that matter, Pi can be implemented without use of a spigot algorithm, if you are not concerned about efficiency. --Rdm 12:37, 26 July 2011 (UTC)

Hm. It might be worth scrapping the task and creating more defined ones, such as Pi/Bailey-Borwein-Plouffe, and leave the "Pi/" namespace available to other specific implementations.--Michael Mol 15:03, 26 July 2011 (UTC)

Pi can be implemented without use of a spigot algorithm regardless of efficiency, because that algorithm is not good at being efficient at all. The C program I wrote continuous generates Pi digits faster than the unbound spigot, despite the algorithm used was totally unsuitable for the task. --Ledrug 00:07, 27 July 2011 (UTC)

If we create more defined tasks, we might want to consider using tau instead of Pi. --Rdm 12:57, 1 August 2011 (UTC)

Ugh. Can we not have that debate here? The only significant difference between pi and tau is the impact they may have on the readability and intuitive extrapolation of formulas. I see enough difficulty agreeing on task spec as is, and pi vs tau is not clearly resolvable. For the time being, I would far prefer to stick with pi, as that's the most common and mass way of representing the number, and so that's what people are more likely to recognize and understand. When tau beats pi by a 2:1 margin, I might be more interested. --Michael Mol 14:21, 1 August 2011 (UTC)

That's not exactly an argument on merits. And there's no reason for the use of tau to exclude the use of pi any more than the use of the number 1 excludes the use of the number 0.5. That said, if googlefight meant anything to me, I might use a smaller set of numbers? --Rdm 19:58, 1 August 2011 (UTC)