Re: Is it a bug or my misunderstanding?

On Fri, 07 Aug 2009 09:53:03 -0500, Dima wrote:

There are some commands
which give results with decimal fractions ["real"]
while the calculator is in exact mode.

"Exact" mode primarily affects the original interpretation
(as "integer" vs. "real" object type)
of numeric strings typed on the keyboard without decimal points,
but usually does not affect the results of commands;
in particular, it does not cause all results to remain integers
(or fractions), which would be an impossibility for many operations.

For example, SIZE always returns "real" values,
but you can follow with an R\->I command
or perform R\->I(SIZE(ANS(1)))

[[ 1 5 ] [ 4 7 ] [ 6 0 ]] SIZE R\->I Ans: { 3 2 }

There isn't much point to doing this, however,
because almost any use for the result of SIZE
will convert it back to "real" :)

Some commands, particularly those which existed before any CAS,
when there was no such object type as an "integer,"
hence when the existing commands
could not handle any "integer" objects at all,
will automatically convert all "integer" arguments to real,
to enable the original commands to work in the new series,
without crashing.

That's what happens here:

[ 1 4 6 0 ] 5 4 COL+ Ans: [ 1 4 6 5. 0 ]

In this case, the "position" argument (4) is required to be real,
but in the automatic conversion of all "integer" arguments to "real,"
the element value argument (5) happens to also be converted to real.

You can perform ::R\->I MAP to change that result to [ 1 4 6 5 0 ]

On the other hand: [[ 1 4 6 0 ]] [5] 4 COL+ Ans: [[ 1 4 6 5 0 ]]

No adjustment is needed in this case, because the value argument
is not "integer" type, hence does not get automatically converted.

This has nothing to do with ALG vs. RPN modes of operation;
rather, it is the result of the evolution of the new series of calculators
from the original series, retaining compatibility as much as possible
with the original commands of the earlier series while adding new CAS commands,
and (most of the time) allowing "symbolic arrays" to be used interchangeably
with the original numeric-only arrays.

Occasionally this results in an unintended consequence,
such as those you have found, requiring a (usually easy) work-around.

[r->] [OFF]
.

Relevant Pages

  • Re: what about now? [ADD == --]
    ... You posted TWO programs which show COMMANDS REVERSED in one of them. ... Logic would suggest that both versions should not compile the same, ... calculator, then regardless of how the flag is set, the editor would ... and can even be used within algebraic objects, as also can -NEGin algebraics ...
    (comp.sys.hp48)
  • Re: Technology brief on extensions in MorphEngine
    ... case of one new calculator architecture, ... running on a new platform, to support some of UserRPL, ... and ENDSUB commands for DOSUBS, ... Australia would in fact be a lovely place to be right now, ...
    (comp.sys.hp48)
  • Re: floating-point arithmetics
    ... > simply would like to know what options or commands to use when I ... > For example how would I make the area calculator below work? ... > return $res ... echo "$res" ...
    (comp.unix.shell)
  • Re: Symbolic Calculator for Mobile Devices
    ... use one of the CAS-capable pocket calculators, ... Using Jasymca you don't need to learn many new commands. ... calculator ...
    (sci.math.symbolic)