issue-#59 IN function with SETs

Re: IN function with SETs

Postby Robert » Fri Jun 12, 2015 2:50 pm

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.
User avatar
Robert
 
Posts: 997
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: IN function with SETs

Postby Zinn » Sat Jun 13, 2015 6:21 am

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.
Zinn
 
Posts: 470
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main

Re: IN function with SETs

Postby cfbsoftware » Sat Jun 13, 2015 7:54 am

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;
cfbsoftware
 
Posts: 203
Joined: Wed Sep 18, 2013 10:06 pm

Re: IN function with SETs

Postby Robert » Sat Jun 13, 2015 10:48 am

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
User avatar
Robert
 
Posts: 997
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: IN function with SETs

Postby cfbsoftware » Sat Jun 13, 2015 2:26 pm

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.
cfbsoftware
 
Posts: 203
Joined: Wed Sep 18, 2013 10:06 pm

Re: IN function with SETs

Postby Josef Templ » Sun Jun 14, 2015 8:03 am

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: 2012
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#59 IN function with SETs

Postby Josef Templ » Fri Jun 19, 2015 7:48 am

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
Josef Templ
 
Posts: 2012
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#59 IN function with SETs

Postby Robert » Fri Jun 19, 2015 8:51 am

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.
User avatar
Robert
 
Posts: 997
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#59 IN function with SETs

Postby luowy » Fri Jun 19, 2015 1:20 pm

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
luowy
 
Posts: 207
Joined: Mon Oct 20, 2014 12:52 pm

Re: issue-#59 IN function with SETs

Postby OberonCore » Wed Nov 16, 2016 1:29 pm

luowy wrote:We can leave this issue to a later.
luowy, can you try to implement 2n variant "k out of [0,31]: false" (viewtopic.php?f=58&t=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
OberonCore
 
Posts: 31
Joined: Tue Sep 17, 2013 10:30 am
Location: Russia, Orel

PreviousNext

Return to Rejected (Bugs)

Who is online

Users browsing this forum: No registered users and 0 guests