Project

General

Profile

Bug #1574

ApproxSolveTF

Added by John Abbott about 3 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
bug
Target version:
Start date:
03 Feb 2021
Due date:
% Done:

0%

Estimated time:
Spent time:

Description

ApproxSolveTF is not documented. Maybe that is a good thing...

use QQ[x,y,z];

D := 7;
N := 2^17;
L := [z^D - (N*z-1)^2, y*(z-1/N)-1, x^D - (y^2*x-1)^2];
Pts := ApproxSolveTF(L);
 indent([[ FloatStr(coord) | coord in pt] | pt in Pts]);
[
  ["0.0000",  "0.0000",  "0.0000"],
  ["0.0000",  "0.0000",  "0.0000"],
  ["0.0000",  "0.0000",  "0.0000"],
  ["0.0000",  "0.0000",  "0.0000"],
  ["0.99998",  "0.0089742",  "111.43"],
  ["0.0000",  "0.0000",  "0.0000"],
  ["0.0000",  "0.0000",  "0.0000"]
]

I'm not quite sure what happened there. ApproxSolve can handle this (if I increase the internal precision enough): it finds these solutions:

[
  ["8.7581*10^(-47)",  "-1.0685*10^23",  "0.0000076294"],
  ["8.7581*10^(-47)",  "-1.0685*10^23",  "0.0000076294"],
  ["8.7581*10^(-47)",  "1.0685*10^23",  "0.0000076294"],
  ["8.7581*10^(-47)",  "1.0685*10^23",  "0.0000076294"],
  ["0.99998",  "0.0089742",  "111.43"],
  ["2.6487*10^18",  "1.0685*10^23",  "0.0000076294"],
  ["2.6487*10^18",  "-1.0685*10^23",  "0.0000076294"]
]


Related issues

Related to CoCoA-5 - Bug #1216: RationalSolve: gives wrong answerClosed2018-08-07

Related to CoCoA-5 - Bug #1573: ApproxSolve: very impreciseClosed2021-01-30

History

#1 Updated by John Abbott about 3 years ago

I have set the target version as 5.3.6, but maybe it could be postponed?

It is a bit strange that the solution [0,0,0] appears several times. Not sure what that means.

Maybe these fns (ApproxSolve and ApproxSolveTF) should automatically check that the solutions looks "plausible" but substituting into the orig polys, and verifying that the values obtained are reasonably small (whatever that might mean).

#2 Updated by John Abbott about 3 years ago

  • Description updated (diff)

#3 Updated by John Abbott about 3 years ago

  • Related to Bug #1216: RationalSolve: gives wrong answer added

#4 Updated by John Abbott about 3 years ago

The code seems to be a bit convoluted. It'll take time to work out what it is supposed to be doing... not today!

#5 Updated by John Abbott over 2 years ago

  • Related to Bug #1573: ApproxSolve: very imprecise added

#6 Updated by John Abbott over 2 years ago

Probably ApproxSolveTF should have an accuracy-check-loop the same was as was done for ApproxSolve:
the heuristic is that the final value of each poly should be at most 10^(-6) times that max value of a term in the poly (so that heuristically there is "good cancellation").

Of course, if you think of a better heuristic, let us know!

Also available in: Atom PDF