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 
3 Likes
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.
1 Like
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?!
2 Likes
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. 
3 Likes
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.
2 Likes
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.
1 Like
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
2 Likes
I see what you mean. It automatically rounds the amount entered to 4 decimals in the calculated value and in the formula.
1 Like
Hi @Cheroodles,
This problem has been bothering me 
and I think I’ve solved it now. The trick is to put the whole formula into the one variable. This way, it doesn’t round off the numbers, only the result, which I’m sure isn’t a problem.
Please see the attached measurements file:
Trig to calculate armhole from bicep.sm2d (1.8 KB)
And… as an added bonus, you don’t need so many variables 
1 Like
I don’t know if that’s the case… the issue appears to lie in translatining the formulas… kudos if you have a way around the issue.
I think there is still going to be rounding issues as here’s what currently happens
loc = QLocale();// From system locale
bool ok = false;
const qreal d = loc.toDouble(nValues.at(i), &ok);
if (ok == false)
{
qDebug() << "Can't convert to double token"<<nValues.at(i);
continue;//Leave with out translation
}
loc = QLocale::c();// To internal locale
const QString dStr = loc.toString(d);// Internal look for number
newFormula.replace(nKeys.at(i), nValues.at(i).length(), dStr);
based on this line… the number gets translated and formatted back to a string using the default decimal places in the loc.toString()
const QString dStr = loc.toString(d);
In order to maintain the nunber from getting rounded to the default 6 places we have to force it to use 15 places when formatiing:
QString dStr = loc.toString(d, ‘f’, 15); // Internal look for number
And of course nothing is ever easy… to maintain a 15 decimal decimal dsiplay and not display E notation when you go past 6 places… we have to use the “f” format, but using that format will always display trailing zeros upto 15 places. So something like 10.125000000000000 is kind of annoying, so then we have to strip the trailing zeros:
dStr.remove(QRegularExpression(“0+$”)); // Remove trailing 0’s
Things is, while I was able to isplay 15 places, I was still getting rounding errors so where so I gave up as it’s just not worth the time to figure out where the error is coming from. As you can see the error seems to be off ± .000000000000001. 
2 Likes
I actually checked the formulas in Excel before putting them into the Variables Table and the results were the same except that Seamly rounded the result to 4 decimals, which I think is the most important, as long as the values inside the formula don’t get limited, so that the calculation is correct.
I don’t think the rounding of the result will make any difference in working with fabric.
1 Like
Definitely not. I’ve spent 2/3 of my life cutting just about every fabric imaginable, and I can pretty much say that using scissors / shears or a cutting machine you’d be lucky to be accurate to 1/32 of an inch. The only way to cut accurately is with a rotary cutter… or like we would do with certain smaller parts like pocket flaps - die cut on the clicker press. Then there’s the issue of how accurate can someone sew the parts you cut. That’s why I knew each of my employees sewing skills, and who could handle pieces that needed to be sewn accurately.
4 Likes