How To: Format a real number relation in a note?

[TomD.inPDX]

I have a real number variable and I want to represent this in a note with a limited number of decimal places.

The default decimal places is 3 in the part file and that is what I want. The note I want needs to be limited to 1 decimal place.

Since this is not a "dimension", I cannot edit the number of decimal places in properties.

I can set the decimal places in the "options" of the measure:distance dialog (for instance) but the relation only follows the units set in options of a saved measure, not the decimal places set in the options.

Creo 2.0

thanks

[James62 · Accepted solution]

hi Antonius,

I would ask PTC support the very same question but I can't.

Anyway PM me if you need some help with this I had it figured out before buying Creo.

And please vote for this one: http://communities.ptc.com/ideas/1400#

EDIT: Just an idea. If your parameter is a real number then you could try adding &param_name[.1] to your drawing note. I think just that could solve your problem. So there might not be a need to convert real to string if you aren't gonna add additional chars and use this in repeat region.

[TomD.inPDX]

Thanks Jakub.

Where is there a good comprehensive list of all the functions available in Creo?

[James62]

You're welcome.

Do you mean part/assy relations functions? Or comprehensive list of all the functions available in Creo?

I don't know but Brian maybe does. http://communities.ptc.com/message/186647#186647

The site I've learned most of the relation functions from isn't available anymore.

[TomD.inPDX]

This list...

I searched Help for "Functions and Operators" and got a little help, but not nearly comprehensive enough to learn from.

[James62]

Yeah, maybe googling for some of these could find explanation list.

[BrianMartin]

HI Jakub & Antonius...

If you ever need help with any functions like this, Pro/PROGRAM, relations, or even relations in tables- just ask. I'm very well versed in all these things. I've started gathering information to put everything into one class. I'm still building the whole online training academy thing. Pro/PROGRAM will be another good addition... people always ask for help on this and there are really no good reference books, videos, or classes. I figure it's a good place to start differentiating me from other training services. At first, all the classes will be free. Maybe one day I can actually sell them, too. It would be nice not to have to eat ramen noodles day and night... one day maybe I can move up to Cambell's soup!

I'm always happy to help you anyone from Planet PTC Community... if you get stuck, just give a shout.

Thanks!

-Brian

[TomD.inPDX]

[[CAMPBELL'S SOUP GIFT BOX]]

You have time to cook, Brian... much less eat?

I think programming is only a side-feature for 90% of the users. We only need enough to keep models from blowing up, and in some cases, to make similar items quickly. Unfortunately for those that put together training materials, by the time you finish a good session, the interface changes.

We seriously appreciate your generous time here on the board. I will certainly keep the offer in mind.

Now were do I send the soup?

[BrianMartin]

You should just bring the soup to next years' Planet PTC Live in Anaheim. Next year's conference will be much closer to you... it would be great if you could make it down.

Good point about the interface changes. This is a good reason to focus on portions of the interface that haven't changed since the dawn of the dinosaurs.

[BrentDry]

Thanks James.

Despite using this before I had completely forgotten so your older post was valuable to me.

Still pleases me that I can look up the community 🙂

(And to those that know me this is my work login versus the private one I have had for years. I grabbed this one so I could login to PTC help and training based on my work agreement with PTC)

 Regards, Brent

[MartinHanak]

Antonius,

just FYI you can convert REAL value into STRING value using the following relations in new empty part.

/* input variables

number_digits=3

x=12.98765

/* output variables

t1=floor(x,number_digits)

t2=itos(t1*10^number_digits)

t3=extract(t2,1,string_length(t2)-number_digits)+"."+extract(t2,string_length(t2)-number_digits+1,number_digits)

Martin Hanak

[BrianMartin]

Martin's getting sneaky trimming the digits as a string instead of a real number. This is a great trick... if only more people understood some of the nifty stuff you can do with relations. Unfortunately it's one of those rare arts that few seem to know about.

Martin is really giving a goldmine of information here but you have to dig deep to fully appreciate it.

The four functions Martin is using are:

• FLOOR - rounds any real number down to the next closest value with the number of digits specified. The format is floor(real number,number of digits to round to)
• ITOS - the "integer-to-string" function. The format is just itos(integer).
• EXTRACT - grabs a portion of a string. The format is extract(string, start position, number of chars to extract)
• STRING_LENGTH - provides the length of a string in characters. The format is string_length(string)

But you really have to examine the code to truly see the beauty here.

The itos function only converts integers to strings. It cannot handle decimal values (real numbers). If you wrote x = itos(12.98765) you'd end up with x="12". The decimal values would be discarded. Therefore, Martin's relations incorporate a thoughtful bit of math to handle this problem.

First, he sets the variable number_digits to 3. Then, first set a variable for the number digits after the decimal to preserve. He uses the floor function to round down the real number x which starts at 12.98765. Once this function has completed it's work, x is 12.987.

Next, Martin uses the itos function. He multiples 12.987 by 10 to the power of 3 (or 1000) to remove the decimals. Thus, once itos has done it's work, the value has changed from 12.987 to "12987" (now a string with the decimal removed)

In the last line of the relations, Martin uses extract and the string_length functions together. This final line writes out the first two characters of the string "12987" which are just "12". Next a dot (.) is written out. Finally, the last 3 characters of the string ("987") are written. Together this is "12.987" which completes the conversion from 3 digit real number to string".

The whole thing is very, very clever. Thanks for posting this Martin.

Thanks!

-Brian

PS: There's one very slight problem though... I'll leave it to any curious readers to figure it out. Here's a hint... it has to do with the "6" in the original value of x which was 12.98765 Maybe someone will catch it and demonstrate the fix.

[TomD.inPDX]

Oh, I definitely appreciate Martin's approach. In the day, I was very into programming DBASE III and IV and completely understand the approach and even the syntax.

The use of "FLOOR" might be a bit troubling since a "ROUND" should be available to round to either the "even principle" or the conventional 1-4=down and 5-9=up. But even thsat could be "relationed" to resolution.

Why a "new empty part"?

This stuff has to be written somewhere; No?

[BrianMartin]

Yep... the use of Floor was the "one very slight problem". Martin could've incorporated a test to do the rounding better. As it stands 12.98765 rounds to 12.987 when it should round to 12.988. A simple if/then/else test and the addition of the CEIL command could resolve this.

But that's just being nitpicky...

[TomD.inPDX]

Brian, I'd love to hear this from the "horse's mouth" so to speak...

Quite some time ago, I heard it was NASA that came up with the Round "5" to Even rule. Is this a fact?

n.nn5 round to n.nn(even) where n.nn(1-4) rounds down and n.nn(6-9) round up.

And where does that leave n.nn51 in relation to n.nn?

Its a great rule but the source has remained ambiguous. I'd love to confirm this with references.

[BrianMartin]

Unfortunately, "the horse" can neither confirm nor deny that NASA is responsible or the rounding rule you mentioned.

One of my children pulled me aside the other day and said: "Dad... is there life on other planets?" Of course I said "We don't know yet but we're looking... and personally I believe there is life on other planets just by the sheer mathematical probability. I think we'll eventually find it."

This seemed to be a reasonable and, I hoped, thoughtful answer. When I asked why the child wanted to know, he said: "Well Uncle Danny (a huge redneck related to my ex-wife) said NASA already has proof aliens exist but they keep it secret from everyone. Is that true?"

(Facepalm)

[BenLoosli]

Rules for Rounding Off

--------------------------------------------------------------------------------
Ever since the calculator replaced the slide rule, people have been able to get results to six or more places, therefore it's critical that we know how to round the answers off correctly. The typical rule taught back in elementary school was that you round UP with five or more and round DOWN with four or less.

SORRY, BUT THIS RULE IS WRONG!

However, please don't rush off to your elementary school teacher and read 'em the riot act!

The problem lies in rounding "up" (increasing) the number that is followed by a 5. For example, numbers like 3.65 or 3.75, where you are to round off to the nearest tenth.

OK, let's see if we can explain this. When you round off, you change the value of the number, except if you round off a zero. Following the old rules, you can round a number down in value four times (rounding with one, two, three, four) compared to rounding it upwards five times (five, six, seven, eight, nine). Remember that "rounding off" a zero does not change the value of the number being rounded off.

Suppose you had a very large sample of numbers to round off. On average you would be changing values in the sample downwards 4/9ths of the time, compared to changing values in the sample upward 5/9ths of the time.

This means the average of the values AFTER rounding off would be GREATER than the average of the values BEFORE rounding.

THIS IS NOT ACCEPTABLE.

We can correct for this problem by rounding "off" (keeping the number the same) in fifty percent of the roundings-even numbers followed by a 5. Then, on average, the roundings "off" will cancel out the roundings "up."

The following rules dictate the manner in which numbers are to be rounded to the number of figures indicated. The first two rules are more-or-less the old ones. Rule three is the change in the old way.

When rounding, examine the figure following (i.e., to the right of) the figure that is to be last. This figure you are examining is the first figure to be dropped.

If it is less than 5, drop it and all the figures to the right of it.
If it is more than 5, increase by 1 the number to be rounded, that is, the preceeding figure.
If it is 5, round the number so that it will be EVEN.

Keep in mind that a zero is always considered to be EVEN when rounding off.

This from ANSI Z210.1

[MartinHanak]

Antonius,

of course you can use relations in any part. I thought the most easiest method for testing is using "new empty part".

To implement the conventional 1-4=down and 5-9=up "ROUND" principle, it is necessary to modify relations slightly, see below.

/* input variables
number_digits=3
x=12.98799
x=x+5/10^(number_digits+1)

/* output variables
t1=floor(x,number_digits)
t2=itos(t1*10^number_digits)
t3=extract(t2,1,string_length(t2)-number_digits)+"."+extract(t2,string_length(t2)-number_digits+1,number_digits)

Martin Hanak

[TomD.inPDX]

Very clever!

[BrianMartin]

Now he's just showijng off.

[JonathanHodgson]

Yes indeed - adding 0.5 (or 0.0005, depending on the number of decimals you're rounding to) is a much neater technique than if/else. I've used that before with Excel's INT() function.

[TomU]

Just a head's up for other's searching the community who may attempt to implement this.  There are a couple of use cases that may cause issues if used as written.

Values less than 0.0995 will "break" the logic and only output "."

Values less than 0.9995 will not output the leading zero.  0.9994 outputs ".999"

[rgonzalez]

X = 0.098765

[JodyPescod]

I just caught this thread and was a little excited to see if PTC had actually added a much needed function. But alas .... no .... just another verification that they don't listen to the users.

We have been using this "trick" to convert parameters that are real numbers to notes in drawings since I started. The function we have asked for is RTOS (Real to String) with a way to control the number of decimals.

The actual answer to the posted question is .... there is no direct method .... just Martin's "trick".

[huggre]

Funny how the "integer to string" (ITOS) function has been with us for so many years, but still "no real to string" function in sight.

My guess is that it would take PTC a few hours to program this function into Creo, still we have to create pages of cryptic relations to perform such a simple task.

What a monkey to do?

Lets hope PTC gets there act together and fix this issue once and for all.

And when they are at it, why not provide the entire library java functions related to managing strings and numbers.

Now, that would something!!!

[dveljkovic]

I have just found this thread by looking for something else.

This is how I do it:

/*#####Number to string for given decimal places (up to 9)#####

/*#####ASSIGN DIMENSION BELOW TO A VARIABLE#####

NUMBER=d8

/*#####ENTER DECIMAL PLACES YOU WANT TO SHOW#####

DECIMAL_PLACES=3

/*CALCULATION (REPLACE “X” WITH NUMBER 1,2,3,…FOR EACH DIMENSION YOU WANT TO MAKE AS STRING)

NUMBER_INT=FLOOR(NUMBER)

NUMBER_DEC=NUMBER-NUMBER_INT

NUMBER_DEC=NUMBER_DEC*10^(DECIMAL_PLACES)

X_STR_NUMBER_INT=ITOS(NUMBER_INT)

CHECK=(NUMBER_DEC-FLOOR(NUMBER_DEC))

IF (CHECK<0.5)

X_STR_NUMBER_DEC=ITOS(FLOOR(NUMBER_DEC))

ELSE

X_STR_NUMBER_DEC=ITOS(CEIL(NUMBER_DEC))

ENDIF

/*NUMBER AS A STRING "STR_NUMBER" WITH GIVEN DECIMAL PLACES

X_STR_NUMBER=X_STR_NUMBER_INT + "." + X_STR_NUMBER_DEC

This macro also rounds up or down the value for given decimal places.

[James62]

Nice solution, Danilo.

[dveljkovic]

When nothing else is available from PTC this is the best I can do. It took me 5 minutes to make this script. I do not understand why PTC could not do something like this? They should be better in this, right? If Excell has VAL and STRING functions since forever, I do not understand why Creo does not have it in 21st century?

[James62]

I am sorry, didn't mean to get started on why PTC couldn't change this and that.

Yes, it is 21st century. Relations could be more robust with more operations and functions available nowadays, but this is what we get.

I think the old programmers of Pro/E has put in too little functionality back when they have been developing relations just because they wanted to save few lines of code, but now each and every user's part has to have this more of an awful code. Luckily we can get good enough comps now that can chew all these stupid relations.

These days when it's all about sales for PTC, they don't give a damn about relations, as long as existing relations functionality is not broken. If there is a possible workaround to a problem, then an enhancement to that problem will not make any more sales.

I've posted here just to let you know I wouldn't be able to figure out how to write that relation you posted above in 5 mins, and maybe not even in 5 hours. So, that's what my hat goes off for.

Well, if PTC cared to make relations more robust this thread wouldn't keep on going, but then we wouldn't know how to literary make a whip from a crap.

[TomU]

Similar to the logic above, this one too does not process values correctly.

Values less than 0.0009 output "."

Values with zeros immediately after the decimal point get shifted.

• 0.001 --> ".1"
• 0.01 --> ".10"

Whole numbers don't have trailing zeros.  (Technically not wrong, just not desirable.  Should be "10.000".)

• 10.000 --> "10."

Combination examples:

• 10.0009 --> "10."
• 10.001 --> "10.1"
• 10.01 --> "10.10"