gephi / gephi-plugins

Repository for Gephi Plugins maintained by the team. Each plugin has it's branch.
270 stars 620 forks source link

Error when casting Float to Double and vice versa #119

Closed WouterSpekkink closed 2 years ago

WouterSpekkink commented 8 years ago

I noticed that it is no longer possible to cast a Float to a Double or vice versa. For example, if I import coordinates as floats in Gephi, and then try to lay them out with the Geo-Layout plugin, I get the error report as shown in the attachment.

I believe this was not an issue in the previous version of Gephi.

errorreport

eduramiba commented 8 years ago

Thanks for the report, I think it used to store primitives instead of wrappers. Now the good way is to check that the column is a type of Number and do something like ((Number) object).doubleValue();

WouterSpekkink commented 8 years ago

So is this something we should deal with on the plugin side? I have the same problem with the event graph layout, for which a pull request is running. If there is something I should change there, I could probably do another commit this evening.

eduramiba commented 8 years ago

Sure, ideally you should check that the plugin works with any number type column. Something that might also work is casting to primitive double instead of wrapper.

WouterSpekkink commented 8 years ago

Okay, I think I fixed it for the event-graph-layout, following your suggestion. I just tested it by running Gephi with the plugin, and this time importing something as a float didn't cause an error. I'm not sure if my solution is very pretty, but it would work for the Geo-Layout as well. I use the following code. n refers to a node, as I am using a for-loop to iterate through all nodes in the graph. The ord variable is the double I want the plugin to work with, and order is the Column in which this variable is stored.

ord = ((Number) n.getAttribute(order)).doubleValue();

Works very well. I didn't know the trick with enclosing the entire expression in parentheses yet.

mbastian commented 2 years ago

Thanks folks. The line may not be very pretty but it's perfectly correct and efficient way to do it.

I just checked and the GeoLayout is also doing it this way so I'll close the issue as this must be resolved there as well.