Skip to main content
KenFarley
KenFarley21-Topaz II
21-Topaz II
March 17, 2021
Question

Relations: Parameter defined as INTEGER changes to REAL

  • March 17, 2021
  • 3 replies
  • 9614 views

I'm working in Creo 4.

I have a parameter numSets, that I define as an Integer.

Now, I calculate the value of that parameter using dimensions of the model in the following relation:

numsets = ( lenmain - 2 * dxsltstrt ) / ( 2 * diaslot ) - 2

 Here's the part that irks me. After the relation has been entered and evaluated, Creo changes my parameter from Integer to Real, assigning it a value that has a fractional component to it.

The expected behavior, based upon every other programming language I've used, is for the type of parameter to be left as I defined it and the value be rounded or truncated to a whole INTEGER value. Switching the parameter type is absolutely NOT an acceptable result.

Knowing this, I'm going to have to be careful to explicitly use floor() or ceil() to restrict the assigned value.

Why is this kind of tomfoolery type conversion built into Creo?

    3 replies

    T
    23-Emerald IV
    TomU23-Emerald IV
    23-Emerald IV
    March 17, 2021

    Using relations is actually a sneaky way of changing a parameter's type.  Even though you can't do it manually without deleting and recreating the parameter, relations will gladly change the type for you.  It shouldn't work, but it does.  😁

     

    (view in My Videos)

      Dale_Rosema
      23-Emerald III
      Dale_Rosema23-Emerald III
      23-Emerald III
      March 17, 2021

      WOW!

      T
      23-Emerald IV
      TomU23-Emerald IV
      23-Emerald IV
      March 17, 2021

      What do you want to bet that this is 'working to spec'.  😂

        HamsterNL
        HamsterNL18-Opal
        18-Opal
        March 19, 2021

        Creo will use a REAL number because (most likely) your formula outputs a REAL number.

         

        If you want your formula to output an INTEGER, you should always use a CEIL or FLOOR function.

         

        I do wonder...numSets sounds like you want to calculate the "number of sets" of (for example) fasteners. If your formula results in 4.15782564 "sets"...do you want to use 4 sets...or 5 sets? And 4.856284618...4 sets or 5 sets?

         

        Also, know that a formula that uses "CEIL((x-b)/a)" can have a different outcome compared to "FLOOR((x-b)/a) + 1". That will become apparent when (x-b)/a results in an integer value.

          KenFarley
          KenFarley21-Topaz IIAuthor
          21-Topaz II
          March 19, 2021

          But that's not the issue I have with it. The problem is Creo *changing* the type of a parameter I defined. In any other programming language I've used that is based on strong typing, i.e. requires you to define the type of the variable before you can use it, variable types are not changed willy-nilly to comply with what the assigned value is. When I define an Integer, it better stay an integer, regardless of the assigned value. If this results in quirky behavior because I didn't take into account rounding or truncation, that's my fault, but that's not the problem here.

          As for floor and ceil, yes I'm all to well aware of how they work. Bear in mind that these functions actually output Real numbers, too.

          The numSets, not that it matters, is sets of pairs of items I was placing. I needed to place two of an item close together and was calculating how many sets of them would fit in a particular area. When given the choice I like to have things spaced as evenly as possible - fasteners, slots, position markers, etc.

            P
            19-Tanzanite
            pausob19-Tanzanite
            19-Tanzanite
            March 20, 2021

            I always thought that INTEGER type of parameters were kind of odd - for example, it's not supported in Pro/PROGRAM...  And you can't do the "force" a parameter to become an INTEGER type though this relations tomfoolery.

             

            I'd avoid using them altogether.  What's the point?  It's not like you need to have integers for that infamous itos() function to work 🙂

             

            Anyway, I found a Pro/Work-Around if you want the error thrown if a "real" or "string" value is being assigned to your integer valued parameter: Make it a restricted integer type - let's say less than 32767 and more than -32768:

            pausob_0-1616204237353.png

            If this kind of parameter is then assigned an incompatible value:

            pausob_1-1616204347791.png

             

             

             

              KenFarley
              KenFarley21-Topaz IIAuthor
              21-Topaz II
              March 23, 2021

              Integers, when properly implemented, have advantages over other data types. In general, for any programming language, there are these:

              (1) Unambiguous values. For a real number, what is a "2" could be, due to rounding or whatever, 2.0000001, or 1.9999998, depending on what has happened to that variable. This could, if you're not a cautious programmer, lead to erroneous results if you're relying on a conditional statement like IF x < 2 THEN...

              (2) Integers take less memory space, particularly if the language you are using has implemented different length variants, like C's short and long. Probably not a concern with Creo.

              (3) Mathematical calculations with integers are faster than floating point. Again, probably not a concern with Creo, but I've had to do real-time data acquisition and leaving the data as the "raw" integers greatly improved max data rates possible.

              The trouble I'm seeing with Creo is, if an "Integer" is just a "Real" that has a temporary or honorary status as an integer until something changes it, then none of the advantages of integer data types is applicable. The most worrisome is the possibility of errant IF/THEN conditionals, but I can deal with that by avoiding the "==" logical comparison, I suppose.

              Dale_Rosema
              23-Emerald III
              Dale_Rosema23-Emerald III
              23-Emerald III
              March 23, 2021

              Looking at Tom's first video, I think it would be more scary if the number is turned into a string.

              Terms & ConditionsAccessibility statement