SciCalc

I had a calculator that had an inverse button that was used before a function to reverse it. (But maybe have it as a configure option)

I think that’s fair enough on a physical calculator where they are trying to reduce expense by limiting the number of buttons, but on a virtual calculator this is not a problem: SciCalc doesn’t yet have too many buttons in my opinion.

Providing the buttons are grouped logically (see my earlier post) I think we’re OK as we are.

It might be nice, however, if Adjust did the inverse of the function even though a button for the inverse of the function also existed, a bit like being able to Adjust-click on scroll bar nudgers.

I think if someone were updating SciCalc, the way to go would be to offer two UIs (possible with a choices window to select the default, and a way to toggle between the two). The basic mode would just offer the basic arithmetical functions, one or two memories and would open immediately (as suggested) so it could be tied to the Calculator key on many enhanced keyboards.

The second mode would reproduce a scientific/graphic calculator with 4/5/6 line screen (I forget what my old Casio has) with extra buttons as needed).

This would accommodate both classes of user – the “financial” type user who is just adding columns of figures and adding/subtracting VAT etc, and the scientific/academtic user who is going beyond that.

Just wish I had the spare time to write such a beast!

There is a Scientific Calculator called !RUCalc by Rupert Thompson v 1.50 (28 Apr 1995) written in BASIC.

Updated by Alan Wrigley published by RISC User.
Looks very much like a hand held Calculator.
Probably in the ‘RISC User’ Nutshell CD.

I think if someone were updating SciCalc, the way to go would be to offer two UIs (possible with a choices window to select the default, and a way to toggle between the two).

Andrew – if you look back to Chris’s post in this thread on 9th June there is a little link, labelled “here”, which allows you to download what he’s been working on. I think you’ll be impressed.

Oops, sorry, serves me right for not keeping abreast of the full thread.

It certainly does look excellent – I couldn’t spot an “auto-open” calculator window feature, but I think that was discussed previously.

It might be worth a look at the DeskEdit built-in calculator for exapanding it to a 3rd view “programmer”. I have uploaded a screenshot to Link to image It offers some nice bit-wise features and can quickly translate between hex, binary and ascii characters etc. Since DeskEdit isn’t exactly popular, and this was quite a nice little feature of the editor, it might be worth merging into something else.

There’s a new version of Calc to test out here. Main changes are:

- Summary bar fixes added
- Base and Trig mode now set by radio buttons rather than dropdown menus
- Ctrl-S keypress to change views
- Calculator buttons layout altered
- Option in Choices to open the calculator window on startup
- Pasting text should work correctly now

Comments and bug reports welcome. As before, I don’t plan to add any more features, but happy to address any reported issues.

@Chris: I like the look and UI of the new version very much, particularly the new buttons for Base and Mode. Many thanks!

If I was being picky, could I suggest the Base & Mode buttons would be even better if…
(a) the two types were somehow visually different, so the Base/Mode split was more obvious.
(b) the ‘pressed’ variations were more obviously different from the ‘unpressed’, as they (unlike the rest of the buttons) are ‘pressed’ for a long time, and convey valuable status information which should be easy to see.

It is now my default calculator!

Strange bug:

Open calculator, switch to binary, enter “10”, switch to octal. Calculator displays “12” instead of 2.

10 from BIN to HEX displays as A.

Looks like it’s interpreting the binary values in decimal by mistake.

One I don’t follow: in decimal mode, enter 10. Click HEX, and it shows A, click DEC and it shows 10, click BIN and it shows zero! In fact going to BIN straight from HEX also gives a zero.

If I was being picky, could I suggest the Base & Mode buttons would be even better if…
(a) the two types were somehow visually different, so the Base/Mode split was more obvious.

I’ll have a go.

(b) the ‘pressed’ variations were more obviously different from the ‘unpressed’, as they (unlike the rest of the buttons) are ‘pressed’ for a long time, and convey valuable status information which should be easy to see.

Yes, I know what you mean. I’ll tinker with the sprites a bit.

Strange bug

Gah. Something’s gone wrong there. Thanks – I’ll take a look.

There’s a new copy of Calc here. The base-change snafu should be fixed. I’ve also recoloured the Trig mode buttons to make them distinct from the Base ones, and made the ‘pressed’ ones a bit more obvious.

The sprites may not be perfect, but I don’t think I can face wrestling with Paint for much longer, so hopefully they’ll do. :)

I think v0.74 icons much better, thanks.

Would it be a good idea to have the Mode buttons in the order of Bin, Oct, Dec, Hex? This is (a) in ascending order so is logical, and (b) puts probably the most used ones (Dec and Hex) next to each other and nearer the centre.

Would it be a good idea to have the Mode buttons in the order of Bin, Oct, Dec, Hex?

I can see the logic in that, and did think about it, but I decided against it in the end for two reasons: (a) the Decimal mode is very different from the others in terms of the functions available, so it seemed sensible to separate that one out, and (b) that’s the order in which the bases used to be on the old SciCalc, which I thought might ease the transition from anyone who liked the old way of doing things.

I think my preference now would be not to change anything further in the app other than bug-fixes, and get it submitted to ROOL as-is. Once it’s got a slightly wider audience, I’m very happy to look at stuff like this again if there’s demand.

Any other views?

I’ve not yet had the chance to have a look but the above discussion has been logical and very informative.

I think my preference now would be not to change anything further in the app other than bug-fixes, and get it submitted to ROOL as-is.

I think that’s a very sensible idea.

v0.75 is great. I think that having the help link being available from both menus is a good move. The choices are a good idea and the Edit → Copy summary displays OK. With the functionality covering both standard and scientific, is it still appropriate for the app’s Purpose to state “Scientific Calculator” (when the main window is simply titled “Calculator” in both modes)? The help file looks good but I’ve not read it all yet.

And the summary window is great. If ever the Raspberry Pi finds its way into primary schools (and interactive whiteboards), I can see this being very useful – but it might be worth considering:

• increasing the legibility of the summary window from a distance (can someone please try it out on the big screen at the London Show, if not before?), e.g. white bg, smaller font / grey bg, bold font / other ideas?
• particularly in standard mode, the summary can become truncated – a possible workaround would be to have the summary display in an (optional) window of its own. This could be resizable and could also (potentially) show the entire history (preferably with a reset history facility)… and even possibly allow the saving of its contents. (All of this only if you think it’d be worth the effort, naturally.)

Anyway, I agree that it’s worth including as a replacement in the ROM in its present form, if the size is OK. In this case, perhaps both versions should be available for download from Desktop applications
(for the medium term) in order that a wider audience be able continue to compare/test functionality.

I have been using Calc v0.74 dated 13 Jul 2011 (and I have just found v0.75 dated 15 Jul 2011), and I thought it was proposed that it be added to the disc image to replace !SciCalc. Did this ever happen? If not, should it be done before the RPi build progresses any further?

If not, should it be done before the RPi build progresses any further?

Where is it on the web? I’ll add it (if licence permits). The development RISC OS 5 HardDisc4 tarball image currently still includes v0.61.

Calc v0.75 can be found here

Still only able to deal with 10 characters though :-(

Is this a massive job to rectify?

Only asking as I would love to be able to do a count on the RISC OS ROM and keep dividing by 1024 until it made sense to an audience when I am doing a demonstration of just how small the ROM is…

Still only able to deal with 10 characters though

What is the length of number you want to enter?
I suspect the trouble is that even using FP, you can only enter 10 significant digits. If the allowed length is increased so you can enter more, it would have to be converted to exponent form (ie 123456789E5) and the low-order digits would be lost without warning!

Could you enter it in exponent form?
When the result gets small enough it will be displayed as a normal decimal number.

Open a Task Window, start BASIC64, set @% appropriately and Bob’s your Uncle. RPi audiences would like that because it’s programming… ;)

My main question when I revived this thread still seems unanswered.

Why has !Calc v0.75 not replaced !Calc and !SciCalc in the HardDisc image? What needs to be done?

Why has !Calc v0.75 not replaced !Calc and !SciCalc in the HardDisc image? What needs to be done?

I have included Calc v0.75 in the Raspberry Pi proposed disc image alongside SciCalc. Someone else would have to do the necessary changes in the ‘vanilla’ HardDisc4 build which is the starting point.

I see that there have been some CVS changes today for SciCalc to v0.78.

I thought that the new !Calc was going to replace SciCalc? Has that happened or not?

Calc is a much more obvious name for new users than SciCalc!

Is there any reason to have an abreviated name anymore? Why not !Calculator?

Backwards compatability?