Rounding to decimal in fields

[yael.vsh]

Hi. 
So I have a crazy situation.

I'm trying to create a field with area value of a polyline in meters with two decimals, rounded down.

The value should match the one written in properties with LUPREC=4, as an external inspector checks the field to match properties (cutting off the unnecessary digits, hence round down).

I've used TRUNC function and everything was great. 

For example 11577880.1183 in properties shows in field 115.77 m

Until I stumbled onto polyline that shows 1328100 in properties but field shows 132.80. I saw that internal value of area was 1328099.99998. The properties window rounds it, but TRUNC function just cuts off after 5th digit.

I tried rounding the number and thus cutting off all decimals, before truncating it at, but then problem with values like 123199.8563, which in field shows 123.20.

The SOLUTION that I thought of would be to round the number after 4th decimal but I can't get it to work in FIELDS. 

Neither multiplying by 10000 works, nor setting the decimal at which to round.

Another idea is somehow to use the area field inside formula with precision of 0.0000, which i can't achieve either. Formula fields seem to use the internal value, disregarding set precisions.

Anyone can think of a solution or help me achieve mine?

The solution must be within the field expression, as I need the values to update with Polyline.

Thank you!!

[ВeekeeCZ]

This formula will work for you?

%<\AcExpr (%<\_FldPtr 2133054391376>%/10000-0.005) \f "%lu2%pr2">%

[cadffm]

1. I don't know why you are after this, but ok (the normal rounded numbers are "more correct"  then what you want.)

2. My comments, even if it is uninteresting

3. Sample file

I think I'm completely confused after reading the thread,

if so - jump to the end

When i wrote about "this case" or "in your" case i mean your attached dwg sample.
_

>>I'm trying to create a field with area value of a polyline in meters with two decimals, rounded down.
First Problem: DOWN? Rounded down in you case would be 1328099.99
Q: Are you really want that the field you are after ONLY round down?
For me the down-rounded number is "more wrong", or the drawing 😉

>>The value should match the one written in properties with LUPREC=4,
?
Luprec 4 means 4 decimals and in your case the properties palette shows 1328099.9999

>>I've used TRUNC function and everything was great.
Trunc is not for rounding, trunc CUTs the decimal places. But ok, in case of "rounding down" it is the same,
but without any decimal places and not with 2 or 4, only for NO decimals.

>>For example 11577880.1183 in properties shows in field 115.77 m
Oh, now let's multiply too, okay

>>Until I stumbled onto polyline that shows 1328100 in properties
while luprec is set to 0,1,2 or 3, not 4 as you wrote above.

>>but field shows 132.80
}missing the fieldsetting/codes your are using{

>I saw that internal value of area was 1328099.99998.
In your posted sample it is 1328099.9999293.... and so on

>The properties window rounds it,
usual

>but TRUNC function just cuts off after 5th digit.
TRUNC is cutting, nothing else

>The SOLUTION that I thought of would be to round the number after 4th decimal but I can't get it to work in FIELDS.
4 decimals rounded is 1328099.9999

>Formula fields seem to use the internal value, disregarding set precisions.
You'are right, internal process is not using the displayed value, it works with the directly determined values.

---

>>I had same exact polyline copied/mirror and same field formula showed once 132.80 and once 132.81
We could guess, but why? Upload a sample (two polylines, two fields)

-

>>I cannot have that because it doesn't match the properties.

hooo

If you want that fieldvalue match the properties palette value,

stop everthing, use this code %<\AcObjProp.16.2 Object(%<\_ObjId 282255661888>%).Area \f "%lu6%qf1%zs8">%

and nothing else.

It display 1328099.99992932 for luprec8 and 1328100 for luprec2 for example

and only this matchs to  " fieldvalue match the properties palette value"

Sorry, You either want it to be identical or you don't.
Everything in between is not identical.

If you want everytime 2 decimals, my sample could be a solution,

bet depend on your luprec/auprec settings... it is dismatch

[cadffm]

@ВeekeeCZ 

It works in both cases, fix decimal places, and without this setting it follows the luprec

Kudo 4U

Z9E3zK5E wrote:

%<\AcExpr (%<\_FldPtr 2133054391376>%/10000-0.005) \f "%lu2%pr2">%

[yael.vsh]

Thanks a lot!

I've thought of that too.

Unfortunately it doesn't solve the problem. 

(See the screenshot attached)

[yael.vsh]

Hi

First of all, thank you for taking your time to read the thread.

I'm sorry I was unclear.

Please see new DWG attached.

It's some bureaucratic thing. The construction company I work in has to send polylines (apartment shape) with their corresponding area value written in format of meters, with precision of two decimals. 167.89 m2 for example.

I found a Lisp that puts field area values for multiple polylines in the middle of the polyline. Everything was great, until it turned out that when checking my file that government clerk clicks on a polyline, and check to see if the digits in properties tab match whatever is written in the middle of polyline in the requested format.

As in she sees in properties 123456.7890 (she has LUPREC 4), my field value has to show 123.45. She basically just cuts off the rest. Ridiculous right? I was also annoyed, that's not mathematically correct! I guess reason is that you don't want to write to a client/government amount of meters more than there actually is, so better to round down....

So the field value has to match the properties digits, but in a format of meters with two decimals.

Use trunc, and you're good?

I bumped into that annoying polyline that SHOWS IN PROPERTIES 1328100 with ANY LUPREC. But trunc function with needed to me formatting makes it into 132.80. Because the internal value is 1328099.99999999. So properties ROUND it in any LUPREC. Thus trunc doesn't work because the value in properties is ROUNDED already. 

The dwg I've sent - I didn't explain well what's there. There are multiple same polylines, the ones that are around the only one with field. The field was me trying to make the area smaller and see at when point do properties round the value.

Why same polylines? Because we have 4 identical apartments! 

So check out the polylines around. I've sent multiple screenshots showing, how trunc field with correct precision shows different values, and how it's different then what properties show....

I hope now it's more clear.

Since the clerk who checks has LUPREC 4, I'm looking for a way to round the internal value after 4th decimal.

[yael.vsh]

It looks like you marked something as a solution.

There was NO solution as of yet in this thread.

Is there a way to unmark it?

Thank you!

[cadffm]

I will open your last file later, but one thing i want to comment now:

1. NOBODY have Luprec4 for checking,

    Except he/she/it works in another file or changed the current setting.

    Luprec&Auprec a file saved variables.

[yael.vsh]

I hear. So we use LUPREC 4 anyways, that's why it's how she checks. In any case, it doesn't matter, as the fields use the internal value anyways. But thank you!

[cadffm]

>"It looks like you marked something as a solution.

That's right, it was just a mistake (while working on a android mobile. Autodesk Forum layout is not perfect designed for it. One of the whorst thing is the place&size for the [solution] Button i have.

Correct a few seconds later.

>"There was NO solution as of yet in this"

I guess there is, but this has nothing to do with my wrong 'solution mark.

Thx

[cadffm]

---

@yael.vsh wrote:

I hear. So we use LUPREC 4 anyways, that's why it's how she checks. In any case, it doesn't matter, as the fields use the internal value anyways. But thank you!

---

If someone try to check *whatever*, use Luprec8 (always. Why should i use less precision for GUI informations?)

But ok, 4.

I can not see a problem with both offered variants of fieldcodes

the simple&directly object->are->decimal->2decimal precicion and multiplied with 0.00001 works

132.81

also Z9E3zK5E formular works (for the nested area field, use 2decimal placed precision)

1328100.000000/10000-0.005

= 132.81

_

The real problem is the one who tests, or the method.
Everything else can be done.

[yael.vsh]

The solution worked for those polylines, but didn't for this one.

It has area of 63999.99999999

But in LUPREC 4 shows 64000..

Obviously subtracting 0.005 will then round it down to nearest....

The one who checks is the problem, but I have no control over them 🙂 Have to work with it.

[cadffm]

Yes, for the formular solution(green) it is better to -0.0005

depending on how large is the source value..

but also the prefered simple solution workes (magenta; object area precision = 2, factor 0.0001)

and this should be the way that works generally better

Or?

[yael.vsh]

Thanks a lot.

It looks great. I like the idea of just drawing a line to check. Didn't think of it.

Sending screenshots where those solutions DO NOT work...:(

Thanks

[cadffm]

Now you know all,

work with it..

If one means there is an issue ..

Teach the one with the gap of math rounding & acad knowledge,

or don't use fields & dimensions (not really an option, or)

Nothing more to explore, wish you the best

[yael.vsh]

Thank you everyone for support.

So I've tried the suggested solution and saw that they don't work - and cannot work. Formula field doesn't use the defined precision value of nested field, it uses the internal value.

I basically had a task or both rounding AND rounding down a number at different points.

Number 1238099.99999999 had to be rounded after 4th decimal (for Luprec 4)and then truncated (or subtracting 0.5 in needed scale) after 5th digit.

Since rounding mathematically correct is basically an if statement, subtracting or adding a certain number couldn't be a substitute as it is in rounding down.

I've decided to go back to the formula that worked for me and send the file in Luprec 0 (thank you for clarifying that luprec setting is unique to file, not the machine that the file is opened on).

The formula was the following (with ibj id changing)

"%<\\AcExpr (trunc(round(%<\\AcObjProp Object(%<\\_ObjId " (LM:objectid (vlax-ename->vla-object ent)) ">%).Area \\f \">%)*0.01)) \\f \"%lu2%pr2%ps%ct8[0.01]\>%")))

The reason why it didn't work with Lupre=4-8, is because i would need to first multiply the number by 10000, or more accordingly and Autocad wouldn't let me. Why and how to avoid it? It basically was the core question of my post.

It only lets to multiply a number by up to a 1000, if rounding after.

Thank you all! 

If you find the answer to my question, I will be really glad.

[yael.vsh]

Meanwhile I just hope that the clerk will not send the file back saying that it must be with LUPREC 4

[ВeekeeCZ · Accepted solution]

I don't really understand your issue and don't want to. Not sure if solving the following issue solve your problem, but you can try it.

is because i would need to first multiply the number by 10000, or more accordingly and Autocad wouldn't let me. Why and how to avoid it? It basically was the core question of my post....

Obviously, the issue is that you reached the limit that the truncate can handle - that would be 32 bits long integer, which is 2^31 -1. Your precision is too high. 

What you can do, is use the math and lower the number. So you can split the number into part prior to decimal, and decimals itself.

trunc(1328099.9999)+(0.0001* trunc(10000*(1328099.9999-trunc(1328099.9999))))

HTH

[hak_vz]

@ВeekeeCZ

I rarely use fields but understand in general what they offer. My question may sound stupid but I've been told to always ask someone who knows how things work.

Will this expression produce correct result after every update?

If not then simple lisp function sounds like more applicable solution. Tracking connections between objects and information texts is easy to code.

[ВeekeeCZ]

Yes,  I posted that just to show a formula expression. That long number (a constant) should be replaced with field linked to some particular polyline and returns its area. When you change polyline's geometry, the REGEN will update the value.

So far so good. The right question is, whether this dynamic behavior is somehow useful in this case. I have my doubts about it, but it's up to @yael.vsh  to explain.

[yael.vsh]

Cool! I really liked that trick! It looks very promising. I think this would work! 

As far as I understand , I would need to switch second “trunc” in expression to “round”, so that I can round after 4th decimal, and then trunc the whole thing after 5th digit.

Thanks! I’ll try that!
will definitely be a pain in the neck to insert it into my lisp with so many fields,  but oh well! It’s well worth it.