Typecast mystery: value-dependent coercion weirdness with accumulate? about graphblas HOT 7 CLOSED

It might have to do with a compiler optimization. I ran across an odd typecast from double to int, but not this one. It was the case where the double was outside the range of a valid int, which gives an undefined result in ANSI C11.

Is your two-line printing of a vector displaying the indices in the first line, and values in the 2nd?

It looks like a bug, in any case. A standalone C example would be very helpful.

How are you printing the values? I assume you force completion first? Do you use extractTuples to get the values out, to print them?

from graphblas.

Yes, the first line displays the indices and the values are in the second line.

Yes, the values are gotten from extractTuples. Also, Vector_build was used to populate the arrays.

I'm working on a C example and should probably try to verify I see this behavior with my local build.

from graphblas.

Bah, I just realized I compiled the wrong version. I'll continue tomorrow. I did verify the C call from Python though:

import grblas as gb
w = gb.Vector.from_values([0, 1], [0, -20], dtype='INT64')
u = gb.Vector.from_values([0, 1], [1, 2], dtype='FP64')
gb.lib.GrB_Vector_apply(
    w.gb_obj[0],
    gb.base.NULL,
    gb.lib.GrB_PLUS_INT64,
    gb.lib.GrB_IDENTITY_FP64,
    u.gb_obj[0],
    gb.base.NULL
)

which gives the wonky results. Here, gb.base.NULL is the null pointer.

If any observers are curious, one can install grblas via conda install -c conda-forge grblas on OS X and Linux (and conda from here: https://docs.conda.io/en/latest/miniconda.html). It will be pip-installable soon (the normal way to install Python packages).

from graphblas.

I replicated the error. That's a bug in 3.2.2 that I fixed in the 3.3.0 draft. It was a typecasting mistake in Source/GB_dense_subassign_23.c for the generic case. In 3.2.2, I picked the wrong typecasting function. It's fixed in the draft of 3.3.0.

from graphblas.

In v3.2.2, this code below replicates the bug. In v3.3.0, it gives the right result.

#include "GraphBLAS.h"
#define OK(method)  \
{                                \
    info = method ; \
    if (info != GrB_SUCCESS) printf ("Error: %s\n", GrB_error ()) ; \
}

int main (void)
{

    GrB_Vector w, u ;
    GrB_Info info ;
    OK (GrB_init (GrB_NONBLOCKING)) ;
    OK (GrB_Vector_new (&w, GrB_INT64, 2)) ;
    OK (GrB_Vector_setElement_INT64 (w, 0, 0)) ;
    OK (GrB_Vector_setElement_INT64 (w, -20, 1)) ;
    OK (GrB_Vector_new (&u, GrB_FP64, 2)) ;
    OK (GrB_Vector_setElement_FP64 (u, 1, 0)) ;
    OK (GrB_Vector_setElement_FP64 (u, 2, 1)) ;
    OK (GxB_print (w, 3)) ;
    OK (GxB_print (u, 3)) ;
    OK (GrB_apply (w, NULL, GrB_PLUS_INT64, GrB_IDENTITY_FP64, u, NULL)) ;
    OK (GxB_print (w, 3)) ;
    OK (GrB_finalize ( )) ;
}

from graphblas.

I fixed the bug on June 1st, but I didn't log the bug fix in the Doc/ChangeLog. I've added that (bug #18) to the ChangeLog, in v3.3.0-draft10, just posted now.

from graphblas.

Great, thanks!

from graphblas.