A dull experiment and question about the BIGGEST Real in GMS.

[Oberon Tony TIGER]

Yes, I did an experiment to get the range of GMS' Reals.
Well, I'd heard that tan(π/2) won't get stuck though, and according to the graph, in tan(x),when x closes to π/2 from the left side, it could lead to a very very BIG number, as big as +infinity.

However, I have a try but the result is quite astonishing - (-22877332). That's not as big as my expectation(it's not small though).

I don't think it's the boundary,since I know that function real(str) could accept the string with format like "1e+n"(n is a number) and will interprete it as a real number 10000...n times ...0. and I've used a number larger like that before.

Now that it could accept the scientific notation, I think it behaves just like a calculator ... in our smartphone?They can hold a real up to (2^1024)-1

Therefore I tried the power(2,16),power(2,32),power(2,64),power(128)... with debugger and no problems. Then I test power(2,1023), it showed a 8.988465e+307, still acceptable.

Then I tried power(2,1024) and just to my assumption , it return an abnormal result: positive infinite.This value is still printable, just like:

1.<br>
J

This value can also be opposed:

-1.<br>
J

So there I have some questions:
1. Why is there no infinite/-infinite in GMS?
2. Why tan(pi/2) could be a minus value with a not so big absolute?

Well, I just curious about it,but I don't expect a necessary answer.

=========================
Mention in passing : I've reported a bug about keyboard_string and it was ticked was tagged with "SOLVED",but it doesn't solved at all.

 

[FrostyCat]

This "experiment" is farcical to anyone who has the slightest clue on floating-point arithmetic and numerical methods.

1. Why is there no infinite/-infinite in GMS?

That's because the way the runner implemented floating-point operations didn't account for these values, most likely for speed and cross-platform reasons. On HTML5, the handling is subject to however JavaScript defines them.

2. Why tan(pi/2) could be a minus value with a not so big absolute?

You are working with an approximate pi/2, not a theoretical pi/2. You are working with an approximate tan(), not a theoretical tan(). And like everything else about floating points and numerical methods, big values often mean big errors.

GM's real values use the double-precision standard, which has the same range as observed on your calculator app. As is standard with everything floating-point, the precision is based on significant digits, not total digits. The coverage thins out the farther you get from 0 --- for example 2^1023 can be characterized exactly, but not (2^1023)-2.

When I studied CS at University of Toronto, one of the first courses in it was for predicate logic and floating-point theory. The second part is designed explicitly to boot the kind of misbeliefs manifested in this "experiment" out of our systems early.

 

[Oberon Tony TIGER]

This "experiment" is farcical to anyone who has the slightest clue on floating-point arithmetic and numerical methods.


That's because the way the runner implemented floating-point operations didn't account for these values, most likely for speed and cross-platform reasons. On HTML5, the handling is subject to however JavaScript defines them.


You are working with an approximate pi/2, not a theoretical pi/2. You are working with an approximate tan(), not a theoretical tan(). And like everything else about floating points and numerical methods, big values often mean big errors.

GM's real values use the double-precision standard, which has the same range as observed on your calculator app. As is standard with everything floating-point, the precision is based on significant digits, not total digits. The coverage thins out the farther you get from 0 --- for example 2^1023 can be characterized exactly, but not (2^1023)-2.

When I studied CS at University of Toronto, one of the first courses in it was for predicate logic and floating-point theory. The second part is designed explicitly to boot the kind of misbeliefs manifested in this "experiment" out of our systems early.

Thanks for your explanation, but I still think that even if an approximate value shouldn't be so close to 0.(I also did a test in LEGACY GameMaker , and the final value is rather BIG and POSITIVE(16331778728383844), and also I tried in other calculation applications but their absolutes are not so small.(Win Calc directly throws an error,Smartphone calculator throws me an infinite,Graph throw me a value 5.2705E+18.)).

Is it related to EPSILON??

==============================================
PS: My English may be a little confusing....Well,I'm not so good at English.

 

[Wraithious]

I had a problem with that loading large numbers from a file, to solve it i wrote to a file as a string, retrieved it from the file and converted it to real and it worked, the number was like 5,518,800,127,750 ( the time in milliseconds for 175 years )