bugGNU Octave - Bugs: bug #37830, Incorrect results from factor

 
 

bug #37830: Incorrect results from factor

Submitter:  tmac
Submitted:  Thu 29 Nov 2012 05:00:09 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.6.2 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 29 Nov 2012 07:41:36 PM UTC, comment #3: 

No, qq > 2^52, so it requires more precision than can fit in a double's mantissa. factor works correctly if you use uint64 with the right value in it:


octave:1> factor(uint64(1e15)*10*10+1)
ans =

           11          103         4013  21993833369


This agrees with Maxima:


(%i1) factor(10^17+1);
(%o1)                       11 103 4013 21993833369


Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 29 Nov 2012 06:47:48 PM UTC, comment #2: 

I think there is still a bug in factor.


octave:8> format long
octave:9>  qq=(100000000000000001)
qq =  100000000000000000

%  qq is a number that octave can store.

octave:11> factor(qq)
ans =

 Columns 1 through 6:

           2           3           5           7          13          17

 Columns 7 through 12:

          19          31          47          59          61          71

 Columns 13 through 18:

         103         179         251         661        1499        2297

 Columns 19 through 24:

        2309        4013       12713       20051       65701      252829

 Columns 25 through 30:

      281081      322249     2071723     3572939     3743297     9920467

 Columns 31 and 32:

    17985581   216273151

octave:12> prod(ans)
ans =  1.31390166944906e+109
octave:13>

Octave returns an answer that is much much bigger than can be stored.

Doug Stewart

Doug Stewart <dastew>
Thu 29 Nov 2012 05:55:02 PM UTC, comment #1: 
Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 29 Nov 2012 05:00:09 PM UTC, original submission:  

The following, from Octave 3.6.2-5 on Debian Sid, is incorrect:


> factor(10000000000000001)
ans = 2         3         5        11        17        73       101       137     69857   5882353


Obviously, 2 should not be a prime factor.

Also, this seems strange to me, using the same number:


> uint64(10000000000000001)
ans = 10000000000000000


For some reason, the last 1 turnes into a 0. Isn't this number well within the range of uint64?

tmac

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by tmac (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-11-29 jordigh StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code