Darren's Weekly Nugget 05/24/2010

[mike_nrao]

Whoah!  I didn't know you could do conversion that way.   Before implementing one of these "alternative" conversions though I've gotta consider overhead compared to the traditional approach: 

This:

seems to be nearly equivalent to this:

BUT this:

seems to be about twice as fast as the best case of this:

Number of enum elements seems to have no impact on conversion to string in either approach (as expected).

Conversion from string to enum scales with number of elements in both approaches (as expected).

Great nugget Darren, thanks!  I plan on making some code changes to take advantage of this.

[JackDunaway]

---

mike_nrao wrote:

Before implementing one of these "alternative" conversions though I've gotta consider overhead compared to the traditional approach... seems to be about twice as fast....

---

No code containing a property node is going to come close to operating as fast as the "Format into String" (this is due to the forced swap to the UI thread for the synchronous PN execution). I would not be surprised if a FOR Loop benchmark with Format into String beats the "Strings" PN by two or three orders of magnitude (yes, I literally would not be surprised if it ran 100X or 1000X faster).

Also, PN's are not valid on RT targets. And finally, they require the use of a potentially unnecessary "dummy" FP control in order to use the PN. (See the comments of Function to Count Number of Items in an Enum to read some related chatter on the Strings property node)

So... don't consider "Format into String" the "alternative"... consider it the standard!

[danny_t]

---

@Intaris wrote:

Something which surely can't be left out of this nugget is the fact that the reverse also functions.

Following code runs flawlessly.  Of course, if the string does not exactly match one fo the enum strings, the conversion will fail.  But sometimes, this is OK.

Shane

---

Though I accept that the code above always works when you come to utilizse this sort of thing I have found a problem and I am not sure if this is a bug or not.

Enum values here are Monday, Tuesday, Wedensday

The scan from string does not act as a full match, so if my input string is Monda the scan from string will result in a error which I can trap and deal with, however if I passing Mondaytuesday it scan from string will happily set output 1 to Monday and not notice the input was invalid.

So instead I have found I need to check the property node []strings for the Enum in some case first

Dannyt

[David_L]

I agree with you Shane.  While not a showstopper, this does seem to me like incorrect behavior.   This was reported to R&D (CAR # 252400 ) for further investigation. Thanks for the feedback!

[Intaris]

Sure,

'cept it wasn't me who found the unexpected behaviour....

[David_L]

Haha oops.  I read the quoted text instead of the real signature.  Sorry Shane/Danny