bugGNU Octave - Bugs: bug #64361, sinc() return NaN on...

 
 

bug #64361: sinc() return NaN on sinc(-1:0.20:1-0.20) expression

Submitter:  None
Submitted:  Wed 28 Jun 2023 07:52:39 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Patch Submitted Assigned to:  None
Originator Name:  Eugene Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 8.2.0
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 30 Jun 2023 01:16:58 AM UTC, comment #35: 


comment #34:

> Does the problem you see go away if you execute
>


> optimize_range (false);


>
> before executing the sinc test code?
>


Yes.


octave:1> optimize_range (false)
octave:2> sinc(-1:0.20:1-0.20)
ans =

   3.8982e-17   2.3387e-01   5.0455e-01   7.5683e-01   9.3549e-01   1.0000e+00   9.3549e-01   7.5683e-01   5.0455e-01   2.3387e-01

octave:3> optimize_range (true)
octave:4> sinc(-1:0.20:1-0.20)
ans =

   3.8982e-17   2.3387e-01   5.0455e-01   7.5683e-01   9.3549e-01          NaN   9.3549e-01   7.5683e-01   5.0455e-01   2.3387e-01


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 30 Jun 2023 01:07:54 AM UTC, comment #34: 

Does the problem you see go away if you execute


optimize_range (false);


before executing the sinc test code?

John W. Eaton <jwe>
Group administrator
Fri 30 Jun 2023 12:12:19 AM UTC, comment #33: 

At this time and more and more convinced that we should make rasnges into normal arrays. The fact that we currently have "arrays" which content is (slightly) different, depending how you "look" at it is very unsettling.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 11:54:29 PM UTC, comment #32: 

And it will probably occur on AMD chips that offer a vector math processor as well.  And every single processor will have a different way of disabling this vectorization so that the the use of _attribute_ will be inordinately complex.

It is very difficult to write high-level code when the same code (one multiplication, one addition) produces different results based on whether it is in a for loop or not.

Rik <rik5>
Group administrator
Thu 29 Jun 2023 11:23:21 PM UTC, comment #31: 

"This does seem like an annoying processor-specific bug."

As I mentioned before I can reproduce this behavior on aarch64
(raspberry Pi) if I compile with " -O2 -mcpu=native" that should enable Cortex-A72 vectorized math processor (https://developer.arm.com/Architectures/Neon).

I suspect there will be a similar issue on Apple M1/M2 chips.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 08:57:38 PM UTC, comment #30: 

Using _attribute_ ((target ("no-avx"))) does work.

Interestingly, it does so not by making the outcome of array_value() equal to an exact zero for element 6, but instead by having the test "x != 0" return false for the sixth element.  This removes it from consideration in the sinc function.

But, there is still a difference between the access functions in Range.h as this code shows

octave:2> [x](6)
ans = 5.551115123125783e-17
octave:3> x(6)
ans = 0
octave:4> x != 0
ans =

  1  1  1  1  1  0  1  1  1  1


So, using attributes would narrowly fix this particular bug report, but would not, it seems, have full consistency between the two approaches.

This does seem like an annoying processor-specific bug.

Rik <rik5>
Group administrator
Thu 29 Jun 2023 08:49:29 PM UTC, comment #29: 

That also raises the question of whether a different directive would be needed to disable AVX instructions with other compilers.

John W. Eaton <jwe>
Group administrator
Thu 29 Jun 2023 08:38:35 PM UTC, comment #28: 

Just confirming that this is all down to usage of AVX.  As Dmitri noted, compiler optimization levels which would not invoke auto-vectorization of loops (-O0, -O1) work.  Using the compilation directive '-mno-avx' also works.  The only difference between elem()/index() and array_value() is the presence of a for loop.  This page from Intel states under what conditions AVX can occur: https://www.intel.com/content/www/us/en/developer/articles/technical/requirements-for-vectorizable-loops.html.  The very simple loop in array_value() qualifies.

I will test out jwe's suggestion.

Rik <rik5>
Group administrator
Thu 29 Jun 2023 08:22:32 PM UTC, comment #27: 

I think I was going to say "If I understand correctly, that should disable the use of AVX instructions for the array_value function so the compiler shouldn't use them even if it finds an opportunity to do so."

John W. Eaton <jwe>
Group administrator
Thu 29 Jun 2023 08:20:24 PM UTC, comment #26: 

Rik:

I agree that we want all the ways of accessing or viewing range elements to produce the same results.  It seems that it should be as simple as using the same expression in the elem functions as we use in the loop in the array_value function, but as you show in comment #25, for some compiler optimization levels or code generation options, that's not always true.

What happens if you make the following change to the definition of the array_value function and still compile with the -march=x86-64-v3 option?


diff --git a/liboctave/array/Range.h b/liboctave/array/Range.h
--- a/liboctave/array/Range.h
+++ b/liboctave/array/Range.h
@@ -273,6 +273,7 @@ public:
     return array_value ().diag (k);
   }

+  __attribute__ ((target ("no-avx")))
   Array<T> array_value () const
   {
     octave_idx_type nel = numel ();


If I understand correctly

I'm not proposing this exact change as the attribute needs to be used only if the compiler accepts it.  I'm just curious to know whether it is a possible route to a solution for this bug.

We could also eliminate differences in the array_value/elem/display functions if we abandoned the size savings of the range<T> class, but then we could still have differences in behavior for different Octave builds due to different optimization or code generation options.

John W. Eaton <jwe>
Group administrator
Thu 29 Jun 2023 05:13:39 PM UTC, comment #25: 

Okay, with the specified compilation flags I can reproduce this behavior.

Minimal example is now


format longe
x = (-1:0.2:0.8)
x - 0


There is definitely a difference between the code that uses indexing (no for loop) and the code that uses looping (array_value).  Simplest way to see that is


x(6) == 0
ans = 1
[x](6) == 0
ans = 0


Besides elem() and array_value(), there is another function signature that accepts an index vector.


Array<T> index (const idx_vector& idx)


It has similar code to elem() and also behaves similarly as shown below.


x([5 6 7]) == 0
ans =

  0  1  0



Rik <rik5>
Group administrator
Thu 29 Jun 2023 04:52:06 PM UTC, comment #24: 

Oops. I realized now that the order in which I copied the output makes it look like I overwrote x with [x] before I calculated the difference. But that wasn't the case.

Also, when I wrote that `x(:)` or `[x]` are fine, I meant that they result in the same series of values than `x` for me...

Markus Mützel <mmuetzel>
Group administrator
Thu 29 Jun 2023 04:44:49 PM UTC, comment #23: 

I can reproduce on Windows with "-O2 -march=x86-64-v3". That's with GCC 13.1.0 on an AMD Ryzen 7 5800X if that should matter.
I'm seeing the precision issue when I compile like that. The range and the array have the same value though:

>> format longg
>> x = (-1:0.2:1-0.2)
x =

 Columns 1 through 6:

                      -1                    -0.8                    -0.6                    -0.4                    -0.2   5.551115123125783e-17

 Columns 7 through 10:

      0.2000000000000001      0.4000000000000001      0.6000000000000001                     0.8

>> x = [x]
x =

 Columns 1 through 6:

                      -1                    -0.8                    -0.6                    -0.4                    -0.2   5.551115123125783e-17

 Columns 7 through 10:

      0.2000000000000001      0.4000000000000001      0.6000000000000001                     0.8

>> x - [x]
ans =

 Columns 1 through 6:

                       0                       0                       0                       0                       0                       0

 Columns 7 through 10:

                       0                       0                       0                       0


The following might be interesting:

>> x = -1:0.2:1-0.2;
>> sin(x)./x
ans =

   0.8415   0.8967   0.9411   0.9735   0.9933   1.0000   0.9933   0.9735   0.9411   0.8967

>> sin(x(:))./x(:)
ans =

   0.8415
   0.8967
   0.9411
   0.9735
   0.9933
   1.0000
   0.9933
   0.9735
   0.9411
   0.8967

>> sin([x])./[x]
ans =

   0.8415   0.8967   0.9411   0.9735   0.9933   1.0000   0.9933   0.9735   0.9411   0.8967

>> sin(x(1:10))./x(1:10)
ans =

   0.8415   0.8967   0.9411   0.9735   0.9933      NaN   0.9933   0.9735   0.9411   0.8967

>> x - x(1:10)
ans =

 Columns 1 through 7:

            0            0            0  -5.5511e-17            0   5.5511e-17  -1.1102e-16

 Columns 8 through 10:

  -5.5511e-17            0            0


So, the result differs depending on whether I'm using indices or not. But `x(:)` or `[x]` is fine here...

I agree with you that this very much smells like the compiler using different instructions for something that we think should be equivalent.

Should we really mess with compiler optimizations and redesign our code because of that? Or should we just accept that using limited precision floating point numbers is tricky sometimes?
In the latter case, the patch from comment #3 could deal with that in the sinc function.

Markus Mützel <mmuetzel>
Group administrator
Thu 29 Jun 2023 04:43:44 PM UTC, comment #22: 

Hmmm, too bad the patch didn't work out.  I suggested it because I noticed that the code for elem() and array_value() was just slightly different.

In elem() the code is


m_base + T (i) * m_increment


while in array_value() it is


m_base + i * m_increment


In the first construct, the variable 'i' of type octave_idx_type is first converted to the end type (double) and the C++ compiler sees a "double" multiplying "double".  In array_value, the C++ compiler sees "long int" multiplying "double" and I thought the promotion rules might be doing something funny.

Even if this isn't the problem, it might be good to choose the same coding style for all of these functions.

I'm doing a full re-compile with Dmitri's suggested flags now.


Rik <rik5>
Group administrator
Thu 29 Jun 2023 09:10:52 AM UTC, comment #21: 

You have to set flags to "-O2 -march=x86-64-v3"
(it could be -march=native).

-O0, -O1 -- no problem
Also no problem if I add "-mno-avx"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 06:55:05 AM UTC, comment #20: 

"I can reproduce this problem with octave compiled with AVX/AVX2"

I tried building with CXXFLAGS="-g -O2 -mavx2" and I'm not able to reproduce the problem.

Exactly what options are you using to build Octave?

In any case, the funny thing is that at comment #18, the values shown for x = (-1:0.2:0.2) appear to be correct while the ones for [x] do not.  In the first case, the range is stored as a special class containing the base, limit, increment, final value, and number of elements.  The display of those values has a special case in pr-output.cc and the elements are displayed in this loop:


          while (col < num_elem)
            {
              octave_idx_type lim = (col + inc < num_elem ? col + inc
                                     : num_elem);

              pr_col_num_header (os, total_width, max_width, lim, col,
                                 extra_indent);

              os << std::setw (extra_indent) << "";

              for (octave_idx_type i = col; i < lim; i++)
                {
                  octave_quit ();

                  double val;
                  if (i == 0)
                    val = base;
                  else
                    val = base + i * increment;

                  if (i == num_elem - 1)
                    val = final_value;

                  os << "  ";

                  pr_float (os, fmt, val);
                }

              col += inc;
            }


For [x], an array of all the values is computed, stored in an NDArray object, and display is handled by the NDArray display method which just prints the elements of the array.  Computation of the elements is done in range<T>::array_value in Range.h:


        // E.g, -0 would otherwise become +0 in the loop (-0 + 0*increment).
        retval(0) = m_base;

        if (m_reverse)
          for (octave_idx_type i = 1; i < nel - 1; i++)
            retval.xelem (i) = m_base - i * m_increment;
        else
          for (octave_idx_type i = 1; i < nel - 1; i++)
            retval.xelem (i) = m_base + i * m_increment;

        retval.xelem (nel - 1) = final_value ();


I am able to observe values that look more like the reported problem if I make the following change to the loop in the octave_print_internal function for range<double> objects:


diff --git a/libinterp/corefcn/pr-output.cc b/libinterp/corefcn/pr-output.cc
--- a/libinterp/corefcn/pr-output.cc
+++ b/libinterp/corefcn/pr-output.cc
@@ -2554,6 +2554,7 @@ octave_print_internal (std::ostream& os,

           pr_scale_header (os, fmt.scale_factor ());

+          double val = 0.0;
           octave_idx_type col = 0;
           while (col < num_elem)
             {
@@ -2569,11 +2570,10 @@ octave_print_internal (std::ostream& os,
                 {
                   octave_quit ();

-                  double val;
                   if (i == 0)
                     val = base;
                   else
-                    val = base + i * increment;
+                    val += increment;

                   if (i == num_elem - 1)
                     val = final_value;


Then I see:


octave:1> format longg
octave:2> x = (-1:0.2:0.2)
x =

 Columns 1 through 6:

                      -1                    -0.8     -0.6000000000000001     -0.4000000000000001     -0.2000000000000001  -5.551115123125783e-17

 Column 7:

                     0.2


I'm compiling with -g -O2, not -mavx2, so maybe your compiler is "optimizing" the loop in array_value to do the same kind of incrementing instead of performing the multiplication that we asked for?

John W. Eaton <jwe>
Group administrator
Thu 29 Jun 2023 04:29:33 AM UTC, comment #19: 

I meant to say the patch did not make a difference.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 04:28:30 AM UTC, comment #18: 

Looks the same.

octave:2> format long
octave:3> x = (-1:0.2:0.2)
x =

   -1.000000000000000   -0.800000000000000   -0.600000000000000   -0.400000000000000   -0.200000000000000    0.000000000000000    0.200000000000000

octave:4> x = [x]
x =

 Columns 1 through 6:

  -1.000000000000000e+00  -8.000000000000000e-01  -6.000000000000000e-01  -4.000000000000000e-01  -2.000000000000000e-01   5.551115123125783e-17

 Column 7:

   2.000000000000000e-01

octave:5>


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 04:16:48 AM UTC, comment #17: 

This does seem like array_value() is probably producing a different result from elem().

Can you try the attached diff with 'patch -p1 < bug64631.diff' and see if the difference between x and [x] goes away?

(file #54895)

Rik <rik5>
Group administrator
Thu 29 Jun 2023 04:07:25 AM UTC, comment #16: 


octave:1> format long
octave:2> x = (-1:0.2:0.2)
x =

   -1.000000000000000   -0.800000000000000   -0.600000000000000   -0.400000000000000   -0.200000000000000    0.000000000000000    0.200000000000000

octave:3> y = (x != 0)
y =

  1  1  1  1  1  1  1

octave:4> x(6)
ans = 0
octave:5> x(6) != 0
ans = 0
octave:6> x(6) == 0
ans = 1


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 03:49:46 AM UTC, comment #15: 


octave:1> format long
octave:2> x = (-1:0.2:1-0.2)
x =

 Columns 1 through 7:

   -1.000000000000000   -0.800000000000000   -0.600000000000000   -0.400000000000000   -0.200000000000000    0.000000000000000    0.200000000000000

 Columns 8 through 10:

    0.400000000000000    0.600000000000000    0.800000000000000

octave:3> x = [x]
x =

 Columns 1 through 6:

  -1.000000000000000e+00  -8.000000000000000e-01  -6.000000000000000e-01  -4.000000000000000e-01  -2.000000000000000e-01   5.551115123125783e-17

 Columns 7 through 10:

   2.000000000000001e-01   4.000000000000001e-01   6.000000000000001e-01   8.000000000000000e-01


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 03:47:22 AM UTC, comment #14: 

I always suspected this is something to do with ranges, but I'm trying to pinpoint where.

Could you try this code:


format longe
x = (-1:0.2:1-0.2)


I'm trying to see whether the sixth element is really presented as 0 or as something small like 5e-17.

Next piece of code to execute


y = (x != 0)


The sixth element should be false, but probably isn't.

What this could mean is that range extraction for a single element is different then than for an index vector.  There are different routines in liboctave/array/Range.h for the two situations.

Rik <rik5>
Group administrator
Thu 29 Jun 2023 01:51:32 AM UTC, comment #13: 

So this is again a discrepancy between a range and an array.
I thought we had some discussion about abandoning ranges altogether?!

So other possible fix is to explicitly recast x into array
x = [x] at the very beginning of the function.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 12:24:09 AM UTC, comment #12: 

I can also reproduce this on aarch64, so it is not AVX, but rather non-SSE?


$ cat /proc/cpuinfo
processor        : 0
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer        : 0x41
CPU architecture: 8
CPU variant        : 0x0
CPU part        : 0xd08
CPU revision        : 3


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Jun 2023 12:11:03 AM UTC, comment #11: 


octave:58> (-1:0.2:1-0.2) - [x(1), x(2), x(3), x(4), x(5), x(6), x(7), x(8), x(9), x(10)]
ans =

 Columns 1 through 5:

                       0                       0                       0  -5.551115123125783e-17                       0

 Columns 6 through 10:

   5.551115123125783e-17  -1.110223024625157e-16  -5.551115123125783e-17                       0                       0


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Jun 2023 11:54:40 PM UTC, comment #10: 

&Yes, but code does not compare to x(6), but to x and they
are not the same see comment 7 and 8.


Dmitri A. Sergatskov <dasergatskov>
Wed 28 Jun 2023 11:10:23 PM UTC, comment #9: 

Since you are able to reproduce, can you step through the code with the debugger?  The sinc.m function is very simple


  y = ones (size (x));

  i = (x != 0);

  if (any (i(:)))
    t = pi * x(i);
    y(i) = sin (t) ./ t;
  endif


I would like to know what the value of 'i' is.  According to your comment #6,


octave:6> x(6) != 0
ans = 00000000


the sixth element is not equal to zero and should not be included in any further calculations.

Rik <rik5>
Group administrator
Wed 28 Jun 2023 10:59:12 PM UTC, comment #8: 

So it must be some re-casting happens between x = (-1:0.2:1-0.2)
and calling x(i):


octave:43> x = (-1:0.2:1-0.2)
x =

 Columns 1 through 6:

   -1.000000000000000   -0.800000000000000   -0.600000000000000   -0.400000000000000   -0.200000000000000    0.000000000000000

 Columns 7 through 10:

    0.200000000000000    0.400000000000000    0.600000000000000    0.800000000000000

octave:44> format long
octave:45> x = (-1:0.2:1-0.2)
x =

 Columns 1 through 6:

   -1.000000000000000   -0.800000000000000   -0.600000000000000   -0.400000000000000   -0.200000000000000    0.000000000000000

 Columns 7 through 10:

    0.200000000000000    0.400000000000000    0.600000000000000    0.800000000000000

octave:46> (-1:0.2:1-0.2) - x(6)
ans =

 Columns 1 through 5:

  -1.000000000000000e+00  -8.000000000000000e-01  -6.000000000000000e-01  -4.000000000000000e-01  -2.000000000000000e-01

 Columns 6 through 10:

   5.551115123125783e-17   2.000000000000001e-01   4.000000000000001e-01   6.000000000000001e-01   8.000000000000000e-01


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Jun 2023 10:55:12 PM UTC, comment #7: 

More bizarre stuff:


octave:27> format bit
octave:28> x = (-1:0.2:1-0.2)
x =

 Columns 1 and 2:

  1011111111110000000000000000000000000000000000000000000000000000  1011111111101001100110011001100110011001100110011001100110011010

 Columns 3 and 4:

  1011111111100011001100110011001100110011001100110011001100110011  1011111111011001100110011001100110011001100110011001100110011001

 Columns 5 and 6:

  1011111111001001100110011001100110011001100110011001100110011000  0011110010010000000000000000000000000000000000000000000000000000

 Columns 7 and 8:

  0011111111001001100110011001100110011001100110011001100110011100  0011111111011001100110011001100110011001100110011001100110011011

 Columns 9 and 10:

  0011111111100011001100110011001100110011001100110011001100110100  0011111111101001100110011001100110011001100110011001100110011010

octave:29> x(6)
ans = 0000000000000000000000000000000000000000000000000000000000000000
octave:30> x(1)
ans = 1011111111110000000000000000000000000000000000000000000000000000
octave:31> x(2)
ans = 1011111111101001100110011001100110011001100110011001100110011010
octave:32> x(3)
ans = 1011111111100011001100110011001100110011001100110011001100110011
octave:33> x(4)
ans = 1011111111011001100110011001100110011001100110011001100110011000
octave:34> x(5)
ans = 1011111111001001100110011001100110011001100110011001100110011000
octave:35> x(6)
ans = 0000000000000000000000000000000000000000000000000000000000000000



Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Jun 2023 10:41:54 PM UTC, comment #6: 

I can reproduce this problem with octave compiled with AVX/AVX2:


octave:1> sinc(-1:0.2:1-0.2)
ans =

 Columns 1 through 6:

   3.8982e-17   2.3387e-01   5.0455e-01   7.5683e-01   9.3549e-01          NaN

 Columns 7 through 10:

   9.3549e-01   7.5683e-01   5.0455e-01   2.3387e-01



octave:2> format bit
octave:3> x = -1:0.20:1-0.20;
octave:4> x(6)
ans = 0000000000000000000000000000000000000000000000000000000000000000
octave:5> x(6) == 0
ans = 00000001
octave:6> x(6) != 0
ans = 00000000
octave:7> xpi = pi * x(6)
xpi = 0000000000000000000000000000000000000000000000000000000000000000
octave:8> xs = sin (xpi)
xs = 0000000000000000000000000000000000000000000000000000000000000000
octave:9> y = xs / xpi
y = 1111111111111000000000000000000000000000000000000000000000000000


Markus patch helps.

Dmitri.
--



Dmitri A. Sergatskov <dasergatskov>
Wed 28 Jun 2023 07:40:51 PM UTC, comment #5: 

This looks like an unsafe optimization (--fast-math or similar)
or broken compiler (that uses unsafe optimization even though no-one asked it).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Jun 2023 07:27:27 PM UTC, comment #4: 

Could the original reporter try this code and paste the results back to this bug report?


format long
x = -1:0.20:1-0.20;
x(6)
xpi = pi * x(6)
xs = sin (xpi)
y = xs / xpi


There may be a subtle issue with sinc.m, but there also seems to be some problem with the reporter's installation and libraries.  For small inputs, sin(x) -> x and so the the sinc function (sin(x)/x) becomes x/x = 1.  Hence, I don't see a need to test for "abs (x) > eps".  To see what I mean, try the smallest number representable with doubles which is far smaller than eps.


octave:16> x = realmin
x = 2.2251e-308
octave:17> xpi = pi*x
xpi = 6.9903e-308
octave:18> sin (xpi)
ans = 6.9903e-308
octave:19> ans / xpi
ans = 1


Rik <rik5>
Group administrator
Wed 28 Jun 2023 05:03:38 PM UTC, comment #3: 

Does the attached patch solve the reported issue for you?


(file #54893)

Markus Mützel <mmuetzel>
Group administrator
Wed 28 Jun 2023 08:46:29 AM UTC, comment #2: 

Anyway, it might be a good idea to not compare floating point values exactly here:
https://hg.savannah.gnu.org/hgweb/octave/file/4555f9918009/scripts/signal/sinc.m#l47
Maybe, something like this would be better?


   y = ones (size (x));

-  i = (x != 0);
+  i = (abs (x) > eps);

   if (any (i(:)))
     t = pi * x(i);


Markus Mützel <mmuetzel>
Group administrator
Wed 28 Jun 2023 08:37:16 AM UTC, comment #1: 

Works for me with Octave 8.2.0 on Windows:

>> sinc(-1:0.2:1-0.2)
ans =

 Columns 1 through 6:

   3.8980e-17   2.3387e-01   5.0455e-01   7.5683e-01   9.3549e-01   1.0000e+00

 Columns 7 through 10:

   9.3549e-01   7.5683e-01   5.0455e-01   2.3387e-01


Markus Mützel <mmuetzel>
Group administrator
Wed 28 Jun 2023 07:52:39 AM UTC, original submission:  

  Hi! 
  I came across an incorrect expression for the sync() function: 


octave:55> sinc(-1:0.20:1-0.20)
   3.8982e-17   2.3387e-01   5.0455e-01   7.5683e-01   9.3549e-01          NaN   9.3549e-01   7.5683e-01   5.0455e-01   2.3387e-01


Reproduced for Octave 7.3.0 and 8.2.0 Releases.

  Thanks

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #54895:  bug64631.diff added by rik5 (608B - text/x-patch)
file #54893:  bug64361-sinc.patch added by mmuetzel (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by None (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-06-29 rik5 Attached File- Added bug64631.diff, #54895
    2023-06-28 mmuetzel Attached File- Added bug64361-sinc.patch, #54893
        StatusNone Patch Submitted

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code