# [seqfan] Re: Worry about old sequence, A030077, paths in K_n

Brendan McKay Brendan.McKay at anu.edu.au
Mon Apr 4 06:33:46 CEST 2022

```What you are both missing is that the chord lengths are not square roots
of integers.

The problem of comparing weighted sums of square roots is completely
different from the problem of comparing weighted sums of sines, even
though they might coincide in some simple cases.

Now I have found that there are paths with different multisets but the
same length for n=18 and (subject to a conjecture) also for n=20.

Brendan.

On 4/4/2022 2:17 pm, israel at math.ubc.ca wrote:
> Maybe what you're missing is the word "squarefree".  Without it, you do
> have "trivial" equivalences, for example 2*sqrt(x) = sqrt(4*x) (which
> is exactly what gives your relation between the diagonal and edge of a
> hexagon).
>
> Cheers,
> Robert
>
> On Apr 3 2022, Allan Wechsler wrote:
>
>> I must be missing something very dumb. If the different diagonals are
>> all
>> incommensurate then why are we doing high-precision floating point
>> arithmetic at all, and why are we worrying about whether two "cyclic
>> polylines" might or might not be equal? If the diagonals are
>> incommensurate, all we need to know is the number of each kind of
>> diagonal.
>> That can't be right; there must be linear equivalences. (Note, for
>> example,
>> that the long diagonal of a hexagon is exactly twice an edge.)
>>
>> On Sun, Apr 3, 2022 at 3:16 PM <israel at math.ubc.ca> wrote:
>>
>>> There are no nontrivial equivalences: the square roots of squarefree
>>> integers are linearly independent over the rationals. See e.g.
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>> Robert
>>>
>>> On Apr 3 2022, Allan Wechsler wrote:
>>>
>>> > Are there any good examples of nontrivial equivalences? I'm
>>> thinking > that we might be able to *characterize* nontrivial
>>> equivalences, and > thus be able to prove two paths to be unequal in
>>> a sort of > "combinatorial" way, without resorting to extended
>>> arithmetic.
>>> >
>>> >On Sat, Apr 2, 2022 at 3:03 PM Sean A. Irvine <sairvin at gmail.com>
>>> wrote:
>>> >
>>> >> By the way, my code is using computable reals not floating-point,
>>> but
>>> >> it still faces the problem of deciding equality. I've been using 50
>>> >> decimal digits for this problem. I could easily rerun with higher
>>> >> precision, but I would like to remove the need for the approximation
>>> >> altogether.
>>> >>
>>> >> Sean.
>>> >>
>>> >>
>>> >> On Sun, 3 Apr 2022 at 02:04, David Applegate <david at bcda.us> wrote:
>>> >>
>>> >> > I worry about using floating point (extended or not) to check if
>>> >> > different sums of square roots are equal or not. Using finite
>>> >> > precision for this is extremely tricky This is a notoriously hard
>>> >> > problem in general. For example, to see that
>>> >> > sqrt(7)+sqrt(14)+sqrt(39)+sqrt(70)+sqrt(72)+sqrt(76)+sqrt(85) !=
>>> >> > sqrt(13)+sqrt(16)+sqrt(55)+sqrt(67)+sqrt(73)+sqrt(79) you already
>>> need
>>> >> > more than double-precision floating point (their difference is
>>> 10^-19,
>>> >> > see
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
>>> >> > ). There is a randomized polynomial time algorithm for testing
>>> >> > equality, but it isn't just compute the result to enough
>>> precision.
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
>>> >> >
>>> >> > -Dave
>>> >> >
>>> >> > On 4/2/2022 5:05 AM, Sean A. Irvine wrote:
>>> >> > > So far I can verify to A030077(14):
>>> >> > >
>>> >> > > 2022-04-02 21:46:54 1
>>> >> > > 2022-04-02 21:46:54 1
>>> >> > > 2022-04-02 21:46:54 1
>>> >> > > 2022-04-02 21:46:54 3
>>> >> > > 2022-04-02 21:46:54 5
>>> >> > > 2022-04-02 21:46:54 17
>>> >> > > 2022-04-02 21:46:54 28
>>> >> > > 2022-04-02 21:46:54 105
>>> >> > > 2022-04-02 21:46:54 161
>>> >> > > 2022-04-02 21:46:54 670
>>> >> > > 2022-04-02 21:46:55 1001
>>> >> > > 2022-04-02 21:47:00 2869
>>> >> > > 2022-04-02 21:47:58 6188
>>> >> > > 2022-04-02 22:01:58 26565
>>> >> > >
>>> >> > > I adapted my existing program for A007874 to this case.  I'm not
>>> sure
>>> >> > why I
>>> >> > > skipped over it before, but perhaps the dihedral group
>>> confused >> > > me.
>>> >> The
>>> >> > > program uses 50 digits of precision for the length >> > >
>>> determination. I
>>> >> feel
>>> >> > > like it should be possible to do this without any kind of >>
>>> > > precision
>>> >> > limit,
>>> >> > > but I don't have the time for that now. I'll leave it running
>>> >> overnight.
>>> >> > >
>>> >> > > I'll also start a run for A007874 itself which also has four
>>> >> > > additional terms with a(15) looking a little suspicious.
>>> >> > >
>>> >> > > Sean.
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > On Sat, 2 Apr 2022 at 16:22, Neil Sloane <njasloane at gmail.com>
>>> wrote:
>>> >> > >
>>> >> > >> To Seq Fans, The creator of an interesting sequence, A030077,
>>> >> > >> Daniel Gittelson, submitted 12 terms in 1999, and 4 more terms
>>> were
>>> >> > >> added in
>>> >> > 2007
>>> >> > >> by a former editor. Daniel G. wrote to me today, expressing
>>> doubt
>>> >> > the
>>> >> > >> 4 additional terms.
>>> >> > >>
>>> >> > >> He says he interrupted his study of sequences to pursue a
>>> medical
>>> >> > career,
>>> >> > >> but now that he is retired, he can return to combinatorics.
>>> >> > >>
>>> >> > >> It would be nice if someone could verify the terms! (It is
>>> not at
>>> >> > >> all obvious to me how to do this.)
>>> >> > >>
>>> >> > >> Neil Sloane
>>> >> > >>
>>> >> > >> --
>>> >> > >> Seqfan Mailing list -
>>> >> > >>
>>> >> > > --
>>> >> > > Seqfan Mailing list -
>>> >> >
>>> >> > --
>>> >> > Seqfan Mailing list -
>>> >> >
>>> >>
>>> >> --
>>> >> Seqfan Mailing list -
>>> >>
>>> >
>>> >--
>>> >Seqfan Mailing list -
>>> >
>>> >
>>>
>>> --
>>> Seqfan Mailing list -
>>>
>>
>> --
>> Seqfan Mailing list -