consider the case below: list=[[7,8,9],[1,2,3],[10,11,12],[4,5,6],[7,8,9],[10,11,12]] for simplicity, I have removed the decimal points here, but if you want to remove duplicates in this case it would be difficult to compare in case the list within the list are not properly rounded. remove_extra_points(list) => [[7, 8, 9], [1, 2, 3], [10, 11, 12], [4, 5, 6]] On Mon, 12 Feb 2024 at 22:24, Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > If you can round the arrays to a certain number all at once, comparing > them would be much neater and easier for many people. > > subtract and compare is probably better for speed right now, till you have > such a rounding solution not available inside openscad > > On Mon, 12 Feb 2024 at 22:02, Father Horton <fatherhorton@gmail.com> > wrote: > >> Why would this be better than the more usual (and faster) >> subtract-and-compare method? >> >> On Mon, Feb 12, 2024 at 10:27 AM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> You have a point here, I did not think about this in enough depth. >>> >>> but maybe you can achieve the same result by writing a better logic for >>> rounding. >>> >>> e.g. iteratively rounding a number from 1 less than the decimal point of >>> a number till you reach the decimal point you want. >>> >>> in the example 1.12344999999, if it is first rounded to 10 decimal it >>> will be 1.12345 and another step will make it 1.1234 >>> similarly 1.12345000001 if it is rounded to 10 decimal it will be >>> 1.12345 and so on. >>> >>> Now writing such logic in openscad may need some good skills, but I >>> think this should be the right logic. >>> >>> On Mon, 12 Feb 2024 at 12:52, Jordan Brown < >>> openscad@jordan.maileater.net> wrote: >>> >>>> On 2/10/2024 4:05 PM, Sanjeev Prabhakar via Discuss wrote: >>>> >>>> Maybe round a number to 4 or 5 decimal places and then comparison >>>> should work. >>>> >>>> E.g. >>>> round(2.0000001,4)==2 , should give "True" as result. >>>> >>>> >>>> No, it won't. >>>> >>>> If you're looking to compare to four decimal places, you would want >>>> >>>> 1.12344999999 >>>> >>>> and >>>> >>>> 1.12345000001 >>>> >>>> to compare equal, because they only differ by 0.00000000002, but the >>>> first will round to 0.1234 and the second will round to 0.1235. >>>> >>>> >>>> The "compare the absolute value of the difference" answer seems >>>> correct, except that to be general, if you're looking at floating point, >>>> you want to compare to some number of significant figures, not some number >>>> of decimal places. If you want to compare to six significant figures, and >>>> you're comparing numbers that are around 1, then you need to confirm that >>>> their difference is less than 0.000001. If you're comparing numbers that >>>> are around a million, then you need to confirm that their difference is >>>> less than 1. You can do that by comparing the absolute value of the >>>> difference to a fraction of one of the two numbers. >>>> >>>> But that breaks down when the value you are comparing against is zero, >>>> because there *are* no significant figures. >>>> >>>> It is also problematic - not wrong, but you could easily make errors - >>>> if the values that you are comparing are themselves the results of >>>> subtracting large nearly-equal numbers. Discussing single-precision >>>> floating point for easy numbers, if you subtract two numbers that are >>>> around a million and get a result of around 1, that result only has about >>>> two significant figures. Each of your two millions is plus or minus about >>>> 0.1, and (simplistically) those error bars add, so your result of around 1 >>>> is plus or minus 0.2; you should consider everything from 0.8 to 1.2 to be >>>> the same as 1. (I might be off by an order of magnitude there, but >>>> hopefully the idea comes across.) >>>> >>>> >>>>

echo(1/3*3);
echo(1 - 1/3*3);
echo(1/3*3 == 1);

ECHO: 1
ECHO: 0
ECHO: true

On 2/12/2024 1:11 AM, nop head via Discuss wrote: > My Casio calculator from the 1970's seems to round numbers perfectly. > So you can divide 1 by three and multiply by 3 to get one. I presume > it just calculates an extra digit and rounds. I wish OpenSCAD did the > same. > The operative words there are "seems to". OpenSCAD (at least on Windows) handles that case perfectly too. echo(1/3*3); echo(1 - 1/3*3); echo(1/3*3 == 1); yields ECHO: 1 ECHO: 0 ECHO: true The smallest integer where OpenSCAD doesn't get that right is 49. I'm pretty sure that the "store an extra digit and round" scheme will fail in *some* case, but I'm not enough of a mathematician and not enough of a floating point expert to predict what that case is.

And what happens if the lists have the same elements, but in different order? On Mon, Feb 12, 2024 at 11:18 AM Sanjeev Prabhakar via Discuss < discuss@lists.openscad.org> wrote: > consider the case below: > > list=[[7,8,9],[1,2,3],[10,11,12],[4,5,6],[7,8,9],[10,11,12]] > > for simplicity, I have removed the decimal points here, but if you want to > remove duplicates in this case it would be difficult to compare in case the > list within the list are not properly rounded. > > remove_extra_points(list) => [[7, 8, 9], [1, 2, 3], [10, 11, 12], [4, 5, > 6]] > > > On Mon, 12 Feb 2024 at 22:24, Sanjeev Prabhakar <sprabhakar2006@gmail.com> > wrote: > >> If you can round the arrays to a certain number all at once, comparing >> them would be much neater and easier for many people. >> >> subtract and compare is probably better for speed right now, till you >> have such a rounding solution not available inside openscad >> >> On Mon, 12 Feb 2024 at 22:02, Father Horton <fatherhorton@gmail.com> >> wrote: >> >>> Why would this be better than the more usual (and faster) >>> subtract-and-compare method? >>> >>> On Mon, Feb 12, 2024 at 10:27 AM Sanjeev Prabhakar < >>> sprabhakar2006@gmail.com> wrote: >>> >>>> You have a point here, I did not think about this in enough depth. >>>> >>>> but maybe you can achieve the same result by writing a better logic for >>>> rounding. >>>> >>>> e.g. iteratively rounding a number from 1 less than the decimal point >>>> of a number till you reach the decimal point you want. >>>> >>>> in the example 1.12344999999, if it is first rounded to 10 decimal it >>>> will be 1.12345 and another step will make it 1.1234 >>>> similarly 1.12345000001 if it is rounded to 10 decimal it will be >>>> 1.12345 and so on. >>>> >>>> Now writing such logic in openscad may need some good skills, but I >>>> think this should be the right logic. >>>> >>>> On Mon, 12 Feb 2024 at 12:52, Jordan Brown < >>>> openscad@jordan.maileater.net> wrote: >>>> >>>>> On 2/10/2024 4:05 PM, Sanjeev Prabhakar via Discuss wrote: >>>>> >>>>> Maybe round a number to 4 or 5 decimal places and then comparison >>>>> should work. >>>>> >>>>> E.g. >>>>> round(2.0000001,4)==2 , should give "True" as result. >>>>> >>>>> >>>>> No, it won't. >>>>> >>>>> If you're looking to compare to four decimal places, you would want >>>>> >>>>> 1.12344999999 >>>>> >>>>> and >>>>> >>>>> 1.12345000001 >>>>> >>>>> to compare equal, because they only differ by 0.00000000002, but the >>>>> first will round to 0.1234 and the second will round to 0.1235. >>>>> >>>>> >>>>> The "compare the absolute value of the difference" answer seems >>>>> correct, except that to be general, if you're looking at floating point, >>>>> you want to compare to some number of significant figures, not some number >>>>> of decimal places. If you want to compare to six significant figures, and >>>>> you're comparing numbers that are around 1, then you need to confirm that >>>>> their difference is less than 0.000001. If you're comparing numbers that >>>>> are around a million, then you need to confirm that their difference is >>>>> less than 1. You can do that by comparing the absolute value of the >>>>> difference to a fraction of one of the two numbers. >>>>> >>>>> But that breaks down when the value you are comparing against is zero, >>>>> because there *are* no significant figures. >>>>> >>>>> It is also problematic - not wrong, but you could easily make errors - >>>>> if the values that you are comparing are themselves the results of >>>>> subtracting large nearly-equal numbers. Discussing single-precision >>>>> floating point for easy numbers, if you subtract two numbers that are >>>>> around a million and get a result of around 1, that result only has about >>>>> two significant figures. Each of your two millions is plus or minus about >>>>> 0.1, and (simplistically) those error bars add, so your result of around 1 >>>>> is plus or minus 0.2; you should consider everything from 0.8 to 1.2 to be >>>>> the same as 1. (I might be off by an order of magnitude there, but >>>>> hopefully the idea comes across.) >>>>> >>>>> >>>>> _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

On 2/12/2024 9:18 AM, Sanjeev Prabhakar wrote: > consider the case below: > > list=[[7,8,9],[1,2,3],[10,11,12],[4,5,6],[7,8,9],[10,11,12]] > > for simplicity, I have removed the decimal points here, but if you > want to remove duplicates in this case it would be difficult to > compare in case the list within the list are not properly rounded. > >  remove_extra_points(list) => [[7, 8, 9], [1, 2, 3], [10, 11, 12], [4, > 5, 6]] > I don't think anybody doubts that there are cases where you want to do comparisons, and where arithmetic error is an issue for precise equality. The questions are whether there's anything to improve in the arithmetic so that precise equality *does* work, and what the math and syntax should be for an "almost exactly equal to" comparison.

I learned that comparing Floats (or Reals) for equality is something you DO NOT DO back in my FORTRAN IV days. Haven't done it since. Despite Jordan Brown's long but excellent explanation why not, it will still be on the wishlist for many people that the damn computer should be able to second guess what they mean, and not what it has calculated. <sigh> Especially in a language where there is no explicit distinction between int and real .. you do not know what goes on under the hood. Is "42" stored as an int or as 42.0? Don't get me started on autoconversion from strings to numbers. echo(43==43.0?"Yes":"No"); // Yes (somewhere a conversion is made from a definite 43, to a float approximation of 4.3x10^-1 to be able to do the comparison) FT1=43+1E-6;echo(FT1); // Echos the same "43" echo(43.0==FT1?"Yes":"No"); // "No", even though they seem the same. You might have made a calculation that you think resulted in 43.0, your echo proves it, but alas .. On Mon, 12 Feb 2024 at 18:18, Jordan Brown via Discuss < discuss@lists.openscad.org> wrote: > On 2/12/2024 1:11 AM, nop head via Discuss wrote: > > My Casio calculator from the 1970's seems to round numbers perfectly. So > you can divide 1 by three and multiply by 3 to get one. I presume it > just calculates an extra digit and rounds. I wish OpenSCAD did the same. > > > The operative words there are "seems to". > > OpenSCAD (at least on Windows) handles that case perfectly too. > > echo(1/3*3); > echo(1 - 1/3*3); > echo(1/3*3 == 1); > > yields > > ECHO: 1 > ECHO: 0 > ECHO: true > > The smallest integer where OpenSCAD doesn't get that right is 49. > I'm pretty sure that the "store an extra digit and round" scheme will fail > in *some* case, but I'm not enough of a mathematician and not enough of a > floating point expert to predict what that case is. > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

On 2/12/2024 8:27 AM, Sanjeev Prabhakar wrote: > e.g. iteratively rounding a number from 1 less than the decimal point > of a number till you reach the decimal point you want. > > in the example 1.12344999999, if it is first rounded to 10 decimal it > will be 1.12345 and another step will make it 1.1234 > similarly 1.12345000001 if it is rounded to 10 decimal it will be > 1.12345 and so on. So if you're rounding 1.49 to zero decimal places, you should first round it to 1.5 and then to 2? --- Rounding, at least straightforward rounding, has all the same issues that ordinary comparison does - they're just centered around the values that are halfway between your "final" values.  Which should be no surprise when you realize that rounding is just adding 0.5 and truncating.

On 2/12/2024 1:44 AM, Dan Perry via Discuss wrote: > Integer math is a feature not a bug.  The easiest way to check odd vs > even is: num % 2 == 0. Sure.  Integer arithmetic is great when you need integer arithmetic.  But it doesn't magically solve the problems that people have with floating point arithmetic.

On 2/12/2024 10:08 AM, Michael Möller wrote: >  I learned that comparing Floats (or Reals) for equality is something > you DO NOT DO back in my FORTRAN IV days. Haven't done it since. Yep. > Is "42" stored as an int or as 42.0? Yes.  Both.  Sort of. > echo(43==43.0?"Yes":"No");  // Yes (somewhere a conversion is made > from a definite 43, to a float approximation of 4.3x10^-1 to be able > to do the comparison) No.  They are exactly the same value, and they are both absolutely precise.  The problem arises only with non-integers.  Integers in the range -10^15 through 10^15, approximately, are represented precisely.  Larger integers start getting fuzz in their lower digits. It's exactly like in grade-school arithmetic.  You can add, subtract, and multiply integer values all you want, and everything will be fine.  It's division (and square root and trig and ...) that can introduce those obnoxious infinite-length values that can't be represented precisely. > FT1=43+1E-6;echo(FT1);  // Echos the same "43" > echo(43.0==FT1?"Yes":"No"); // "No", even though they seem the same. Correct.  There are two places in there that introduce errors: * First, and most obvious, is that echo() rounds to six or so places, and so the 1e-6 is dropped. * Second, the 1e-6, being derived from a negative power of 5, is an infinite repeating fraction and cannot be represented precisely. > You might have made a calculation that you think resulted in 43.0, > your echo proves it, but alas .. Yes.  If you really care, you should subtract the echoed result from the calculated result and look at the difference.  (No, there's no way to do that inside OpenSCAD.)