issue-#124 Range-check for SHORT(ENTIER(real))

[Robert]

Code: Select all

ELSIF (x.class = Nmop) & (x.subcl = conv) & (DevCPT.Included(f, x.left.typ.form) OR DevCPT.Included(f, g)
        (*>>>*)&(x.left.typ.form # Real64) (*<<<*)) 

A couple of questions:
- A don't understand the workings of the compiler, but I guess this is equivalent to using ENTIER to convert a REAL to a LONGINT, then discarding any bits above 31, but keeping those below. That seems to be the case from the few experiments I have done. Is that correct?
- For REAL numbers that are in the range [MIN(INTEGER) .. MAX(INTEGER) + 1), where the existing code already returns the correct answer, is the new code slower or faster, bigger or smaller?


I still think that the inconsistency between doing "SHORT ENTIER" in 1 or 2 lines can be confusing, and can waste time trying to figure out why one's code is producing unexpected behaviour. Maybe the best solution is not to change the compiler, but to document these surprises, maybe in a new section of the Platform-Specific-Issues document? I would also consider recording other suprises, such as "33 IN {1} = TRUE", with a clear note that these are compiler, platform, and date specific, and not parts of the language to be relied upon.

[luowy]

according the language report
ENTIER(real-val) return LONGINT,
SHORT(longint-val) return INTEGER

so SHORT(ENTIER(real-val)) will return INTEGER;

the current BB compiler has a range-check for ENTIER(real), the real should can be round into a valid LONGINT.
otherwise will trap;but this is not documented.

the Robert's example let us known the expression SHORT(ENTIER(real)) has change the range-check from LONGINT to INTEGER,

IMO, it is a bad idea,it broken the ENTIER() defination,confuse user and harmful for code's rubost.

for expression SHORT(ENTIER(real)), the logic should be:
ENTIER(real) reutrn LONGINT, whith range-check (LONGINT );SHORT(longint) return INTEGER.

after fixup,the example code

Code: Select all

lonint:=ENTIRE(real);int:=SHORT(longint)

can be writen as

Code: Select all

int:=SHORT(ENTIER(real))

,simple ,efficient and rubost;

the BB framework has many SHORT(ENTIER()) expression,they are good test suites;

[Ivan Denisov]

I had prepared version for testing:
http://blackboxframework.org/unstable/i ... c1.627.zip

Diff:
http://redmine.blackboxframework.org/pr ... 3e1d01b11f

[Ivan Denisov]

I found that this fix is leading to hight increase of drawing speed.

There is an stack overflow trap in Fern example. And with a fix it appears much faster!

[DGDanforth]

I found that this fix is leading to hight increase of drawing speed.

There is an stackoversflow trap in Fern example. And with a fix it appears much faster!

fern.png

Do you mean the trap occurs sooner OR
the drawing of the Fern is faster with no trap?

[Ivan Denisov]

Now I am not sure... I can not reproduce the TRAP with 626 build version now...
http://blackboxframework.org/unstable/i ... c1.626.zip
We need another example for evaluate speed.

[Ivan Denisov]

I think, that this fix is leading to stack overflow somehow. Can someone check this too?

[Josef Templ]

The current behavior MUST NOT be changed at all!
Removing an existing runtime check is a severe change that can affect existing code in a subtle way.
This is not acceptable for a last-minute change.
It does not lead to more robust code but to less robust code.
It also may add additional instructions and thus is potentially slower than the existing solution.
It also takes away the fine grained control over the range checking behavior.
With the current solution it is possible to express both cases, with and without range check.
This is not possible any longer with the change unless you add explicit cumbersome range checking code.

As a compromise I can imagine to add a note about range checking in the language report
or in the system specific part.
This is in line with Robert's proposal.

- Josef

[Robert]

As a compromise I can imagine to add a note about range checking in the language report
or in the system specific part

I have made a first draft for this suggestions - comments please ...

[Josef Templ]

I cannot find any docu where the compiler options are defined.
Is there any?

Dev/Docu/Compiler says "The compiler has no compiler options.", which is certainly wrong.
Procedure DevCompiler.CompileList shows the full truth.

- Josef