CAS: log of large integers?

[Joe Horn]

The HP 50g nicely returns 777 if you do 777 ALOG LOG in exact mode, even though 10^777 is larger than the 50g's MAXREAL. But Prime returns +Inf for log10(10^777), even though 10^777 is an exact integer. Apparently Prime first tries to convert the argument to a real, which in this case immediately overflows.

Question: How can Prime be programmed to return the approximate common log of exact integers which are greater than CAS's MAXREAL? The program should work on any large integer, even square-free integers (even the 50g has trouble with those).

[parisse]

There is indeed a Prime special code slice that convert to float if possible the argument of log10. I don't remember why, but there is certainly a reason otherwise the code slice would not be there.

[Wes Loewer]

(05-21-2015 11:28 AM)parisse Wrote:  I don't remember why, but there is certainly a reason otherwise the code slice would not be there.

This made me smile --- I often have the same thought when I look back at code I've written. :-)

[Tim Wessman]

(05-21-2015 11:28 AM)parisse Wrote:  There is indeed a Prime special code slice that convert to float if possible the argument of log10. I don't remember why, but there is certainly a reason otherwise the code slice would not be there.

I'm guessing left from the first version of the 39gII...

[Thomas_Sch]

(05-21-2015 04:40 PM)Tim Wessman Wrote:  

(05-21-2015 11:28 AM)parisse Wrote:  There is indeed a Prime special code slice that convert to float if possible the argument of log10. I don't remember why, but there is certainly a reason otherwise the code slice would not be there.

I'm guessing left from the first version of the 39gII...

Does that mean this 'special code slice' could be removed for the Prime?

[Gerald H]

(05-21-2015 06:37 AM)Joe Horn Wrote:  The HP 50g nicely returns 777 if you do 777 ALOG LOG in exact mode, even though 10^777 is larger than the 50g's MAXREAL. But Prime returns +Inf for log10(10^777), even though 10^777 is an exact integer. Apparently Prime first tries to convert the argument to a real, which in this case immediately overflows.

Question: How can Prime be programmed to return the approximate common log of exact integers which are greater than CAS's MAXREAL? The program should work on any large integer, even square-free integers (even the 50g has trouble with those).

I'm sorry none of the members on the Prime side have tried to answer your question - perhaps they're too busy enjoying the new features & trying to find out how the machine actually works to bother with a fiddly number programming problem.

You did however prompt me to (try to) deal with the matter on the 50G, so thanks for the stimulus.

[Thomas_Sch]

(05-22-2015 04:57 PM)Gerald H Wrote:  ...
I'm sorry none of the members on the Prime side have tried to answer your question - perhaps they're too busy enjoying the new features & trying to find out how the machine actually works to bother with a fiddly number programming problem.
...

Parisse and Tim answered, and maybe they could remove the 'Prime special code slice', parisse mentioned.

[Gerald H]

(05-22-2015 05:28 PM)Thomas_Sch Wrote:  

(05-22-2015 04:57 PM)Gerald H Wrote:  ...
I'm sorry none of the members on the Prime side have tried to answer your question - perhaps they're too busy enjoying the new features & trying to find out how the machine actually works to bother with a fiddly number programming problem.
...

Parisse and Tim answered, and maybe they could remove the 'Prime special code slice', parisse mentioned.

Yes, I noticed the reference to a "code slice" but don't understand - Does this mean the solution to the question "How can Prime be programmed to return the approximate common log of exact integers which are greater than CAS's MAXREAL?" is present in the Prime & the only problem is the matter of accessing the command?

Again, you mention/suggest the removal of this "code slice" - Does this mean making the command available or the erasure of the programme parts involved?

[Thomas_Sch]

(05-22-2015 05:57 PM)Gerald H Wrote:  

(05-22-2015 05:28 PM)Thomas_Sch Wrote:  Parisse and Tim answered, and maybe they could remove the 'Prime special code slice', parisse mentioned.

Yes, I noticed the reference to a "code slice" but don't understand - Does this mean the solution to the question "How can Prime be programmed to return the approximate common log of exact integers which are greater than CAS's MAXREAL?" is present in the Prime & the only problem is the matter of accessing the command?

Again, you mention/suggest the removal of this "code slice" - Does this mean making the command available or the erasure of the programme parts involved?

Sorry, but this could & should (only?) be answered by Tim and/or Parisse.

I dont't know the code, but the post from Parisse suggests, that there seems to be a bit of code, which leeds to the effect Joe has determined.

Hopefully they are reading this thread again.

[parisse]

It's in usual.cc, line 497

Code:


  ...
    gen a,b;
    if (abs_calc_mode(contextptr)==38 && has_evalf(e,a,1,contextptr))
      return log10(a,contextptr);
    if (is_algebraic_program(e,a,b))
      return symbolic(at_program,gen(makevecteur(a,0,log10(b,contextptr)),_SEQ__VECT));
  ...

calc_mode returns 38 inside the hp39gii and -38 inside a Prime (and 1 inside geogebra). You can check inside Xcas, by running calc_mode(38) or calc_mode(-38) instead of calc_mode(0). calc_mode is not available on the Prime.

[Thomas_Sch]

(05-22-2015 07:01 PM)parisse Wrote:  It's in usual.cc, line 497

Code:


  ...
    gen a,b;
    if (abs_calc_mode(contextptr)==38 && has_evalf(e,a,1,contextptr))
      return log10(a,contextptr);
    if (is_algebraic_program(e,a,b))
      return symbolic(at_program,gen(makevecteur(a,0,log10(b,contextptr)),_SEQ__VECT));
  ...

calc_mode returns 38 inside the hp39gii and -38 inside a Prime (and 1 inside geogebra). You can check inside Xcas, by running calc_mode(38) or calc_mode(-38) instead of calc_mode(0). calc_mode is not available on the Prime.

I don't understand this above,
calc_mode does something return - but calc_mode is not available ?

And how does this help Joe's question ?

[Gerald H]

Exactly my point Thomas: No one seems interested in the PROGRAMMING problem that prompted this thread.

[Thomas_Sch]

"never give up, always ask sustainably"

[DrD]

(05-23-2015 01:47 PM)Gerald H Wrote:  Exactly my point Thomas: No one seems interested in the PROGRAMMING problem that prompted this thread.

What exactly is an exact integer? A whole number, positive, negative or 0? A number without fraction? Then are -1.0, 0.0, or 1.0 exact integers, or are they inexact integers?

One way to solve Joe's problem, is to use multi-precision processing ... parallel as many Prime calculators as needed.

[kharpster]

Unfortunately after playing around, at this point I cannot answer Joe's question, but I did determine the following:

Home Mode (default settings) "Limits" example:

log10(10^308) = 308
log10(10^309) = inf

LOG(ALOG(500)) = 500
LOG(ALOG(501)) = 500


CAS Mode (default settings) "Limits" example:

log10(10^307) = 307
log10(10^308) = inf

LOG(ALOG(308)) = 308
LOG(ALOG(309)) = inf

[Joe Horn]

(05-23-2015 06:23 PM)DrD Wrote:  What exactly is an exact integer?

It's a specific object type in the Prime and HP 49/50 series calculators, namely, an integer whose number of digits is limited only by available memory. For example, if you do 2^63 on the HP 49/50 in exact mode, or on the Prime in CAS view (with its Exact mode set), you get the exact integer result of 9223372036854775808. If you perform the same calculation on the 49/50 in approximate mode, or on the Prime in Home view, you only get the approximate answer of 9.22337203685ᴇ18 which shows how standard HP reals have mantissas with at most 12 digits.

(05-23-2015 06:23 PM)DrD Wrote:  A whole number, positive, negative or 0? A number without fraction? Then are -1.0, 0.0, or 1.0 exact integers, or are they inexact integers?

They CAN be integers, but they are not necessarily. The dead giveaway is the absence of a decimal point in CAS (or on the HP 49/59 in exact mode). If you add 1+2 and get "3" (no decimal point) then it's an integer, but if you get "3." then it's a real, not an integer.

Prolepsis: Yes, of COURSE it's mathematically an integer. But that's not what we're talking about. We're talking about calculator object types here, not mathematical entities. Sorry if that was unclear.

[DrD]

(05-24-2015 02:01 AM)Joe Horn Wrote:  

(05-23-2015 06:23 PM)DrD Wrote:  What exactly is an exact integer?

(05-23-2015 06:23 PM)DrD Wrote:  A whole number, positive, negative or 0? A number without fraction? Then are -1.0, 0.0, or 1.0 exact integers, or are they inexact integers?

Prolepsis: Yes, of COURSE it's mathematically an integer. But that's not what we're talking about. We're talking about calculator object types here, not mathematical entities. Sorry if that was unclear.

Touché! Just having a weird moment on an, otherwise, boring, grey, day! I'm older now, and somehow feel entitled to one, now and again.

Analepsis: Better: a book, beer, and brain break!

My first thoughts on this puzzler: divide large numbers and agregate the sum of their parts: simulating greater bit-width for multi-precision processing, and ... suddenly, it was nap time.

[Joe Horn]

Finally got it working, with Gerald's help.

"biglog", a CAS program.

Input: any positive integer (may be very large).
Output: its common log as a real, accurate to 12 significant places, even for tough inputs (see 3rd example below).

Examples:
biglog(2^7777) --> 2341.11027628 (large correct answer)
biglog(999999999884) --> 11.9999999999 (the correctly rounded answer)
biglog(999999999885) --> 12. (the correctly rounded answer)

#cas
biglog(d):=
BEGIN
LOCAL j,k;
IF type(d)<>DOM_INT THEN RETURN "Argument not integer" END;
d:=abs(d);
k:=string(d);
j:=expr(head(k)+"."+tail(k));
return size(k)-1+evalf(log10(j),13);
END;
#end

[kharpster]

Joe/Gerald,

I walked through the code and can see what you are doing, good work! But what I am having trouble with is how you knew to use DOM_INT, there is only one reference to a DOM_ value in the user guide and that is for DOM_STRING. Is there another document that identifies the DOM_ types? The internal help text for type() only shows it being compared to a numeric value and not to a system "constant" that represents that value...

[Joe Horn]

(05-24-2015 05:27 PM)kharpster Wrote:  Joe/Gerald,

I walked through the code and can see what you are doing, good work! But what I am having trouble with is how you knew to use DOM_INT, there is only one reference to a DOM_ value in the user guide and that is for DOM_STRING. Is there another document that identifies the DOM_ types? The internal help text for type() only shows it being compared to a numeric value and not to a system "constant" that represents that value...

No, I don't know of any complete list of object types. Just throw any object at the type command (be sure to spell it in lowercase!) to see the name of an object type, e.g. type(123) in CAS returns DOM_INT, whereas type(123.) returns DOM_FLOAT. Adding zero to any object type turns it into an integer, useful for comparisons. Some type names have aliases, e.g. you can use "integer" in programs instead of DOM_INT, and "integer" is displayed as DOM_INT in the history stack. All of the ones I know about are here (discovered by experimentation and peeking directly into the firmware):

DOM_int = 0
float --> DOM_FLOAT = 1
integer --> DOM_INT = 2
DOM_LONGFLOAT = 3
complex --> DOM_COMPLEX = 4
DOM_IDENT = 6
DOM_MATRIX --> DOM_LIST = 7
algebraic --> DOM_SYMBOLIC = 8
symbol = 8 (does not change to DOM_SYMBOLIC)
rational --> DOM_RAT = 10
DOM_STRING = 12
DOM_FUNC = 13

Anybody know what object types 5, 9, and 11 are? (N.B. I'm referring to the type command, not the TYPE command here.)

Arcane trivia: The firmware also refers to object types "double" and "DOM_SPECIALFLOAT" but I get the feeling that these are either not implemented or not supported.