Re: canon F-720i calc Hex




mensanator@xxxxxxxxxxx wrote:
FCS wrote:
Hi there,

After giving one calculator (Casio bought oct 2000) away
and leaving my solar cell SHARP (bought 2003 or 2004)
in a briefcase at a contract and it was never returned to
me, I thought it was time I got another one as it's round
that time I want to spend the evenings revising calculus
and statistics.

As it is I picked up the cheapest marked as suitable for
A/AS level maths from WHSMITH, a prominent stationer
and newsagent in the UK.

I've never had a canon before. Moore's law seems to be
holding strong for them on the surface of it but, working
through the manual I found what seems to me to be an
anomaly with the DEC-HEX-BIN-OCT function.

To be fair, the manual does state the DEC mode is used
only as conversion step for the other modes' values and,
as such, counsels against actually doing any calculations
in it.

I had found this prior to working through the relevant bit
in the manual, but as it features in the documentation,
which enables one to check the ROM is working right,
I thought I'd spell it out here and ask if anyone can see
why it should work like so.

The example given is DEF-EFE=FFFFFEF1

DEF (base 16) = 3567 (base 10)
EFE (base 16) = 3838 (base 10)

3567 - 3838 = -271

And, please note this is the arithmetic minus operator,
not the logical Negative or NOT or NOR function.

Now, 271 in HEX is 10F

And cycling FFFFFEF1 through the bases does give
the answer -271 in decimal mode, whether entered in
a hex form or produced as the result of a calculation.

Can anybody refer me to why it should be FFFFFEF1
and not -10F?

It seems that the ROM for this model calculates positive
numbers as having values from 0 -> 7FFFFFFF, which
translates as 0 -> 2147483647 in base 10, and then the
negative numbers run from FFFFFFFF -> 800000000,
which convert to -1 -> --2147483648 in decimal.

Now, OK, I've been around long enough to know that
even a £1 calculator from poundland has a tried and
tested ROM and accompanying documentation, even
if not all the keys work properly when it's in its case.

However, I've never come across this one before and,
having worked through the manual, I see no reason
for it at all. It's a ten digit display, plus exponent in
little letters, so what's the problem with using the
same floating minus sign as normally fits into a 10
digit display?

I'm also aware that people coming up to GCSE and
A/AS levels, and people entering education on the
various foundation and/or vocational courses in the
UK's Tertiary and Higher education sectors may not
have either the experience or insight around them to
pick up on this and, by writing answers down right
off the display window, may well get marked down
for it when in fact they've done naught wrong!

Part of the reason I'm picking it back up was the
realisation that the bit I kept getting "stuck" on in
relation to complex numbers in one of the texts I
have is, in fact, a quite widely known typographical
error in the answers that the macho culture of the
engineering education approach to date has not
seen fit to mark up more explicitly, in my experience,
than by allusion. they never tell you which answer
is wrong, in other words, just expect that mentioning
it in the introductory lecture will be sufficient for you
whenever it is that you get round to working through
that particular chapter.

Boy did I kick myself when I recalled that little nugget
from week one. I'd concluded I just didn't "get" them.
More so for not having a calculator handy at the time.

Still, at least I haven't yet redesigned the banana
in the face of openly offered peer-review.

Yet I did manage to ascertain that the average 1-2-3
compliant spreadsheet still lacks sufficient functions to
work completely through a foundation maths text first
written in the 1970s as late as the 2000 edition of it.

I shall be buying a more fully-featured calculator in
the near future and don't expect this one to see
too much use past the full A-Z of variables coming
in pretty handy in my rare trips to the bookmakers.

However, it seems that if you're willing to work round
what is to me an unconventional notation system
for negative values in its hexadecimal, octal and
binary modes, the Canon F-720i does do exactly
what it says on the tin.

What I'm interested in is anyone can point me in the
direction of any sources for why this notation convention
is used, either from the perspective of Canon ROMs,
or, if it's a widely used convention


This is the reply...

<http://en.wikipedia.org/wiki/Two's_complement>


This is my reply to the reply:

Well, OK, perhaps, so far as it goes. I did have twos-
complements in the back of my mind when I posted
but for some reason had them down as purely a binary
thing.

Wu, C. Thomas; An Introduction to Object Oriented
Programming with Java; McGraw-Hill International Edns;
Singapore, 1999; ISBN 0-256-25462-1

does cover the topic of twos complements (pp 124-128)
from the perspective of "how numbers are stored in a
[computor]". And, yes, for base2 the twos complement
model does appear on the surface to hold.

However, what is actually displayed are the both the 8s
and the 16s complements, even after cycling the returned
values through the decimal mode, which renders in a
standard +/- decimal representation without having to rely
on any 10s complements.

As such it doesn't really answer the question, and with
the caveat that unless I'm much mistaken wikipedia is
still at the teething stage and subject to overnight revision
and, as such, there's no guarantee that what's up there
now will be up there tomorrow; this is doubly true for the
stage of maturity wiki will have to reach before it is a
reliably citable source bearing in mind Moore's law and
archive retrieval remoteness over time.

Reasoning by analogy: I can enter 13:4 using its basic
notation for fractions. this is automatically changed to
3/1/4 and can then be flicked between 3.25 and 3/1/4.

These are, for what it's worth, all decimal.

Now, by way of using a different shift function, the original
entry of 13/4 can be recalled. However, despite the fact
that the calculation is done via the circuitry for base10
results - even in DHBO mode - the decimal values is then
never used as the basis for representing the Hex or Oct
values, despite it would seem no great shakes in terms
of the basic logical operations to then use the decimal
value as the basis for an integer-integer conversion from
any one base to another which then would stand as a
value, regardless of polarity (which can be reintroduced
later).

Seeing as the operations to convert the decimal value
to Hex or Oct are already there, that is, and the number
of "blocks" used to cycle between screens merely seem
to represent digit strings rather than being related to the
unit's usable volatile memory--as there is a 99-character
formula input buffer which is largely unused in this mode.

As such, despite being kind of in the area, not only does
your reference seem a somewhat macho approach (see
above) it also makes no effort to address the question I
eventually posed, i.e., what is it about the constraints of
this particular calculator ROM that makes the conversion
of a twos-complement into a polarised decimal a standard
operation but the polarising of a true Hexadecimal or Octal
value either not possible to, or not worth bothering to, program
in?

Please also observe that the notation convention used in
this particular model, whilst using a convention of F-->8
led 16s complement (i.e. led=leading character, which
can't be described as a bit as it's not base 2) while the
convention employed for the 8s complement uses a 3-->2
led display (again leading "bit", in terms of a BInary digiT
but not actually a "bit" as in binary it's 11-->10, and is
thus always at least 2 "bits".

So the question stands, why is it not worth making this
particular ROM more usable by way of an intuitive, polarised
conversion or integer numbers of bases other than 10?

Otherwise, thanks for the response.

Back to the end of the original post...

(as I should find out
soon), calculator ROMs generally as, in all fairness, it's
a new one on me and I don't see what's wrong with a
conventional minus operator that persists across blocks.

G Daeb

COPYRIGHT (C) 2006 SIPSTON
--

G Daeb

COPYRIGHT (C) 2006 SIPSTON
--

.



Relevant Pages

  • canon F-720i calc Hex
    ... After giving one calculator (Casio bought oct 2000) away ... It seems that the ROM for this model calculates positive ... if it's a widely used convention (as I should find out ...
    (sci.math)
  • Re: canon F-720i calc Hex
    ... After giving one calculator (Casio bought oct 2000) away ... It seems that the ROM for this model calculates positive ... direction of any sources for why this notation convention ...
    (sci.math)
  • Re: TRANSITION FROM HP48 TO HP50
    ... That's the original safety feature ("binary header," ... designed into the original HP48 series file transfer system, ... whereby any binary file not meant for the receiving calculator ... The first 20 bits of any 48/49/50 series object is a ROM address ...
    (comp.sys.hp48)
  • Re: Urgent: 50g anti-piracy by 5 June 2007
    ... Every calculator has a unique serial number in ROM. ... first time it could be run on any calculator but after it modifies itself, ... memory normally invisible to use (such as unused KOS memory or the ...
    (comp.sys.hp48)
  • Re: Calculator wrong
    ... "Phil Carmody" wrote in message ... Should a teacher accept that as the answer when a pupil insists on following ... the opposite convention ... >> any surprise that they threw RPN out the window on this calculator? ...
    (sci.math)