Talk:Cuban primes

From Rosetta Code

Why so large?[edit]

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[edit]

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)