A Little too random.

rdebath

RANDOMIZE(1134157108);
FOR I := 1 TO 50 DO BEGIN
  J := RANDOM(10);
  IF (J<1) OR (J>10) THEN
    ERROR('RANDOM(10) returned %1', J);
END;

---------------------------
Microsoft Dynamics NAV Classic
---------------------------
RANDOM(10) returned -8
---------------------------
OK   
---------------------------

Anybody code across this before? Got an explanation? I wonder if the RTC is compatible...

ara3n

It looks like a bug in classic.
And it's still in 2009 sp1 classic.

On RTC it works fine and you don't get the error.

FDickschat

Must be a bug. I've run it in 2009 SP1 Classic in a report 1.000.000 times and it only happens on run 48.

Any reason why you RANDOMIZE that number? Why don't you just use current datetime as the default does?

rdebath

FDickschat wrote:

Any reason why you RANDOMIZE that number? Why don't you just use current datetime as the default does?

Because it was the first positive one that popped out of my test report; the one below that bombs out in less than a second nearly every run.

As for the RTC; the good thing is that it seems to give values in the right range; bad thing it that for a given value the sequence returned is different from the classic client. But as Navision isn't really used for simulation this shouldn't be a problem.

I suppose I should raise it with Microsoft.

OBJECT Report 76000 Random test
{
  OBJECT-PROPERTIES
  {
    Date=12/02/10;
    Time=17:19:11;
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    ProcessingOnly=Yes;
    OnPreReport=BEGIN
                  Window.OPEN('Seed  #1######');

                  WHILE TRUE DO BEGIN
                    InitRANDOM();
                    Window.UPDATE(1,Seed);
                    FOR I := 1 TO 10000 DO BEGIN
                      J := RANDOM(10000);
                      IF (J<1) OR (J>10000) THEN
                        ERROR('Got %1 with seed %2', J, Seed);
                    END;
                  END;

                  Window.CLOSE;
                END;

  }
  DATAITEMS
  {
  }
  REQUESTFORM
  {
    PROPERTIES
    {
      Width=9020;
      Height=3410;
    }
    CONTROLS
    {
    }
  }
  CODE
  {
    VAR
      Window@1000000000 : Dialog;
      Seed@1000000001 : Integer;
      I@1000000002 : Integer;
      J@1000000003 : Integer;
      K@1000000004 : Integer;

    PROCEDURE InitRANDOM@1000000013();
    VAR
      Str@1000000000 : Code[8];
      I@1000000001 : Integer;
      IntVal@1000000002 : Integer;
    BEGIN
      Str := COPYSTR(FORMAT(CREATEGUID), 2, 8);
      FOR I := 1 TO STRLEN(Str) DO BEGIN
        IF IntVal < 134217728 THEN
          IntVal *= 16 ELSE
          IntVal := (IntVal - 134217728) * 16 - 1 - 2147483647;
        IntVal := IntVal + ((Str[I]-48) - 7 * (Str[I] DIV 64));
      END;
      Seed := IntVal;
      RANDOMIZE(IntVal);
    END;

    BEGIN
    END.
  }
}

ara3n

you could add j := ABS(j) to get the same result.

matttrax

ara3n wrote:

you could add j := ABS(j) to get the same result.

True, but should probably still be told to Microsoft. Can't imagine it would be anything but a low priority bug fix, though.

ara3n

right I just suggested that as a workaround.

rdebath

ara3n wrote:

you could add j := ABS(j) to get the same result.

Ahh, no. ABS(0) is still zero, and yes the function sometimes returns zero too.

ara3n

ok so if it returns 0 change it to 1.


j := ABS(j)

if J = 0 then j = 1;

anyways I hope you've reported it to MS.

rdebath

ara3n wrote:

anyways I hope you've reported it to MS.

Tell the truth I'm still annoyed about the ***p^W messing about with a bug report that I gave up on last month. Basically it came down to a "won't fix" resolution despite other parts of Microsoft agreeing with me that it was a bug. Now there's nothing inherently wrong with the "won't fix" resolution, however, they then decided to charge support call 9572935 as ", as an error has not been identified."

It didn't 'cost' us anything as the "bundled 20 support incidents" were already written off but it's still really stupid.

Say, as they seem to love the "bombarded with legalese" technique would you have a page or two of capslocked verbiage that tells then to ***k off rather than 'charge' something?

Or, maybe, thought I doubt it, they've actually got a bug reporting system now buried somewhere on their MSIE site.

BTW: I've switched to using a good quality PRNG called "Multiply with carry", it's a minor change on the normal linear congruential generators that I always thought looked like a good idea but never had the maths to even try to prove.