Talk:Cuban primes

From Rosetta Code

Why so large?

I don't know why to choose such a big number "show the 100,000th cuban prime." It take me above 2min runtime. the 6635th cuban prime 4293894169 is the last < 2^32. --Horst.h (talk) 11:33, 1 February 2019 (UTC)

My theory is that Gerard lives in the upper midwest of the US and is trying to heat his house with his processor. 🤔 --Thundergnat (talk) 13:44, 1 February 2019 (UTC)
That specific number was the only cuban prime of any substance that could be verified as being correct.   If anyone had a reputable web page that has a reference to a smaller number, I would've used that instead.   So Thundergnat's theory falls flat.     -- Gerard Schildberger (talk) 14:10, 1 February 2019 (UTC)
Darn! :-) --Thundergnat (talk) 14:37, 1 February 2019 (UTC)
However ...     If you'd take a possible (high) average of the price of a kilowatt-hour   (say, in the USA)   of   15¢,   which is   1/4¢   per kilowatt-minute   (I pay less than a dime/kilowatt-hour).   Most modern PC's today have a power supply of 250 watts (or thereabouts, some home-built PCs have larger ones),   but that usage is that usually only that high when starting up the electric motors for the disk drives and whatnot.   Once running, most PCs use around 85 watts up to around 250 watts, excluding the monitor.   So, at 250 watts for a powerful multi-core PC, and for running it for a couple of minutes,   that comes to   1/2¢.   This is all on-the-back-of-a-envelope type calculation.   Let's double that to include the monitor's power consumption and other external devices.   Now, if you double that,   and double it again,   and then double it once again,   that's still less than a nickle.   If you send me a SASE,   I'll send you a check.   🙂     -- Gerard Schildberger (talk) 01:57, 16 August 2019 (UTC)

Python not correct

For instance, output includes 91.--Steenslag (talk) 14:05, 9 June 2019 (UTC)

I've included a     {{incorrect|Python}}     statement to flag the Python entry as incorrect.     -- Gerard Schildberger (talk) 20:35, 9 June 2019 (UTC)
Looks like whomever translated it managed to put a variable name "u" in place of a "v" in the "mx = int(math.sqrt(v))" statement. Works a lot better now. Also the mx var was from 1 instead of 0, but it's unknown if that contributed to the issue.--Enter your username (talk) 02:16, 10 June 2019 (UTC)
P.S. The translator apparently translated this from the C# version. It had a nested assignment statement that could be confusing to some. If the translator had noticed that the C# version was a translation (in turn) of the Visual Basic .NET version, (where nested assignments are not allowed), they might not have experienced this issue, as it was clearer (in the vb version) which variable was being acted upon.--Enter your username (talk) 02:23, 10 June 2019 (UTC)
Thanks for fixing the program.     -- Gerard Schildberger (talk) 02:40, 10 June 2019 (UTC)

Task in a wrong category

This task is defined to be in the category Category:Programming_Languages, surely by a mistake, so it is appears at the end of such that page. Laurence (talk) 20:42, 13 October 2019 (UTC)

Could you be more specific please.   What is "it" and what is the name of "that" page.   I could not find what you are referring to, perhaps I'm overlooking the obvious.     -- Gerard Schildberger (talk) 00:13, 14 October 2019 (UTC)
Hi. The page had been already fixed by User:Thundergnat when you retrieved it. It seems that the page contained a [ [ Category:Programming_Languages ] ] (I am not sure), so this task was listed in the programming languages page, as it were one of them. Well (in order to be precise), it was listed as the only one entry of a category named "Programming languages", because actual programming languages are in fact subcategories. Laurence (talk) 00:31, 14 October 2019 (UTC)
OK, thanks.   I had thought I was going blind or something worse.   -- Gerard Schildberger (talk) 00:55, 14 October 2019 (UTC)