issue-#59 IN function with SETs

User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: IN function with SETs

Post by Robert »

I have learned something from this discussion, and I suspect I am not the only one.

I originally asked: "Is

Code: Select all

k := 33;
RETURN k IN {1}
returning TRUE a bug?"
The answer is clear to me now: Yes. But the bug is not in the compiler, it is in my code. Since there is no compiler bug we do not want to do anything for release 1.7, and can concentrate on more important matters.

However it has been observed that my bug is not obvious unless you are familiar with the small print of the language report. Common sense is not enough, as my code would be ok in Oberon.
A small change to the compiler would enable the system (Compiler & run-time) to detect this error quickly. This is helpful, but is it desirable?

I think that help with finding non-obvious bugs is desirable. This is particularly true here as the non-deterministic nature of the code (it depends on global state not directly in the buggy statement) means that even exhaustive testing is inadequate. The test results might be satisfactory today, but not so tomorrow.

Chris says it is undesirable because the programmer looses the option to disable the checks. Why would she do that? - To use out of bounds k; I no longer sympathise with that. To use in bound k FAST; I totally sympathise with that. We do not have timing information so we don't know just strong this argument is.

In conclusion: I think we should not change the compiler for release 1.7, but I would not be surprised if in time this turns out to be unfinished business.
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: IN function with SETs

Post by Zinn »

The situation is not as bad as it looks like.
Someone should write a manual about tips & hints.
We have some cookbook writer specialists.

The module "TestInSet" do allchecks and traps
when you use
(!) "DevCompiler.CompileOpt('+')"
or
(!) DevCompiler.CompileThis TestInSet+

The module "TestInSet" does not do allchecks and run without trap
when you use
(!) "DevCompiler.Compile"
or
(!) DevCompiler.CompileThis TestInSet

It is right.
There is no need to do any change here now.
In the future we can discuss about changing the default settings.
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: IN function with SETs

Post by cfbsoftware »

Robert wrote: Common sense is not enough, as my code would be ok in Oberon.
Unfortunately my previous message on this subject here was misguided. The following code in ETH Oberon actually lists ALL the integers from 0 to 32766

Code: Select all

PROCEDURE Run*;
VAR 
  i: INTEGER;
BEGIN
FOR i := 0 TO MAX(INTEGER) - 1 DO
  IF i IN {0..31} THEN Out.Int(i, 6); Out.Ln END
END;
END Run;
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: IN function with SETs

Post by Robert »

cfbsoftware wrote: When using Oberon I sometimes find it convenient to write code like this:

Code: Select all

IF i IN {0..9} THEN ...
rather than

Code: Select all

IF (i >= 0) and (i <= 9) THEN ...
and would be disappointed if it didn't work or trapped on some values of i.
Well I'm not going to report this as a compiler bug on an Oberon forum!

Robert
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: IN function with SETs

Post by cfbsoftware »

Robert wrote:Chris says it is undesirable because the programmer looses the option to disable the checks. Why would she do that? - To use out of bounds k; I no longer sympathise with that. To use in bound k FAST; I totally sympathise with that. We do not have timing information so we don't know just strong this argument is.
I ran some timing checks on a program I wrote about ten years ago that uses an array of SETs to generate all the prime numbers in the first 256,000,000 integers. The data structure (a common pattern for dealing with sets with values > 31) is:

Code: Select all

CONST
  MaxPrimes = 256000000;

TYPE
  TPrimeArray = ARRAY (MaxPrimes DIV 32)+1 OF SET;
The code that counts the primes (nearly 14 million of them) is:

Code: Select all

  count := 0;
  FOR i := 1 TO MaxPrimes DO
    IF (i MOD 32) IN Primes[i DIV 32] THEN INC(count) END
  END;
Note that this code inherently has no need for range-checking as i MOD 32 is always going to be in range.

The time taken without range checks was 0.92 secs and with range checks was 1.36 secs running on a PC at 3.4GHz.

I then ported the code to Oberon running on an ARM Cortex-M4 microcontroller at 120MHz. The times were 56 secs without range checks and 69 secs with range checks.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: IN function with SETs

Post by Josef Templ »

Robert wrote: However it has been observed that my bug is not obvious unless you are familiar with the small print of the language report. Common sense is not enough, as my code would be ok in Oberon.
Your code is also not OK in Oberon.

- Josef
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#59 IN function with SETs

Post by Josef Templ »

My understanding is that we all now agree that there is no need to change anything in
our forthcoming 1.7 release. The topic may be reconsidered later (1.7.x, 1.8) in a broader context
which covers all possible optional runtime checks. So we can close the redmine issue and
remove the Github topic branch?

- Josef
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#59 IN function with SETs

Post by Robert »

I have had some private discussion with luowy. He has run Chris Burrows's example with the compiler generating out-of-range TRAPs. This caused a slow down of about 20%, which is worse that I would have guessed.

In my opinion this strengthens the conclusion that it is best to leave the compiler unchanged.
luowy
Posts: 234
Joined: Mon Oct 20, 2014 12:52 pm

Re: issue-#59 IN function with SETs

Post by luowy »

Josef Templ wrote:My understanding is that we all now agree that there is no need to change anything in
our forthcoming 1.7 release. The topic may be reconsidered later (1.7.x, 1.8) in a broader context
which covers all possible optional runtime checks. So we can close the redmine issue and
remove the Github topic branch?
I agree with you.We can leave this issue to a later.

luowy
OberonCore
Posts: 31
Joined: Tue Sep 17, 2013 10:30 am
Location: Russia, Orel
Contact:

Re: issue-#59 IN function with SETs

Post by OberonCore »

luowy wrote:We can leave this issue to a later.
luowy, can you try to implement 2n variant "k out of [0,31]: false" (http://forum.blackboxframework.org/view ... =252#p2255) codegeneration without jump (http://forum.oberoncore.ru/viewtopic.php?p=99348#p99348)?

Code: Select all

n IN s = (n <= 31) * (n MOD 32 IN s) s IS reg
MOV ECX, n
CMP ECX, 31
SETBE AL
(*MOV EDX, s *)
(*AND ECX, 31 *)
BT EDX, ECX (* CF = ECX MOD 32 IN EDX *)
SETB AH
AND AL, AH
MOVB result, AL

n IN s = (n <= 31) * (n MOD 32 IN s) s IS mem
MOV ECX, n
CMP ECX, 31
SETBE AL
AND ECX, 31
BT s, ECX
SETB AH
AND AL, AH
MOVB result, AL
Post Reply