math.h error

[sapnads]

hi,

I am trying to use sqrt() and log10() of math.h and it is giving me unexpected results. for instance i tried finding out what log10(temp) was and temp was initialized to 100. output that i got was 6720. temp is a double variable. any idea as to why this could happen? also, is there a stand-along log10() code that i could insert in my code so that i wont have to rely on math.h?

Thanks,

[PanGalactic]

Show the code.

[sapnads]

double alfa, step , test = 100.0;
  int counter = 0;

  int status = STILL_RUNNING ;

  int i,j,k;

  /* memory allocation */
  
  test = log10(test) ;

test here returns 6720

[PanGalactic]

You've got a bug elsewhere in your code that is screwing up your stack.

You can pretty much prove that by taking the code you just pasted and run that on its own.

[sapnads]

but there is no code before that. there is just defining of variables.

[sapnads]

this is the function call

 int pr_loqo(int n, int m, double c[], double h_x[], double a[], double b[],
	    double l[], double u[], double primal[], double dual[], 
	    int verb, double sigfig_max, int counter_max, 
	    double margin, double bound, int restart) 
{
  /* the knobs to be tuned ... */
  /* double margin = -0.95;	   we will go up to 95% of the
				   distance between old variables and zero */
  /* double bound = 10;		   preset value for the start. small
				   values give good initial
				   feasibility but may result in slow
				   convergence afterwards: we're too
				   close to zero */
  /* to be allocated */
  double *workspace;
  double *diag_h_x;
  double *h_y;
  double *c_x;
  double *c_y;
  double *h_dot_x;
  double *rho;
  double *nu;
  double *tau;
  double *sigma;
  double *gamma_z;
  double *gamma_s;  

  double *hat_nu;
  double *hat_tau;

  double *delta_x;
  double *delta_y;
  double *delta_s;
  double *delta_z;
  double *delta_g;
  double *delta_t;

  double *d;

  /* from the header - pointers into primal and dual */
  double *x;
  double *y;
  double *g;
  double *z;
  double *s;
  double *t;  

  /* auxiliary variables */
  double b_plus_1;
  double c_plus_1;

  double x_h_x;
  double primal_inf;
  double dual_inf;

  double sigfig;
  double primal_obj, dual_obj;
  double mu ; //test = 2,temp_test;
  double alfa, step , test = 100.0;
  int counter = 0;

  int status = STILL_RUNNING ;

  int i,j,k;

  /* memory allocation */
  //temp_test = sqroot(test) ;
  test = log10(test) ;

[PanGalactic]

And where do you check the value of test?

[sapnads]

right at line 68. that's where it returns 6720.0000. i've put a break point there to check for the value of test. i actually have the log10() line of code somewhere else in the code and i doubted it didn't work properly. hence i put a test code at line 68 to make sure. and it doesn't return the correct value. somewhere else in the code i tried calling sqrt() of math.h too which didn't return a correct valuei.e., for sqrt(2) it returned 10472.000. hence i put in my own code to take the square root and it worked fine. any idea what may be wrong?

[sapnads]

does anyone have any idea about this issue? i've tried resolving it but of no avail. i have tried writing a code to calculate the basic math operations but it requires high precision for some numbers in some functions. any idea if any log10 function implementation has been done anywhere. I am running a code for about 8000 loops to get the closest possible to the number desired with slight compromise of speed. i would prefer to use the math.h but it doesn't seem to work

[guestgulkan]

works for me.

I can't see math.h being wrong.

To prove once and for all - just make an absolute simple minimal program like this:
If this doesn't work - you have major problems - but I can't see it

#include <iostream>
#include <cmath> //or math.h whichever you prefer

#using namespace std;

int main()
{
    double test = 100.00;
    
     cout << log10(test);
}

[helios]

Let's see which one is more likely:
1. [A set of functions that implements ages-old mathematical knowledge and is used constantly around the world thousands of times each millisecond] giving results off by a considerable margin of error.
2. You screwing up.
Well, I don't know how experienced you are or what you're doing, but unless you can produce some really, really convincing evidence plus some way to duplicate those results, I'm gonna have to say #2.