SciCalc

Is there an original source here?

The source can be viewed here, if that’s any good.

I can send you a copy of the source files for reference if you don’t want to get it via CVS.

Why on earth, in this day and age, do we persist in the habit of distributing BASIC files in crunched (or whatever it’s called) form?

For the life of me I can’t see any benefit. I can see that it’s very undesirable. These applications should serve as good examples for people to learn from.

Think of the children…!

Why on earth, in this day and age, do we persist in the habit of distributing BASIC files in crunched form?

Well, there’s always going to be a speed advantage with any interpreted language like BASIC. The uncrunched form of SciCalc is the one you should be editing anyway, and that’s available via the usual channels.

Well, there’s always going to be a speed advantage with any interpreted language like BASIC. The uncrunched form of SciCalc is the one you should be editing anyway, and that’s available via the usual channels.

I would refer people doing this kind of thing to the current release of Antispam as a good model.¹
The download contains an uncompressed “source” and also the means of compressing it to replace the already compressed version also in the download.
So, end result: what you run by default is compressed, BUT you can edit the source and produce a new amended compressed version. Ticks both boxes.

¹ Dave H’s child, by brainbirth, and adopted out has grown up a fair bit.

That is the way I do things. !RunImages are translated ‘Basalt’ files and the Source directory contains the original code and an Obey file to do the translation.

The ROOL SciCalc !RunImage did not appear to be particularly crunched, just missing spaces between tokens. The earlier ROL version was truly crunched.

I think that with our new hardware there is going to be no noticeable gain from crunching most BASIC programs beyond what BASIC itself does, when Basic$Crunch is set. After all, most of the time is spent waiting for user input. ;-)

I do not think Chris is responsible, but SciCalc is not well written for speed anyway. The use of conditions with TRUE and FALSE stand out particularly, along with lengthy CASE structures. As I said, though, it really does not matter in that sort of program.

OK, I think I’ve solved the problem. The issue arises in PROCcalc_position. Internally, SciCalc uses the ‘*’ character for the multiplication operator, but in the summary bar it uses ‘×’ character for clarity. When calculating precedence, it was being passed ‘×’ but testing for ‘*’, meaning that multiplication got a precedence of zero, placing it before ^ (with a precedence of 1).

If this is right, then the current SciCalc should correctly handle:

pi + 7 ^ 2
pi – 7 ^ 2, etc.

Is that the case?

If this is the issue, then it’s a simple fix, and I’ll submit it to ROOL.

SciCalc is not well written for speed anyway. The use of conditions with TRUE and FALSE stand out particularly, along with lengthy CASE structures.

I think the long CASE structures were all there, but I may have introduced some of the TRUE/FALSE conditions. Out of interest, why are these particularly slow? Are there better alternatives?

A BASIC CASE structure requires the interpreter to move through the program, testing each WHEN condition in turn. If there are many lines between WHEN clauses, each has to be checked for WHEN as well. Thus an extended CASE structure is not at all speedy. There are some things to do to speed things up, and I have a note in my BASIC StrongHelp manual about this.

First, move all the code between WHEN clauses into procedures and call the procedures on the same line as the WHEN. Second, put the most likely WHEN conditions at the beginning of the CASE structure. Third, ensure that there are no spaces before WHEN clauses, which is most easily done by letting BASIC do CRUNCH %1111 by setting the Basic$Crunch system variable. Forth, do not nest CASE structures directly in a program. IF…ENDIF structures can suffer in the same way, but tend not be extended like CASE.

It may be worth noting that the quickest option for (nearly) sequential numeric choices is ON…PROC, but I am not really recommending that. ;)

A long while back, nemo and I had a bit of a discussion about pre-calculating CASE conditions to provide a hidden jump table. I think he did implement such a thing, and I have tried out some ways of doing it in Basalt, but neither is actually available.

As for TRUE/FALSE, there are many instances like:

condition%=FALSE
...
IF condition%=FALSE THEN ...

Whereas this is fine and faster:

IF condition% ELSE ...

Note that this is not the same as advocating the assumption of any non-zero value as TRUE.

There are some instances like, but a bit more complex than:

IF condition%=TRUE THEN ...
IF condition%=FALSE THEN ...

Which can be:

IF condition% THEN
 ...
ELSE
 ...
ENDIF

It is more a matter of style to me, but it slows a program in the same way that unnecessary () do. If speed is not critical, then they may well aid readability.

SciCalc is a program with no performance issues on an 8MHz ARM2 (its performance is limited by the speed of the user entering data), optimise for readability not speed.

Just to be clear, I said this of SciCalc above:

After all, most of the time is spent waiting for user input. ;-)

As I said, though, it really does not matter in that sort of program.

Which is part of an argument for not crunching BASIC programs, in general.

It is rare for speed to be so important that crunching a programme is of any help. SciCalc is an example of something that is not at all speed critical. No-one would notice if it ran at half or twice its present speed.

Readability is far more important in most cases.

Leave the original source alone. Distribute it. Don’t crunch it.

@Chris (121) said:

OK, I think I’ve solved the problem.

That’s great. But trying the contents of today’s “Beta HardDisc4” I find SciCalc 0.81, it still cannot get pi x 7 ^ 2 right (without brackets, my original observation). And 7 ^ 2 x pi gives a bizarre result! Another tweak needed?

This ROOL documentation page
https://www.riscosopen.org/wiki/documentation/show/Software%20information:%20SciCalc
says the stable version is 0.59, dating from the September 2009 corrections. Perhaps the page now needs an update from you?

BTW, should I have raised the bug also as a Ticket? Perhaps it should be listed there anyway for the record?

Sorry to have posed only questions!

I’ve emailed ROOL with a copy of the fix, but AFAIK it hasn’t made its way into the disc build yet. I just checked again on my copy here, and both pi x 7 ^ 2 and 7 ^2 x pi give the same result: 153.93804, so I think the issue has been resolved. It can take a little while for fixes to make their way into the system, as the ROOL team are ferociously busy and get a lot of emails.

So hopefully sorted soon!

Bernard: the change has been checked-in now, but might take a while to emerge in an updated HardDisc4. Keep an eye for updates, and try downloading the new version when one appears.

@Chris: Excellent! Sorry if I appeared at all impatient (with the update process rather than with any individual). I found the precedence problem only while drafting an updated version of the RISC OS 3.6 User Guide chapter describing SciCalc.

I don’t know that the app is widely popular, but it’s included in the distro, so at some point newcomers to RISC OS may welcome descriptions of its bundled apps, inclduing this one that you’ve improved over the months. Thank you for all your work.