#591 Wrong 2D table model output

[Pakon]

With the code in the file attached, out1 should be 0.9, but it was 0. The content in 'table.txt' is exactly what is provided in Ngspice 37 manual.

• table source
• number of columns (x)
  8
• number of rows (y)
  9
• x horizontal (column) address values (real numbers)
  -1 0 1 2 3 4 5 6
• y vertical (row) address values (real numbers)
  -0.6 0 0.6 1.2 1.8 2.4 3.0 3.6 4.2
• table with output data (horizontally addressed by x, vertically by y)
  1 0.9 0.8 0.7 0.6 0.5 0.4 0.3
  1 1 1 1 1 1 1 1
  1 1.2 1.4 1.6 1.8 2 2.2 2.4
  1 1.5 2 2.5 3 3.5 4 4.5
  1 2 3 4 5 6 7 8
  1 2.5 4 5.5 7 8.5 10 11.5
  1 3 5 7 9 11 13 15
  1 3.5 6 8.5 11 13.5 16 18.5
  1 4 7 10 13 16 19 22

---

Console output:
ngspice 1 -> op
Reducing trtol to 1 for xspice 'A' devices
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Reference value : 0.00000e+00
No. of Data Rows : 1
ngspice 2 -> print all
atab#branch_2_0 = 0.000000e+00
inx = 0.000000e+00
iny = -6.00000e-01
out1 = 0.000000e+00
v_inx#branch = 0.000000e+00
v_iny#branch = 0.000000e+00

---

Kind regards,
Pakon

[marcel hendrix]

I note (on-line) that the number "0.9" on the first line of the data is printed in
bold. This is translated to double stars (i.e. illegal characters) when you copy the text off the webpage instead out of the manual. In earlier NGSPICE manuals the example text is
correct.

-marcel

[marcel hendrix]

On 2022-06-30 19:13, Pakon wrote:
[..]

With the code in the file attached, out1 should be 0.9, but it was 0.
The content in 'table.txt' is exactly what is provided in Ngspice 37
manual.

---

• table source
• number of columns (x)
  8
• number of rows (y)
  9
• x horizontal (column) address values (real numbers)
  -1 0 1 2 3 4 5 6
• y vertical (row) address values (real numbers)
  -0.6 0 0.6 1.2 1.8 2.4 3.0 3.6 4.2
• table with output data (horizontally addressed by x, vertically by y)
  1 0.9 0.8 0.7 0.6 0.5 0.4 0.3
  ^^^^^^^ huh?
  [..]

---

Console output:
ngspice 1 -> op
Reducing trtol to 1 for xspice 'A' devices
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000

Reference value : 0.00000e+00
No. of Data Rows : 1
ngspice 2 -> print all
atab#branch_2_0 = 0.000000e+00
inx = 0.000000e+00
iny = -6.00000e-01
out1 = 0.000000e+00
v_inx#branch = 0.000000e+00
v_iny#branch = 0.000000e+00

---

When the 4 '*' characters are removed:
...
Using SPARSE 1.4 as Direct Linear Solver
[Operating point finding]
ngspice 210 -> print all
atab#branch_2_0 = -9.00000e-01
inx = 0.000000e+00
iny = -6.00000e-01
out1 = 9.000000e-01 <=== as wanted
v_inx#branch = 0.000000e+00
v_iny#branch = 0.000000e+00
ngspice 211 ->

-marcel

[Pakon]

Hello Marcel,

I've just found out that it was because of the following line in my file attached.
v_iny iny 0 -0.6
When -0.6 is within a pair of curly brackets as
v_iny iny 0 {-0.6}
The result of out1 is now as expected (9.000000e-01)

But,
v_iny iny 0 -0.59
and
v_iny iny 0 {-0.59}
the output is 9.016667e-01 with and without a pair of the brackets.

Is it possible that it is with a parser-related issue?

Thank you,
Pakon

[Giles Atkinson]

Interesting! When I tried, the problem was reproduced exactly as described. The table cut cleanly from the manual, except that it crosses a page boundary, leaving a heading to be removed. I tried adding "verbose=1" to the .model line, as that is mentioned in the manual:

ngspice 2646 -> op
Reducing trtol to 1 for xspice 'A' devices
Doing analysis at TEMP = 27.000000 and TNOM = 27.000000


Instance: atab   Message: y value -0.6 exceeds table limits,
  please enlarge range of your table

Instance: atab   Message: y value -0.6 exceeds table limits,
  please enlarge range of your table

Instance: atab   Message: y value -0.6 exceeds table limits,
  please enlarge range of your table

Instance: atab   Message: y value -0.6 exceeds table limits,
  please enlarge range of your table

Instead, I reduced the input value sightly, and all is well:

ngspice 2649 -> print all
atab#branch_2_0 = -9.00002e-01
inx = 0.000000e+00
iny = -5.99990e-01
out1 = 9.000017e-01
v_inx#branch = 0.000000e+00
v_iny#branch = 0.000000e+00

So, rounding error, perhaps dependent on parser? My interpretation is that there is a bug here: the output should be a (reasonably obvious) continuous continuation for inputs outside the defined region.

[Pakon]

Just to update that if I just add 0 and the end of -0.6, out1 is as expected.
v_iny iny 0 -0.60

It might be something with parsing the value, I guess.

[Pakon]

I found the root of the problem, which is pow(10.0,...);

When the exponent is a negative value, it affects calculations in some sections in the source code file 'inpeval.c' (and maybe other files that do the same calculation as well).

We can see from the following example.

// Need to include float.h and math.h

int digs = DECIMAL_DIG;

int main()
{
  int sign = -1;
  double mantis = 6;
  printf("-0.6 = %.*e\n",digs,-0.6);
  printf("-6*pow(10,0,-1) = %.*e\n",digs,-6*pow(10.0,-1));
  printf("-6/pow(10,0,1) = %.*e\n",digs,-6/pow(10.0,1));
  return 0;
}

---

output:

-0.6 = -5.999999999999999777955e-01
-6*pow(10,0,-1) = -6.000000000000000888178e-01
-6/pow(10,0,1) = -5.999999999999999777955e-01

---

So what I did was, at the end of INPevaluate function, modifying the return part with...

//----------------------------------
double return_val;
if (expo1 + expsgn * expo2 < 0){
   return_val = sign * mantis/pow(10.0,(double)-(expo1 + expsgn * expo2)); 
   //fprintf(stderr,"INPevaluate return : %.*e\n",my_digs_inpeval,return_val);  
   return(return_val);
    }
else {
   return_val = sign * mantis * pow(10.0,(double)(expo1 + expsgn * expo2)); 
   //fprintf(stderr,"INPevaluate return : %.*e\n", my_digs_inpeval, return_val); 
   return(return_val);
    }
//----------------------------------

And this solved the problem.

Pakon

[Pakon]

just a small correction:
my_digs_inpeval = digs

[Giles Atkinson]

Fixed by [240684]