Re: [igraph] Question on igraph_integer_t and igraph_real_t

[Gábor Csárdi]

On Tue, Jan 27, 2009 at 8:18 PM, Chris Wj <address@hidden> wrote:
> Pardon my curiosity, but what makes the change tedious? What parts would
> break if you changed the typedef?

Many things could potentially break, most of all the R interface,
because there is no copying when an igraph function is called from R.
We must be sure that all R functions use 'integers' instead of doubles
when calling igraph. But other things could break potentially as well.
Give it a try if you want, make the change recompile igraph and run
'make check'. (make check is not exhaustive, even if it is clean,
there could be errors.)

> What would cause the change to the
> indexing in R?

Nothing, that is a separate issue. In R everything is indexed from 1,
except igraph vertices and edges, and this is confusing to R users.

The idea is, that it is better to make the two substantial changes at
the same time.

G.

> Again, this is just curiosity... I have not had to handle this type of
> change before.
>
> On Tue, Jan 27, 2009 at 3:44 AM, Gábor Csárdi <address@hidden> wrote:
>>
>> igraph was started a long time ago, even if not much from the original
>> code has remained. At that time I was concerned with some system
>> having sizeof(long int)==2. That's the historical reason for defining
>> igraph_integer_t as a double.
>>
>> It is a decision that I regret now, but it would be quite hard to get
>> rid of it, it requires a lot of testing and retesting. In particular,
>> the vertex/edge ids in the graph should be long int, igraph would be
>> somewhat faster as well.
>>
>> But for this change we need a good testing system first, and then,
>> maybe together with the painful change from 0-based indexing to
>> 1-based in the R package, we can have it.
>>
>> Gabor
>>
>> On Mon, Jan 26, 2009 at 11:22 PM, Chris Wj <address@hidden> wrote:
>> > I was reading the code to understand the underlying mechanisms in
>> > igraph.
>> > This is probably more of a C programming question, but why is
>> > igraph_integer_t defined as a double?
>> >
>> >> typedef double igraph_integer_t;
>> >> typedef double igraph_real_t;
>> >
>> > At first, I thought this was to have 64-bits for storing graph and edge
>> > ids
>> > because the graphs can get quite large. What is the benefit over using a
>> > long int?
>> >
>> > -Chris
>> >
>> >
>> > _______________________________________________
>> > igraph-help mailing list
>> > address@hidden
>> > http://lists.nongnu.org/mailman/listinfo/igraph-help
>> >
>> >
>>
>>
>>
>> --
>> Gabor Csardi <address@hidden>     UNIL DGM
>>
>>
>> _______________________________________________
>> igraph-help mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/igraph-help
>
>



-- 
Gabor Csardi <address@hidden>     UNIL DGM