More functions or more enums?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 02 February 2013   #1
More functions or more enums?

Anyone know if its better, performance wise, to have ten separate functions, or one function that evaluates the same code, using 10 different enumerated cases.

For example if you wanted to make functions to randomly delete subobject selections, would you have one function with a parameter to choose the subobject selection, or would you have separate functions for each? Is there any performance hit at all using if, then, statements for each case? Or should I worry about the load time for a large library of functions, even if they're in structs?
 
Old 02 February 2013   #2
deleting any actual scene object/sub-object will be many orders of magnitude more expensive than evaulating an if statement. Unless you're in a loop running millions of times I wouldn't worry about it.
 
Old 02 February 2013   #3
Quote: Anyone know if its better, performance wise, to have ten separate functions, or one function that evaluates the same code, using 10 different enumerated cases.


depends how you handle the ten separate functions, if you use them as a variable which is "pre chosen" then there is a performance gain. but if they are being still being called using case or if statements then inline probably has the edge.
 
Old 02 February 2013   #4
Thanks for the replies. I guess it does depend on what I'm using the functions for. I'm starting to get a larger and larger library of functions, where each type of function has multiple subobject versions, such as getting vertex, edge, and face positions or getting random selections, or copying selections. Most of the functions will be assigned specifically, to the current subobject level, so it seems like it would be better to keep them seperated. Others could still be used from different levels, such as my own selection conversion functions.

The main reason I'm thinking about combining functions, is that using -

fn RandomSelectionPoly SO:subobjectlevel =
(
if (SO == 1) then () else
if (SO == 2) then () else
if (SO == 4) then ()
)

looks easier to manage in large function libraries than -

fn RandomSelectionPolyVert =
()
fn RandomSelectionPolyEdge =
()
fn RandomSelectionPolyFace =
()

If I kept with separate functions I would probably want to have them in a struct. I guess the question is, how do you manage your function libraries?

Last edited by Ian31R : 02 February 2013 at 10:49 PM.
 
Old 02 February 2013   #5
You can use the case statement:

fn RandomSelectionPoly SO:subobjectlevel =
      (
	case SO of
	(
		  1: ()
		  2: ()
		  4: ()
	)
    )


Maybe the best practice is to use the struct.
 
Old 02 February 2013   #6
Originally Posted by miauu: You can use the case statement:

fn RandomSelectionPoly SO:subobjectlevel =
       (
 	case SO of
 	(
 		  1: ()
 		  2: ()
 		  4: ()
 	)
     )


Maybe the best practice is to use the struct.


Yeah I've seen that method before, is that more efficient than if statements? I'll probably just keep with separate functions in structs. Its nice having a function that does everything, but I fell more comfortable, when its used a lot in other functions, that its more efficient and less "bulky".
 
Old 02 February 2013   #7
let's look at this task: "We need mechanism to be able collect most of primitive objects..."
let's we care just about Box, Sphere, Cylinder, Cone, and Torus

solution #1 MORE FUNCTIONS

 fn collectBoxes = for obj in Geometry where classof obj == Box collect obj
 fn collectSpheres = for obj in Geometry where classof obj == Sphere collect obj
 fn collectCylinders = for obj in Geometry where classof obj == Cylinder collect obj
 fn collectCones = for obj in Geometry where classof obj == Cone collect obj
 fn collectToruses = for obj in Geometry where classof obj == Torus collect obj
 


solution #2 MORE ENUMS

 fn collectPrimitives class: = case class of
 (
 		 Box: for obj in Geometry where classof obj == Box collect obj
 	  Sphere: for obj in Geometry where classof obj == Sphere collect obj
 	Cylinder: for obj in Geometry where classof obj == Cylinder collect obj
 		Cone: for obj in Geometry where classof obj == Cone collect obj
 	   Torus: for obj in Geometry where classof obj == Torus collect obj
 	 default: #()
 )


it's same ugly as the fist one.

solution #3 MORE SKILL USE

 fn collectPrimitivesByClass class: =
 (
 		for obj in Geometry where classof obj == class collect obj
  )


what is better?
 
Old 02 February 2013   #8
solution #3 is not always applicable as different sub-objects have different functions sometimes with different signature, it's not as easily replaceable as a class name. Somewhere along the line you will have a switch clause.
 
Old 02 February 2013   #9
Originally Posted by lo: solution #3 is not always applicable as different sub-objects have different functions sometimes with different signature, it's not as easily replaceable as a class name. Somewhere along the line you will have a switch clause.

yes... i've shown very simple sample but we can pass a concision function with number of params:

for example

delete objects 
bb = for k=1 to 10 collect
(
	box pos:[0,0,random -20 20] height:1 wirecolor:(#(red,green,blue,orange)[random 1 4])
)
fn findbycondition list condition params: = 
(
	for element in list where (condition element params:params) collect element
)
fn colorcondition node params: =
(
	if params == unsupplied do params = red
	node.wirecolor == params
)	
fn heightcondition node params: = 
(
	if params == unsupplied do params = #(-1e9,1e9)
	node.pos.z >= params[1] and node.pos.z <= params[2] 
)	

findbycondition (objects as array) colorcondition params:green 
findbycondition (objects as array) heightcondition params:#(-2,8)
 
Old 02 February 2013   #10
in my library i also have search by collection of conditions...
 
Old 02 February 2013   #11
Originally Posted by lo: solution #3 is not always applicable as different sub-objects have different functions sometimes with different signature, it's not as easily replaceable as a class name. Somewhere along the line you will have a switch clause.


I agree, because some of the function I have, have more subobject types than others. With the random selection functions, you could make a function to randomly select borders or elements, or you could randomly select objects. With a function set for getting positions, you would probably only want to have verts, edges, faces, and nodes.

Although a lot of functions, you could probably use seperate functions to convert between other subobject levels, which is what I'm also considering doing, a lot of the functions I'm making for borders and elements require specific code. Functions for nodes often require different code as well.

Last edited by Ian31R : 02 February 2013 at 08:38 PM.
 
Old 02 February 2013   #12
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 04:55 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.