MDV Software Reclamation

[bwinkel67]

Hi Steve,

I got a really interesting results with this:

Code: Select all

5 MODE 4: PRINT #0, "Seed (1-65537)? ";: INPUT #0, seed
10 WINDOW #1, 344, 128, 35, 35: SCALE #1, 128, 0, 0: BORDER #1, 1, 7: PAPER #1, 0: INK #1, 7
15 WINDOW #2, 256, 10, 35, 164: PAPER #2, 0: INK #2, 7
20 FOR i = 1 TO 512
25   x = myRand: y = myRand
30   INK #1, 4: CIRCLE #1, x/8.388607E6, y/1.677722E7, 1
35   PRINT #2, i, pt, x/8.388607E6, y/1.677722E7
40 END FOR i
45 STOP
50 DEFine FuNction myRand
55   n = 2.147484E9: REMark typed in as 2147483647
60   seed = (seed * 16807 + 1)
70   seed = seed - INT(seed / n) * n
80   RETurn seed
90 END DEFine 

So with seed 1234567 I get a cycle half-way through (mabye a little earlier). With seed 123 it's about one-quarter of the way. With seed 567890 it goes about three-quarter before it cycles. One way to see the cycles is to add the changes below. Note that if it cycles before it is half-way through it will automatically recycle again after that same interval (so with seed 123 it will cycle multiple times when plotting 512 points):

Code: Select all

5 MODE 4: PRINT #0, "Seed (1-65537)? ";: INPUT #0, seed
10 WINDOW #1, 344, 128, 35, 35: SCALE #1, 128, 0, 0: BORDER #1, 1, 7: PAPER #1, 0: INK #1, 7
15 WINDOW #2, 256, 10, 35, 164: PAPER #2, 0: INK #2, 7
17 size = 1
20 FOR i = 1 TO 512
22   IF i = 257 THEN size = 3
23   IF i = 384 THEN size = 5
25   x = myRand: y = myRand
30   INK #1, 4: CIRCLE #1, x/8.388607E6, y/1.677722E7, size
35   PRINT #2, i, pt, x/8.388607E6, y/1.677722E7
40 END FOR i
45 STOP
50 DEFine FuNction myRand
55   n = 2.147484E9: REMark typed in as 2147483647
60   seed = (seed * 16807 + 1)
70   seed = seed - INT(seed / n) * n
80   RETurn seed
90 END DEFine 

So what is happening is that there is some massive round-off error in SuperBASIC where it causes the 31-bit random number generator to revisit an already seen number because it loses some number of digits (once you do that, mathematically you are in a cycle). I tested it and figured it out...it has to do with how SuperBASIC stores integers. Idiotically, it actually stores them internally differently in how it displays them so when you save the program to file and then reload is, you lose precision!?!?!?!

Try this, type in:

10 num = 16777216

Then, on the console type this:

run
print num - 16777216

The result will be 0.

Now save the program (save mdv1_test_bas), do a new and reload it. Then type this again:

run
print num - 16777216

Now the result is 4.

What the proverbial f___!?

[NormanDunbar]

Strangely enough, I have a similar problem tonight! (On QPC II 4.05)

I'm writing a function to return the floor of a number, just because.

When I run it from the prompt with "print floor(4)" I get the correct answer, which is 4. If I run it in a FOR LOOP, similar to this:

Code: Select all

1000 for x = -2 to 2 step 0.2
1010  print x, floor(x)
1020 end for x

I get weirdness. The output for the fractions are all fine. The values printed for x (that's x, not floor(x)) when it is around zero are:

Code: Select all

-.2
-2.328306E-10
.2

If I change the increment:

Code: Select all

1000 for x = -2 to 2 step 0.2
1010  print x, floor(x)
1020 end for x

I get more and different weirdness:

Code: Select all

-.2
-.1
-3.608875E-9
.1
.2

In all cases, when it floors most whole numbers, -2, -3, -2 or 2 for example, it returns the wrong answer for all whole numbers except where the first value in the for loop is a whole number.

Even stranger:

Code: Select all

1000 for x = -4 to 4 
1010  print x, floor(x)
1020 end for x

Works fine!

So, obviously, in the loop the value x is a floating point and there's some rounding going on which means that my whole numbers are not quite whole so the addition of -1 when INT(x) > x, as in:

Code: Select all

DEF FN floor(x)
  LOCal int_x
  int_x = INT(x)
  RETurn int_x - (int_x > x)
END DEFine floor

So, taking my code out of the equation and just running this:

Code: Select all

1000 for x = -2 to 2 step 0.1
1010  print x, 
1020 end for x

I get everything looking perfect except where zero should be, it comes out as -1.105946E-8 in this code.

I've never seen anything like this before. Who is stealing my zeros?


Cheers,
Norm.

[bwinkel67]

BTW, I'm fine with rounding. What I'm not fine with is that when you enter code into SuperBASIC and it shows it in E notation demonstrating that rounding has occurred, it should not store a more precise number somehow internally that parallels but is different form how it is displaying in code. There is just no reason for that. If you are going to allow higher precision then figure out how to capture it in code.

[stevepoole]

Hi Bwinkel67,

Insert Line 65 to your myrand routine : 65 If seed > 1E10 : print seed : stop

I soon get seed,is 1.851258E13, way above the SuperBasic 10 digit accuracy !

The QL User Guide warns against this... so your code gets digits chopped off as expected... and so the ouput cycles.

I often wonder who needs floats as big as 1E616, knowing that most of the digits are pruned off ?

Coded in 64 bit C++ , your myrand will probably be accurate and not cycle.....

Best wishes,

Steve.

[bwinkel67]

Coded in normal 32 bit systems it will be fine as well. If you read the utah.edu two page description in my original post you'll see that they state the cycle of 2^31-1 was chosen as that is the max integer for Unix systems of that time (early 2000's).

Forget about precision, if SuperBASIC can't even accurately store a 7 digit number then we have problems. And the fact that it internally keeps more info around then it shows in SuperBASIC, and then that is lost when yous save and reload, is just horrible. What kind of programming environment outside of the QL loses precision once you save and reload your source code.

[pjw]

You could try converting your algos to Archive IIRC it is accurate to 14 digits, although what it gains in precision it looses in magnitude. I used to know this stuff, but alas, no longer. I think Abacus uses the same fp routines.

[bwinkel67]

I don't do much, if any, programming in SuperBASIC. It's a good scripting language though and one reason I create the CL command shell and BASIC interpreter for the Mac. Just curious how SuperBASIC deals with precision. Maybe we ought to start a new thread on that just to see what other have to say. Does SBASIC fix that? I should try these examples on my Q68.

[bwinkel67]

Speaking of getting off topic, this thread was not meant to be either about SuperBASIC precision or random number generators though it's been fun exploring the topic (thank you to Steve!!!).

Here is my 3rd reclaimed piece of software and source code. It is a terminal emulator. This was probably the first thing I wrote on the QL because I needed to use it to dial into my work's Unix system back in the early 90's and code in Emacs. So this did do the trick, though I never implemented a full featured VT100 or VT52 terminal. I think this implemented a subset of that.

Also, before I purchased a Hermes. I suffered with character loss with this program so I optimized it using goto statements (a big no no). But I did it carefully and basically tried to get rid of double jumps (i.e. out of the back end of a switch statement was one jump and then it had to jump past the else of the if the switch was nested in) which helped tremendously.

In any case enjoy, both C source (Digital C again) and executable included. Compiled and running on my unexpanded QL and also on QLAY2. The screen and font layout is different on the US QL than on QLAY2 so I had to work a bit to get everything to display properly but it does now. It was originally written to work on US QL in TV mode so that's why the 70 column by 20 line format (I changed it to 74 columns). I recently bought one of those RetroWifi RS232 thingies so I will be hooking it up and testing it once summer starts. Yes, I could use QLterm or Qterm, but where's the fun in that -- of course if mine can't handle some of the BBS formatting commands (on that online telnet community) then I will either try and update it or use QLterm.

term.zip

(6.69 KiB) Downloaded 83 times

BTW, I may need to create a new forum topic since this one got out of hand a bit with the other discussions (although much appreciated). The initial purpose was to to share code I had written in the 90's (an encryption program, a full BASIC interpreter, and this terminal program) so anyone interested could see how they were written (in C), could modify them (again in C using Digital C or porting them to C68), and/or use them. I will likely create a GitHub project for the BASIC since I have plans for the ZX81 Simulator -- stay tuned

[bwinkel67]

...maybe I should reach out to Dilwyn to get these put on his site...

[dilwyn]

I haven't been following this thread, but yes, by all means - all I need is a zipped file and a short description for the website.