Denial

Hello all,

Anybody ever witnessed a "?FORMULA TOO COMPLEX" error from a CBM Basic V2.0 program (that is, without any extensions or ML additions).
To my opinion, this error can never occur. Can you think of a program (line) that proves otherwise ?

Regards,


Wim.

wimoos wrote:Anybody ever witnessed a "?FORMULA TOO COMPLEX" error from a CBM Basic V2.0 program (that is, without any extensions or ML additions). To my opinion, this error can never occur. Can you think of a program (line) that proves otherwise ?

The stack for string expressions is only 3 strings deep. 1 PRINT "A"+("B"+("C"+"D")) throws a ?FORMULA TOO COMPLEX error, whereas 1 PRINT "A"+("B"+"C") doesn't.

The stack for string expressions is only 3 strings deep. 1 PRINT "A"+("B"+("C"+"D")) throws a ?FORMULA TOO COMPLEX error, whereas 1 PRINT "A"+("B"+"C") doesn't.

Hmmm....who would ever use brackets in combination with string concatenation: there is no automatic hierarchy in this that needs to be overruled. Moreover, the formula isn't really complex, is it ?

But this gave me the idea that the use of LEFT$/MID$/RIGHT$/CHR$/STR$ functions lead to similar effects. For example will produce a ?FORMULA TOO COMPLEX error as well.

Now comes the question: why a stack of only three strings deep ? Of course limited by Zp location, but they must have thought a minimal of three required. What is the thought behind that ?

wimoos wrote:why a stack of only three strings deep? [...] What is the thought behind that?

That setup is probably sufficient for most non-trivial string expressions. For example, even something like

A$=LEFT$(LEFT$(A$,M-1)+LEFT$(B$,N)+MID$(A$,M+LEN(LEFT$(B$,N))),LEN(A$))

works and gives the same result as the left-MID$() assignment in BASIC V3.5/V7 and WimBasic:

MID$(A$,M,N)=B$

Hmm...good example, thank you for that.

Now I compared the vanilla Basic formula with the Left-MID$ WimBasic implementation. I compared them on usage of strings scrap space and on the usage of the temporary descriptor stack.

The vanilla implementation uses more scrap space than the WimBasic equivalent.
Also, vanilla uses two entries on the descriptor stack, while the WimBasic implementation uses only one entry on the stack.

Chances are that vanilla runs into a garbage collection quicker and into a FORMULA TOO COMPLEX quicker when more elaborate strings are used.

That's fair enough. Just two things I'd like to point out:

1. Ideally, an implementation of "MID$()=" shouldn't need any more temporary stack space than necessary for the RHS expression. The exchange of the string content LHS can operate in-place.

2. GC, as bad as it's implemented in BASIC V2, only becomes relevant with a 3-digit number of "active" strings, where it then can take a noticable couple of seconds, lots of minutes, even going into one to two hours. Yet this didn't keep me from using a high two-digit number of strings - in the game VICtoria Gold - to store shape definitions of the provinces for the graphic map. When a GC occurs there, it only takes ~1/2 second.

For applications that require to handle an even higher number of strings, support by machine language routines is probably the best bet: that's the route I went with the formatting process of MG Browse. If I had stored each text line into a separate BASIC string, GC would have become unbearable pretty soon.

... http://sleepingelephant.com/ipw-web/bul ... 9&start=88 ...

On a side note, Mike that game you point out ( VICtoria Gold), isn't available for download anymore the links are broken. I for one would like to try it, it looks like a cool game.

Norm

Thank you for the hint - here's a working link:

https://dateipfa.de/.Public/denial/games/victoria.zip

I'll also repair the link in the OP and the announcement thread.

Thx

Not relevant in real use, but some V2 bugs may provoke a string descriptor stack overflow leading to a ?FORMULA TOO COMPLEX error.

PRINT POS("")
PRINT POS("")
PRINT POS("")

Throws the error on the 3rd one. In contrast to POS() FRE() doesn't test the dummy argument type also, but a proper argument cleanup will be done.

However, this could be used to artificially shorten the string descriptor stack (for experimenting with the interpreter) because each POS("") occupies one stack element. As far as I know this remains permanent until a CLR or RUN. Further usage of expression evaluation does not recognize the useless stack descriptor entry.

As far as I know this remains permanent until a CLR or RUN.

This is correct. Additionally NEW, and non-immediate LOAD, do this. Also the routine that prints "ERROR" whenever an error occurs does a call to $C67A where the string descriptor stackpointer is reset.

In WimBasic, I have done some maintenance on PRINT USING. This, and the POS("") bug, now makes that results in a ?FORMULA TOO COMPLEX straight away. Where works properly.

Regards,

Wim.

A similar bug as in POS(""), is in IF.
results in ?FORMULA TOO COMPLEX at line 40.

No one would ever be tempted to code this, but the handling is wrong. There should be a ?TYPE MISMATCH at line 10.

Regards,

Wim.

wimoos wrote:A similar bug as in POS(""), is in IF.
[..]
No one would ever be tempted to code this, but the handling is wrong. There should be a ?TYPE MISMATCH at line 10.

More curiosities regarding IF can be found in the german C64-Wiki (the english version isn't up-to-date).