Hi there, I’m trying to create a pattern system that uses complex math equations using variables with very long digits, that need extended decimal places - 15 would be good. At the moment I can’t get correct results because the variables get truncated at about 9 places after the decimal point. It seems like an easy fix to increase the decimal places allowed on your end, but I’m not a software engineer, perhaps it’s more difficult than it seems. If possible, increasing the decimal places to 15 would really be appreciated. Thanks so much for the software, I’ve been loving it

Hey, welcome to Seamly!

I’m not sure what the point of that level of granularity would be. Even using Meter measurements, five decimal places is hundredths of a millimeter, which is ridiculously precise for use on just about anything.

I look forward to seeing what the Devs have to say about it, but I know they’ll be interested in some concrete examples of why the current limits just don’t cut it, unless its a floating point thing that can’t be changed without re-doing the whole kit-&-caboodle anyway.

Can you show some examples. Maybe you could use formulas instead of manually typing those numbers? Internally Seamly2D could eventually calculate more accuratly; perhaps only the gui is restricted to 9 digits?!

Yes… I would need to see examples.

As you can see I used 15 decimal places in a formula no probem.

Let me explain though what happens… The tools in Seamly2D all use formulas in QString format… the math parser will evaluate a formula to a value - usually a qreal ie a double. The display is the result of taking a value and converting it back to a QString… which is determined by 3 things - format, precision, and locale. For example - the default for converting to and from strings is format g and 6 decimal places.

So with a g format, a value string will display with 6 decimal places BEFORE it starts to display in exponential.

The 3rd thing is the locale… but for the most part the app uses Locale:c so it’s a non factor.

That being said… if you’ve been able to follow along… that value of .000000000000001 typed in the length field will reformat after the 6 (9th?) decimal place - so it display E notation.

BTW - The 9 decimal places is probably coming from the math parser as it formats the converted evaluated value. So whether it’s 6 or 9… the value is going to get chopped. So I would say at minimum the parser would need to be extended, if not also additional QStrings in tool code.

In any case not on my priorities list… as I see it - even an accuracy of 1mm is overkill for clothing.

Maybe try using E notation… for example I typed in .000000000000001 and it changed it to 1e-15.

Internally the accuracy is probably there… it’s just the display that is limited in decimal places with the QString format arguments - or as the case is the lack of resulting in the default precision.

Hi Douglas, Thanks for getting back to me. For more context, the calculations are to determine armscye circ, height, and width based on bicep circ. Here are the calculations:

Coefficients:

For g(b): a_g = -4.09616460e-06 b_g = 0.00045567144 c_g = -0.00913907428 d_g = 36.64168807

For w(b): a_w = 5.61797765e-06 b_w = -0.00101449275 c_w = 0.06376811594 d_w = 14.11884058

For h(b): a_h = -6.96864111e-06 b_h = 0.00101449275 c_h = -0.06292753623 d_h = 9.0

Perform prediction for g measurement: g_prediction = a_g * b^3 + b_g * b^2 + c_g * b + d_g

Perform prediction for w measurement: w_prediction = a_w * b^3 + b_w * b^2 + c_w * b + d_w

Perform prediction for h measurement: h_prediction = a_h * b^3 + b_h * b^2 + c_h * b + d_h

When I run this through python it’s correct, but not in Seamly, because of the truncated numbers.

It’s not the actual end result measurements used in the pattern that need to be that accurate, it’s the variables used in the calculations that have to be ridiculously accurate to get a good result. It’s a complex calculation initially created using AI to determine armscye circ, height, and width using bicep circ only. I posted an example below in response to Douglas if you want a look at it

I see what you mean. It automatically rounds the amount entered to 4 decimals in the calculated value and in the formula.