Anonymous user
Talk:Hailstone sequence: Difference between revisions
m
→cache version of C
(→deleted examples: added WHY to the question of two removals of language entries. -- ~~~~) |
|||
| (7 intermediate revisions by 4 users not shown) | |||
Line 55:
::::::* Batch File
::::::* XPL0
<br>No mention was
==Haskell==
The Haskell version is 18 lines long. This version is 12 lines long and prints all of the chain for n = 27:
import Data.List
import Data.Ord(comparing)
main = do putStrLn $ "Collatz sequence for 27: " ++ ((show.hailstone) 27) ++ "\n"
putStrLn $ "The number " ++ (show longestChain)
++" has the longest hailstone sequence for any number less then 100000."
hailstone n
| n == 1 = [1]
| even n = n:(hailstone (n `div` 2))
| otherwise = n:(hailstone (3*n+1))
longestChain = fst $ maximumBy (comparing snd) $ map ((\x -> (x,(length.hailstone) x))) [1..100000]
Should this be used instead? [[User:Mathlover2|Mathlover2]] ([[User talk:Mathlover2|talk]]) 16:31, 24 February 2015 (UTC)
== Does the program need to do all this on its own? ==
Does the program need to show the sequence for 27 and find the number <100,000 with the longest sequence, or do we just need to use the program to find these?
== cache version of C ==
Running the c cache version [[Hailstone_sequence#With_caching|C]] shows:
<pre>max below 10000000 : 7532665, length 616</pre>
Pascal version shows:
<pre>Longest sequence under 10000000 : 8400511 with 686 elements</pre>
I think the problem of C-Cache is the fact that beginning with i=159487-> 5097000814 > 2^32 > unsigned long the calculation gets wrong.
I use 32 Bit.
edit: some more start values reaching highest value in the sequence:
I thought nearly quadratic for high values, but the last 319804831 -> 1414236446719942480 doesn't fit
<pre>Longest sequence under 10 : 9 with 20 elements
Highest value 15 -> 160
Longest sequence under 100 : 97 with 119 elements
Highest value 27 -> 9232
Longest sequence under 1000 : 871 with 179 elements
Highest value 703 -> 250504
Longest sequence under 10000 : 6171 with 262 elements
Highest value 9663 -> 27114424
Longest sequence under 100000 : 77031 with 351 elements
Highest value 77671 -> 1570824736 <= just below 1 shl 31
Longest sequence under 1000000 : 837799 with 525 elements
Highest value 1042431 -> 90239155648
Longest sequence under 10000000 : 8400511 with 686 elements
Highest value 6631675 -> 60342610919632
Longest sequence under 100000000 : 63728127 with 950 elements
Highest value 120080895 -> 3277901576118580
Longest sequence under 1000000000 : 670617279 with 987 elements
Highest value 319804831 -> 1414236446719942480 <= nearly limit of Uint64 </pre>
EDIT found a good web site Tomás Oliveira e Silva
[[http://sweet.ua.pt/tos/3x+1.html]] with a list of first occurences of highest value upto 2^58
[[http://sweet.ua.pt/tos/3x+1/t1.txt.gz]]
I dont know, why his values or only * 0.5 instead of 27 ->9232 is listed with 4616, 319804831 -> 1414236446719942480 is listed with 707118223359971240.
<br>
-----
<br>
It looks like my (lucky) guesstimate for REXX of '''20 decimal digits''' was very close to being on the nose, with the number '''319,804,831's''' Collatz sequence having '''19''' decimal digits for its maximum value ('''1,414,236,446,719,942,480'''). -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 22:56, 31 March 2016 (UTC)
:: thank you. thumps up . I thought about it and conclude that they speed up calculation by the observation, that every odd number gets even by 3*n+1 so they divide by 2 in the same calculation without the need of an IF-statement and add 2 to the length of the sequence.[[User:Horsth|Horsth]]
| |||