SciCalc can't do 32 bit hex

I think this is a bug.
I wanted to work out a memory area and it couldn’t do it. 0xBFFF FFFF – 0×4000 0000. The result was “number too small”
Of course I didn’t enter it like that. I just did it for readability on here.

Surely people use it when working things out when programming in RISC OS, right?

What result did you get? It’s suppose to be 0×7FFF FFFF, isn’t it?

Yeah, I’d say this is a bug. 0xbfffffff will get converted to a negative 32bit int, and then to a double-precision float. Subtracting 0×40000000 then pushes it outside the range of a 32bit signed int, so when displaying the result the conversion from double → int (ready for int → hex) fails.

Admittedly SciCalc’s Help file does say it supports signed 32bit hex (whereas you want unsigned), but if this was really true then it should use hex numbers in the range -0×80000000 to 0×7fffffff instead of 0×80000000 to 0×7fffffff.

Surely people use it when working things out when programming in RISC OS, right?

BASIC in a taskwindow is my go-to. SciCalc is just pathetic (what’s the point of using double-precision arithmetic if your input & output is limited to 9 digits?). I’m not a big fan of the builtin Windows & OS X equivalents either (e.g. “programmer” modes which are restricted to integers)

James, Yes 0×7FFF FFFF was the answer I should have seen. However the answer the calculator gave was literally “number too small”. I worked it out in my head after that instead of being lazy, and verified with a Casio calculator.

Interestingly gcalc in Linux does similar but spits out “inf” instead.

Jeffrey, that behaviour is just bizarre. I’m surprised that SciCalc doesn’t handle it or at least catch it with some bounds checking

I was bashing out a header with the base addresses and sizes for the H3 Cortex A7 memory map. The rest were straightforward, but I wanted to check I was right with RAM address space understandably. Can’t say I’ve ever broken a calculator on a computer before.

I’m not sure what Jeffrey means by using BASIC, but a standard large number doesn’t work
PRINT &FFFFFFFFFFFFFFFF/2
number to big.
I ported kalc and it recognised a default capability of 64 bits

set base hex
# FFFFFFFFFFFFFFFFh 2 /
# 7FFFFFFFFFFFFFFFh

I cross-compiled kalc with the linux line editor but I think the style of entry would work well in NettleSSH ANSI mode/with editor mode enabled. kalc uses RPN but that is minor compared to learning the other options, The useage is explained in the pdf quite clearly if you are patient. It has logic functions and shifts etc, didn’t notice anything for 2’s compliment stuff.

I’m not sure what Jeffrey means by using BASIC, but a standard large number doesn’t work
PRINT &FFFFFFFFFFFFFFFF/2
number to big.

Well, it’s not like that example works in SciCalc either :-) Clearly if you’re using BASIC then you’ll be restricted to the limits of BASIC. But the key thing is that BASIC/BASIC64 has fewer limits than SciCalc.

• BASIC will show your full history, SciCalc only shows one line (and older versions didn’t show any history at all)
• BASIC supports a practically unlimited number of variables for storing intermediate values, SciCalc only supports one
• BASIC allows you to write routines to generate sequences of numbers, SciCalc doesn’t
• BASIC can be fully controlled using just the keyboard (you can even easily launch it by using Ctrl-F12 to open a task window). With SciCalc you either have to do everything using the mouse (ugh) or constantly switch between keyboard & mouse whenever any advanced functions are required (disclaimer: I haven’t actually checked to see if keyboard shortcuts are available for all the buttons)

BASIC has its flaws, but it’s miles better than calculator apps that are designed to mimic the form and function of physical calculators.

BASIC has its flaws, but it’s miles better than calculator apps

+1

I think the only time I ever use SciCalc is when I want to see something expressed as a bitfield. Otherwise… PRINT <num> <op> <num> in a TaskWindow is far more flexible than any calculator app. Plus, if you’re doing a number of calculations, it’s a doddle to scroll back to see the entire chain of working out. A few in-line REMs can be useful to remember what specific values are.

So, yeah, BASIC FTW. :)

didn’t notice anything for 2’s compliment stuff.

Kalc uses the neg operator for 2’s compliment of a number

> set base hex
> set wordsize 32
> # 7FFFFFFFh neg
> # 80000001h