Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: SMcNeill on January 08, 2020, 01:57:47 am

Title: QB64 Oddness at Work
Post by: SMcNeill on January 08, 2020, 01:57:47 am
I really love the first few results from this simple code:

Code: QB64: [Select]
  1. PRINT "QB64 at work:"
  2. PRINT "PRINT 34000000000000000000000000000000000000000"
  3. PRINT 34000000000000000000000000000000000000000
  7. PRINT "PRINT x = 34000000000000000000000000000000000000000"
  8. x = 34000000000000000000000000000000000000000
  9. PRINT "x = "; x
  13. PRINT "PRINT 34000000000000000000000000000000000000000##"
  14. PRINT 34000000000000000000000000000000000000000##
  18. PRINT "PRINT x = 34000000000000000000000000000000000000000##"
  19. x = 34000000000000000000000000000000000000000##
  20. PRINT "x = "; x
  24. PRINT "PRINT x## = 34000000000000000000000000000000000000000##"
  25. x## = 34000000000000000000000000000000000000000##
  26. PRINT "x## = "; x##
  30. PRINT "PRINT 34000000000000000000000000000000000000000."
  31. PRINT 34000000000000000000000000000000000000000.
  33.  

And then compare the first one to the last one...

There's no DEFINT, DEFLNG, or anything in this code which would change our default types to integers, and yet the first couple of results *appear* as if they might be set by an integer limit....

The thing is, LOOK close.  The value we see, compared to our INTEGER64 signed and unsigned limits is below:

12,354,918,591,714,295,808  -- the value we get printed, and assigned.
 9,223,372,036,854,775,807  -- the signed INT64 limit.
18,446,744,073,709,551,615  -- the unsigned INT64 limit.


So it translates the value to something greater than what a signed integer64 can hold, yet it doesn't make it the limit of what an unsigned integer64 can hold...  Just where the heck does that 123... come from??  And why does our value become that one??? 

QB64 is utterly baffling me with how it produces the results it does for us sometimes...
Title: Re: QB64 Oddness at Work
Post by: Qwerkey on January 08, 2020, 05:03:37 am
Quote from: SMcNeill on January 08, 2020, 01:57:47 am
Just where the heck does that 123... come from??  And why does our value become that one??? 


Also try:
Code: QB64: [Select]
  1. PRINT "PRINT 32000000000000000000000000000000000000000"
  2. PRINT 32000000000000000000000000000000000000000

A slightly lower number which gives a larger final printout.

Baffling indeed!  Just what is happening in the processing of the large decimal number into binary and why doesn't it stay fixed at default variable limit as you say???

This is the difference with dumb machines.  The human 'machine' would simply output: "Stop giving me silly numbers".

(and by the way, Fellippe, what are you doing up at this time?!).
Title: Re: QB64 Oddness at Work
Post by: SMcNeill on January 08, 2020, 05:10:29 am
Maybe it’s overflow and the number we’re seeing is MOD 18,446,744,073,709,551,615?

STx can check that with string math for us, I think.  ;)
Title: Re: QB64 Oddness at Work
Post by: Qbee on January 08, 2020, 07:48:08 am
Watching the results made me think of "Weird Scenes Inside the Goldmine".
Long forgotten ... thank you for make me think of that.
Title: Re: QB64 Oddness at Work
Post by: Pete on January 08, 2020, 10:57:52 am
Maybe start working on a new version: QB-LGBTQ. It's like QB64, but completely non-binary.

Pete
Title: Re: QB64 Oddness at Work
Post by: Qbee on January 08, 2020, 12:05:24 pm
Quote from: Qbee on January 08, 2020, 07:48:08 am
Watching the results made me think of "Weird Scenes Inside the Goldmine".
Long forgotten ... thank you for make me think of that.
Couldn't resist - went into the city and bought it - AGAIN.
Title: Re: QB64 Oddness at Work
Post by: Richard Frost on January 26, 2020, 01:06:06 am

I understand what big numbers like that mean.  You are building a really
big television that will use all material in the Universe. 

It starts with hanging one led off a serial port, 8 off a parallel port,
then arrays interfaced directly to the bus, and now this, a dastardly
plan to make everything blink. 

An agent of UNICEF is onto you.
Title: Re: QB64 Oddness at Work
Post by: SMcNeill on January 26, 2020, 01:48:31 am
Quote from: Richard Frost on January 26, 2020, 01:06:06 am

I understand what big numbers like that mean.


Actually, it just means I was testing the new math evaluation routines for use with CONST, and I noticed some really odd results.  I spent hours trying to debug the glitch in my math stuff, only to figure out in the end that QB64 itself was producing the oddness.  ;D
Title: Re: QB64 Oddness at Work
Post by: bplus on January 26, 2020, 09:58:06 am
I ran into a problem like that with Deal Or No Deal. The suit case prize amounts run from 1 million dollars down to 1 cent, can you print .01 from data as double type formatted with commas and dollar sign? Not before going through hell! .01 internally gets changed to 9.99blahblah D -blahblah
Title: Re: QB64 Oddness at Work
Post by: OldMoses on January 30, 2020, 07:15:13 pm
Quote from: SMcNeill on January 26, 2020, 01:48:31 am
Actually, it just means I was testing the new math evaluation routines for use with CONST, and I noticed some really odd results.  I spent hours trying to debug the glitch in my math stuff, only to figure out in the end that QB64 itself was producing the oddness.  ;D

I feel your pain. I too, was spending hours trying to debug some gravity routines that weren't working right. They did fine with small stars and planets, but would choke when presented with a low density supergiant star. The computations require the squaring and cubing of vast distances and I knew the size of the numbers was the issue. Although _INTEGER64 can hold the numbers, QB64 does not seem to like using them in those computations, even though the result goes into a _FLOAT. I had to convert the integers to floats before running them through the arguments, then all was well. Until I did that all sorts of goofy answers were the norm.
Text Only | Text with Attachments