Measuring diagrams in acres, hectares and unit icons

[Aristos Queue]

Doing a bit of analysis of the growth of LV's libraries over the last few releases, and someone pointed out that the number of VIs is about as interesting as counting the number of .cpp files in a C++ program. Instead of number of VIs, we need to know how many square feet the sum total of the VIs cover to really get a feel for the growth rate, a measure more akin to lines of code. Anyone ever written a tool that you can point at a directory of VIs and figure out how the surface are of its diagram? And maybe even its average icon density?

Note that this is just a fun project -- we're not seriously considering either of these measures as generally relevant to any particular decision. It just seemed like an interesting set of facts to know.

[crelf]

QUOTE(Aristos Queue @ Oct 31 2007, 09:06 AM)

Anyone ever written a tool that you can point at a directory of VIs and figure out how the surface are of its diagram?

...dont' forget to multiply the area of subdiagrams (in sequences) by the depth of the number of sequence pages.

[Ton Plomp]

Here's the easy answer:

Ton

[wevanarsdale]

QUOTE(tcplomp @ Oct 31 2007, 01:22 PM)

Here's the easy answer...

As long as your diagram is no bigger than 2.5 in x 2.5 in...

[Ton Plomp]

QUOTE(wevanarsdale @ Nov 1 2007, 07:47 PM)

As long as your diagram is no bigger than 2.5 in x 2.5 in...

Sorry I don't get this....

Ton

[robijn]

QUOTE(Aristos Queue @ Oct 31 2007, 01:06 AM)

for the growth rate, a measure more akin to lines of code. Anyone ever written a tool that you can point at a directory of VIs and figure out how the surface are of its diagram? And maybe even its average icon density?

I would be interested in numbers like this:

0. #nodes, total wire length, #subVI's

1. #nodes / wire length (low rate means spagetti code)

2. #wire bends / wire or wire length (low rate indicates better wire straighting)

3. Code structure complexity indicator: deepest nesting level of structures in the code (except error case around whole VI)

4. Data structure complexity indicator: number of bunde / unbundle / index array / delete from array / insert into array / replace array el / operations in the code

5. Code branch obfuscation indicator: number of case frames or dynamic dispatch method calls

6. Error wire use indicator: is an error wire connection wired through or is the error "put under the carpet" (i.e. lost)

These numbers should give some fingerprint of what the code looks like.

I think you should be able to confirm that a program you have hacked together is actually written worse than one that was properly designed

Joris

[LAVA 1.0 Content]

QUOTE(robijn @ Nov 2 2007, 05:44 AM)

I would be interested in numbers like this:

0. #nodes, total wire length, #subVI's

It sounds like you are interested in "http://forums.lavag.org/Calculate-VI-Modularity-Index-t9266.html&p=36929#entry36929' target="_blank">Modularity Index"...

[jpdrolet]

QUOTE(tcplomp @ Nov 2 2007, 01:44 AM)

Sorry I don't get this....

Ton

The number of pixels is a I16. A max of 32767 pixels is a small diagram...

[Aristos Queue]

QUOTE(jpdrolet @ Nov 2 2007, 07:04 AM)

The number of pixels is a I16. A max of 32767 pixels is a small diagram...

But 32767x32767 pixels is a HUGE diagram. Both of my monitors together are 3360 pixels across, so I think we're ok. Anyone making VIs that cant fit within 32767x32767 needs to discover "Create SubVI From Selection" quickly (or they've got a bastard developer on their team who is hiding code way out at the edges of diagrams hoping it won't be noticed).

[LAVA 1.0 Content]

QUOTE(Aristos Queue @ Nov 2 2007, 12:26 PM)

Anyone making VIs that cant fit within 32767x32767 needs to discover "Create SubVI From Selection" quickly (or they've got a bastard developer on their team who is hiding code way out at the edges of diagrams hoping it won't be noticed).

I recall someone (you?) mentioning that there was a limit on the total length of a wire, but can't find it; I guess I've forgotten the key words...

[wevanarsdale]

QUOTE(tcplomp @ Nov 1 2007, 10:44 PM)

Sorry I don't get this...

The area in the diagram is I16. This value exceeds the data range for a square region with sides larger than 181 pixels. I used 72 pixels/inch to get 2.5 inches.

[Aristos Queue]

QUOTE(wevanarsdale @ Nov 2 2007, 12:41 PM)

The area in the diagram is I16. This value exceeds the data range for a square region with sides larger than 181 pixels. I used 72 pixels/inch to get 2.5 inches.

OH! You're right! I was looking at the dimensions and seeing I16 x I16, and thinking "what's the big deal?" But I16 x I16 gets stored back into an I16, so of course, that's pretty small.

The dimensions need to be cast as U32 *before* the multiplication node.

[Justin Goeres]

QUOTE(Aristos Queue @ Nov 2 2007, 12:17 PM)

OH! You're right! I was looking at the dimensions and seeing I16 x I16, and thinking "what's the big deal?" But I16 x I16 gets stored back into an I16, so of course, that's pretty small.

The dimensions need to be cast as U32 *before* the multiplication node.

Or U64, just in case .

[Aristos Queue]

QUOTE(Justin Goeres @ Nov 2 2007, 02:29 PM)

Or U64, just in case .

Just in case of what? If I have 2^15 x 2^15, I get 2^30 as my maximum bound. It can't exceed I32, much less U32. I only went to U32 because an area should never be negative.

[Justin Goeres]

QUOTE(Aristos Queue @ Nov 2 2007, 02:37 PM)

Just in case of what? If I have 2^15 x 2^15, I get 2^30 as my maximum bound. It can't exceed I32, much less U32. I only went to U32 because an area should never be negative.

I was thinking of the case where you have enough obscenely large block diagrams to roll over that U32 when you start adding all their areas up. But I guess you could coerce that value later, eh?

[crelf]

QUOTE(robijn @ Nov 2 2007, 07:44 PM)

I would be interested in numbers like this:

Time for another plug

Whilst node count is interesting, some of them can get in the way of an accurate relative determination of code "size" (more informaiton here). Sounds like you'd be interested in the VIE LabVIEW Metrics Tool - it more accurately measures the "size" of your code in a varibale that we call "GOBs" ("GObjects - can't tell you too much as the forumla is proprietary, but let's just say that it's comparable to Logical SLOC) and the complexity (exactly what you've asked for in #3). You can download the tool for a free trial here (it's part of the VISTA Metrics 1.2.0 Package).