Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
The Claris Museum: The Vault of FileMaker Antiquities at Claris Engage 2025! ×

This topic is 7225 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Hi everyone,

This post isn't as complex as I'm making it look ... it's just that it uses a few different TOs and a few number calculations so I want to be sure everything you need is listed. Goal: Predict weight of package. Three weight factors: Product, Box (plus packing materials) and Literature (can be substantial also).

In Product table, Product X weight displays 24.58 (approx 1.5 lbs) and this is pulled into LineItems (based upon ProductID). Both BoxWeight and LitWeight are determined by the Rules table. Owner plugs in those figures (in one record) to default-enter the value. He then tweaks the Rules table to improve accuracy. Rules is joined to Contacts on X and Contacts is joined to Invoices on ContactID.

Problem: I can't get the final shipment weight (in Invoices) to display decimals, ie, fraction of a pound! Field format decimal 3 places still displays above (24.83) as 2.000 (for one Product X with 25 literature) when it's LineItem weight correctly displays 24.83. All fields involved are number. Here are my calculations. Can you see what is wrong on why I can't get partial pounds to show?

LineItems - Weight (Auto-Enter, Replace, Evaluate Always):

Case(not IsEmpty(ProductID; Products::Weight * Quantity + Literature * Rules::LitWeight; 0)

I use the ProductID to determine whether to bother calculating at all.

Invoices - TotalGrossWeight (unstored calculation):

Div(Sum ( LineItems::Weight ) + Rules::BoxWeight; 16)

For some reason, when I try to put 16.00 instead of 16, FM accepts it - but it reverts back to 16 flat! I don't understand why. Numbers plugged into Rules are: BoxWeight = 16.00 (boxes weigh 1 lb) and LitWeight = .01

Results: LineItem on product alone displays 24.58. LineItem on product with 25 literature displays 24.83. So far, so good. But the Invoice TotalGrossWeight set to General Format displays 2 and as fixed decimal 3, displays as 2.000. Even if I wrap it with Round(); 3 or SetPrecision(); 3 ... nothing I've tried works. crazy.gif

I think it has to do with the 16 refusing to format as 16.00. I assume Div() doesn't recognize fractions but I don't know how to correct the problem. My weak math skills are showing. Help please? And I'm also always interested on improving my calcs in general so please jump in.

LaRetta laugh.gif

Posted

Doesn't div always return whole numbers? / will return decimals won't it?

ex: x = 24.83 / 2

x = 12.415

but if you use div, you'll get 12.

maybe you might try using / instead of div.

if that doesn't work, i'll look at the math a little closer smile.gif

Just a thought.

hth,

sincerely,

J__

Posted

Okay! I read it was an integer but I thought Div() was now used in place of / in vs. 7. Not so? It seems that wrapping Div() with SetPrecision() should force the resultant calc to display 3 decimals. After all, I was using SetPrecision() and Round() outside of Div().

This calc produces 2.552 so you are certainly right - thank you! But why? I thought any division or multiplication happened BEFORE addition or subtraction. This calc forces addition before the division. Is THAT why it works? I just went through this issue with a date calc ... and I could have sworn (ooooops) that I understood it.

(Sum ( LineItems::Weight ) + Rules::BoxWeight) / 16

... because this produces 25.83 - wrong!

Sum ( LineItems::Weight ) + Rules::BoxWeight / 16

Give me User interface/GUI, data normalization/migration or Admin workflow any day over math. wink.gif

LaRetta

Posted

LaRetta said ... wrapping Div() with SetPrecision() should force the resultant calc to display 3 decimals. After all, I was using SetPrecision() and Round() outside of Div().

Doh! blush.gif Extending a result to 3 decimals which has FIRST been converted to an integer, returns an integer ... so forget my question about that part please. wink.gif

Posted

Hello LaRetta,

Regarding order of operations, your right: it's * / + -

but maybe the reason why it doesn't evaluate as you expect (as we would expect) is because Div() is not an operator but a function, i don't know if Filemaker sees Div() as an operator, according to the help on div() it doesn't say anything except that it's a function. but / is an operator so it will operate on that first unless you have parens around it to force it.

as for / replacing div(), I guess i missed that memo (grin) ... I'm not an fm guru, but i have programmed in a number of other languages and my experience has been that div() - or something like it is usually for integers and / will return decimal number.

for example in Pascal or Delphi, you have 5 div 2 // returns integer

and 5.0 / 2.0 returns a decimal (i'm simplifying it herer, but you get the idea)

Don't be hard on yourself, your math isn't bad at all.

hope that helps,

sincerely,

J__

This topic is 7225 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.