----------------------------------- difi13 Fri May 04, 2012 3:01 pm Turing "mod" fail ----------------------------------- Hello Guys and Girlz. I want to share the magic of turing with you. ok so lets start with taking a cube root of something for example put 64 ** (1/3) %will output 4 put 4 mod 1 %will output 0 and finally put (64 ** (1/3)) mod 1 %will output 1 !!!!!!!!! I would love to know why this happens and possibly the solution Please specify what version of Turing you are using last one. ----------------------------------- Tony Fri May 04, 2012 3:10 pm RE:Turing "mod" fail ----------------------------------- 64 ** (1/3) likely results in a real (floating point) type, not int. What do you get when you run [code] put round((64 ** (1/3))) mod 1 [/code] ----------------------------------- difi13 Fri May 04, 2012 3:55 pm RE:Turing "mod" fail ----------------------------------- its 0 , thanks. but there is one more problem if make a for loop. for x : 1..1000 if x ** (1/3) mod 1 = 0 then put "Cool" end if it will never print cool but if we go for x : 1..1000 if round(x ** (1/3)) mod 1 = 0 then put "Cool" end if Cool will print 1000 times. So the question is how to make it print something if a cube root of a number is an integer(has no decimals) ----------------------------------- Tony Fri May 04, 2012 4:09 pm RE:Turing "mod" fail ----------------------------------- what does round function do? ----------------------------------- difi13 Fri May 04, 2012 4:14 pm RE:Turing "mod" fail ----------------------------------- It is obvious that it rounds the number so anything rounded mod 1 will equal to 0. Now the problem comes "how to make it print something if a cube root of a number is an integer(has no decimals)" ----------------------------------- crossley7 Fri May 04, 2012 4:17 pm RE:Turing "mod" fail ----------------------------------- think about the easiest way to check if a number is an integer or not. Refer to Tony's last post for a clue. In fact, you answered your own question in the same post. Think about it a bit and you will see your answer. Don't use mod for this type of thing since it really works best with integers only and not with reals. ----------------------------------- difi13 Fri May 04, 2012 5:05 pm RE:Turing "mod" fail ----------------------------------- I tried so much stuff. Even stupid check like this: if 64 ** (1/3) = round (64 **(1/3)) then put "Good" end if will never print Good. But both numbers are 4 ----------------------------------- Tony Fri May 04, 2012 5:21 pm RE:Turing "mod" fail ----------------------------------- no, they are not both 4 The first number is 4.0 The second number is 4 ProTip, don't use = comparison on float-point numbers. 4.0 = 4.0 is not necessary true (you'd need to understand float-point standard to understand why that might be the case). So hint: you'd need to compare integers; but round(x) = round(x) obviously doesn't tell you anything useful, so there's some extra work to be done. ----------------------------------- difi13 Fri May 04, 2012 6:04 pm RE:Turing "mod" fail ----------------------------------- I give up ... ----------------------------------- Tony Fri May 04, 2012 7:10 pm RE:Turing "mod" fail ----------------------------------- lets try with a specific example: 4.2 is it an integer? How do you know? ----------------------------------- difi13 Fri May 04, 2012 8:37 pm RE:Turing "mod" fail ----------------------------------- it is not because there is a decimal. ----------------------------------- Aange10 Sat May 05, 2012 10:13 am RE:Turing "mod" fail ----------------------------------- And you learned that if there is a decimal, (such as 4.2 OR the output of 64 ** (1/3)) then when you mod it by 1 it is not= 0. Likewise you know that if it is an integer (has no decimals) and is modded by 1, then it comes out to be 0. With the above logic, you can tell if a number is an integer (not decimals) or a real number (has decimals). Unless the real number ends with .0, such as 4.0. If that matters to you, I suggest using your numbers as strings and seeing if they contain a ".". Also I wanted to point out that the round() function turns a real number into an integer (takes away the decimals). ----------------------------------- difi13 Sat May 05, 2012 11:59 am Re: RE:Turing "mod" fail ----------------------------------- Also I wanted to point out that the round() function turns a real number into an integer (takes away the decimals). Heh .. It seems that turing disagrees with you on that. round(64**(1/3)) still returns 4.0 and will never be = to 4. ----------------------------------- Dreadnought Sat May 05, 2012 12:28 pm Re: Turing "mod" fail ----------------------------------- Also I wanted to point out that the round() function turns a real number into an integer (takes away the decimals). Heh .. It seems that turing disagrees with you on that. round(64**(1/3)) still returns 4.0 and will never be = to 4. Have you tried it? put round(64 ** (1/3)) = 4 >> true put round(64 ** (1/3)) >> 4 % Using Turing 4.1.1 (last official release of Turing) Please give suggestions a try before saying they don't work. ----------------------------------- difi13 Sat May 05, 2012 12:45 pm RE:Turing "mod" fail ----------------------------------- Sorry I meant that this would not work in my case since I need this sort of construction. for x : 1..1000 if round(x ** (1/3)) mod 1 = 0 then put "Cool" end if I am looking to find which numbers (cubed) will not give me any decimals. If I round it, the outcome will be that all the numbers will have no decimals. I hope that you understand what I am saying ----------------------------------- Dreadnought Sat May 05, 2012 1:15 pm Re: Turing "mod" fail ----------------------------------- So you want to test for perfect cubes. You can take the cube root of a number and get a real number. You are trying to check if the real value is an integer, however, real numbers are, at times, imperfect so this only works with a few cubes (1, 27 and 216 for numbers between 1 and 1000 it seems). The mod operator can't really do much better. You know how to round that real number to an integer. Try to think of some way to use the rounded cube root to check if the original number was indeed a perfect cube. ----------------------------------- Aange10 Sat May 05, 2012 3:55 pm RE:Turing "mod" fail ----------------------------------- Do mods in all languages do that? ----------------------------------- mirhagk Sat May 05, 2012 5:20 pm RE:Turing "mod" fail ----------------------------------- depends on the langauge. In some cases mod only works on integers, in other cases it just does weird things with real numbers. ----------------------------------- Aange10 Sat May 05, 2012 8:48 pm RE:Turing "mod" fail ----------------------------------- That's actually very interesting. I wonder why that is... could you elaborate? ----------------------------------- Dreadnought Sat May 05, 2012 11:27 pm Re: Turing "mod" fail ----------------------------------- Well, modular arithmetic is only defined for integers so how you extend the concepts into real numbers is not clear. For example, say you had a theorem in modular arithmetic that requires a number to be prime. How do you extend this to real numbers? ----------------------------------- mirhagk Sun May 06, 2012 8:37 am RE:Turing "mod" fail ----------------------------------- the way the computer handles mod for integers is actually the exact same way they handle division (it's actually calculated at the same time). Floating point numbers are handled completely different, and are not precise. Basically if your program relies on modular arithmetic for real numbers, change your program. ----------------------------------- Aange10 Sun May 06, 2012 10:03 am RE:Turing "mod" fail ----------------------------------- Interesting, thank you both. What about 125 ** 1/3 not= 5? ----------------------------------- evildaddy911 Sun May 06, 2012 10:17 am RE:Turing "mod" fail ----------------------------------- because 5 is an integer, whereas 125 ** 1/3 is a real number, 125 ** 1/3 will never equal "5" ----------------------------------- Dreadnought Sun May 06, 2012 2:54 pm Re: Turing "mod" fail ----------------------------------- because 5 is an integer, whereas 125 ** 1/3 is a real number, 125 ** 1/3 will never equal "5" Although that does seem to be a valid explanation, I'm afraid it is not. Notice this for i: 1..10 put i, " ", (i ** 3) ** (1/3) = i end for % The result is 1 true 2 false 3 true 4 false 5 false 6 true 7 false 8 false 9 false 10 false Notice that the cube roots of 1, 27and 216 are actually equal to 1, 3 and 6 even though the roots are real and 1, 3 and 6 are not. The true reason is that real numbers are not perfectly accurate (they only store so many digits). var num : real := 125 ** (1 / 3) put frealstr(num, 16,15) var num2 : real :=216 ** (1 / 3) put frealstr(num2, 16,15) % Result 5.00000000000000088817841970012523233890533447265625 6.00000000000000000000000000000000000000000000000000 Basically, 216 ** (1/3) (don't forget that 1/3 is a real too) happens to come out as 6 exactly once it is rounded (usually real numbers have 16 digits of accuracy). But this is not so for 125. Hope this clear thing up. ----------------------------------- Aange10 Sun May 06, 2012 5:00 pm RE:Turing "mod" fail ----------------------------------- I knew that evildaddy, i didn't mean the typespecs to be equal, i meant the value. @Dread, so the value of 125 ** 1/3 is 5.00000000000000088817841970012523233890533447265625, not because of exponential function, but because of the inaccuracy of 1/3 (.3repeating)? ----------------------------------- Tony Mon May 07, 2012 1:01 am Re: RE:Turing "mod" fail ----------------------------------- @Dread, so the value of 125 ** 1/3 is 5.00000000000000088817841970012523233890533447265625, not because of exponential function, but because of the inaccuracy of 1/3 (.3repeating)? Kind of, but probably not for the reasons that you are thinking of. See http://en.wikipedia.org/wiki/IEEE_754 for the standard in how floating-point numbers are actually represented: (-1)^s * c * b^q Where the base b is typically 2 (binary representation of the number). As such, there is simply no exact mapping between some decimal fractions and binary encodings. For what integer values of c and q would [code] 0.1 = c * 2^q [/code] be true? So something like 1/10 is just as problematic as 1/3. A way to deal with this is to never compare numbers directly, but only with less-than and greater-than checks, within deltas. In the quoted example, 125 ** 1/3 is less than 0.000000000000001 away from 5.0. If that is acceptable for your calculations, you can just call it 5.0. Some languages have that build in. ----------------------------------- Amarylis Thu May 10, 2012 5:30 am RE:Turing "mod" fail ----------------------------------- So, would doing something like... [syntax="turing]if num > 5 and num < 5.000001 then num := 5 end if[/syntax] Solve the problem for 125 ** (1/3)? (What would be a better solution for this though?) ----------------------------------- Dreadnought Thu May 10, 2012 7:45 am Re: Turing "mod" fail ----------------------------------- You know how to round that real number to an integer. Try to think of some way to use the rounded cube root to check if the original number was indeed a perfect cube. Here I was hinting at a simple way of doing things. Say I give you 28, you compute 28 ** (1/3) and round it to an integer, this gives you 3. How can you easily figure out if 3 is the cube root of 28? (which will tell you if 28 is a perfect cube) ----------------------------------- evildaddy911 Thu May 10, 2012 3:36 pm RE:Turing "mod" fail ----------------------------------- if a ** b = c then c ** (1 / b) = a end if ----------------------------------- Dreadnought Thu May 10, 2012 4:02 pm Re: Turing "mod" fail ----------------------------------- if a ** b = c then c ** (1 / b) = a end if Except when b = 0. :P But that's the idea. This gives an easy check for a perfect cube if (round (a ** (1/3)) ** 3) = a then put "a is a perfect cube" end if