Re: [igraph] Question on igraph_integer_t and igraph_real_t

[Chris Wj]

Pardon my curiosity, but what makes the change tedious? What parts would break if you changed the typedef? What would cause the change to the indexing in R? 

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