On Monday, November 8, 2021 at 1:42:21 AM UTC-3, Python wrote:
> Richard Hertz wrote:

<snip>

> > To manage a 10E+93 number like you posted would require a FPU managing a mantissa of 309 bits plus K bits for
> > exponents > 330 bits per WORD. And such STUPID CPU/FPU will not exist in the foreseeable future.

> I do not have such a kind of CPU/FPU on my computer, nevertheless I have
> no problem to handle it:
>
> Python 3.9.1 (default, Feb 28 2021, 08:57:14)
> [Clang 10.0.0 (clang-1000.10.44.4)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> n =
> 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063
> >>> n
> 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063
> >>> n**2
> 1312113828498849932229320758034401000355582847523188331634145925427322671096362951678784037872850921563147446167249901263434405461542599743612957911324723242390723880078044530519111593969
>
> You seem quite illiterate in computing science, Richard.

Don't be an asshole, Phyton.

You know very well that I'm talking about "number crunching" FPUs, with 1 nanosec invested to add two 64-bits FP numbers or
integers in HARDWARE. Don't troll me with that shit about computers, which I used for almost 50 years (IBM 360, PDP8/11,
Burroughs), when the microprocessor wasn't even conceived.

I'm talking about DSPs that commands missiles flying at 3,000 Km/Hr (standard speed) or 2 times that. Not about an administrative
software that take minutes, hours, days to complete a recursive algorithm or to stop at the 100 million iteration.

If you want a large number, by SW, nobody is going to beat this record easily:

31,415,926,535,897 digits for the value of PI. It took 121 days for Google's virtual machines to reach the number.

The previous record, set by Peter Trueb in late 2016, was 22.4 trillion digits.

Pi dream: Google employee sets record for most digits calculated
Celebrate Pi Day with trillions of new pi digits.

https://www.cnet.com/news/pi-dream-googler-sets-record-for-most-digits-calculated/

"If you want to peruse the fruits of the pi triumph, Google Cloud has published the digits as disk snapshots, along with technical
details on the accomplishment. It's the perfect reading material for Pi Day."

On Sunday, November 7, 2021 at 11:31:28 PM UTC-3, Sylvia Else wrote:
> On 08-Nov-21 11:56 am, Richard Hertz wrote:
> > On Sunday, November 7, 2021 at 9:03:09 PM UTC-3, Al Coe wrote:
> >
> > <snip>
> >
> > Obviously, I touched a sensitive nerve on mathematicians, WHICH I never pretended to do.
> >
> > I have respect for the realm of PURE MATHEMATICS, which IS NOT the realm of APPLIED MATHEMATICS, got it?
> >
> > The ridiculous number that you posted probably has a perfect meaning in the fantasy world of pure math, NOT IN THE REAL WORLD.
> >
> > 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063, if fed to a PC,
> > is truncated to 114547537227949 . 10E+79 (15 decimal digits plus powers of 10).
> >
> > This is because a standard i3 FPU dedicates 50 bits to the mantissa and 14 bits to the exponent (signs included).
> >
> > And N decimal digits uses about 3.32.N bits.
> >
> > To manage a 10E+93 number like you posted would require a FPU managing a mantissa of 309 bits plus K bits for exponents > 330 bits
> > per WORD. And such STUPID CPU/FPU will not exist in the foreseeable future.
> >
> > As far as I know, the most advanced commercial/scientific computer operating today uses 128 bits CPU/FPU. And this is
> > UNALTERED for the last 30 YEARS, when IBM delivered his RISC RS/6000 in 1991.
> The fact that the CPU only has hardware instructions for such numbers
> doesn't mean that the software running on it is constrained by that limit..
>
> As for lack of meaning in the real world, the widely used public key
> encryption system RSA routinely uses calculations of numbers with a
> thousand or more bits, and every PC, Mac, and smartphone does this with
> no fuss at all, and without the users, including you apparently, being
> aware of it.
>
> Sylvia.

Sylvia, I've already replied to Python for the same thing. I didn't appreciate your sarcasm with the "apparently".

I was talking about HW floating point "number cruncher" units or FPU, which were sold as a separate unit for most PC since
it was developed by Intel as i387 (a FPU partner of the i386 line since 1988). After that it came i486/i487 until they were
integrated with the Pentium I, by 1993. Before that, and since the 8080 or 6502, the code was in software (eventually in
firmware of advanced uP). Now, most technical people take embedded FPU for granted, until their work require complex
algebraic math with more than 15 digits and start wondering what's wrong with the PC. Finally, and knowing what happens,
they have to resort to a double precision SW library (128 bits), which is considerably slower, specially in SW recursive loops.

You know what? For my studies on computer sciences, along with microelectronics development, I had the chance to LIVE
the timeline for different CPUs, uPs and DSP since the dawn of it, circa 1971. And my personal curiosity brought me to analyze
the chip internal architecture, with NDA signed with manufacturers. It lasted shortly, after learning about the innermost of 500,000
transistor's chips. I gave up after trying to follow the pace of developments, and Pentium I was the final stroke to abandon any
attempt to understand in detail the architecture. Only building blocks, and even that started to be over my head very quickly.
Today, with 1500 cores with 30 million transistors each, per chip, it's impossible for outsiders to understand such thing.

And I used most of them (It was necessary for my work in defense systems), and I mean EVERY uP AND EVERY DSP, since they
appeared and for 25 aditional years.

You may believe it or not but, during 1982, and as a hobby, I developed the code (firmware) for basic 32-bits IEEE FP to be
applied to an TI CPU, and it included the translation decimal-binary-decimal. It worked pretty well, considering that I did it in
my spare time.

In other order of things, and if you are interested, this is a list of the exact solutions found in a 400x483 matrix, with the
first odd integers. The data is arranged as: c, a, b. There are less than 40 solutions in 200,000 combinations (or 80, if you swap a and b).

It solves c = log₂ (4ab - 2a - 2b + 2) exactly.

1, 1, 1
2, 1, 2
4, 1, 8
4, 2, 3
5, 1, 16
6, 1, 32
6, 2, 11
6, 4, 5
7, 1, 64
8, 1, 128
8, 2, 43
8, 3, 26
8, 8, 9
9, 1, 256
9, 4, 37
10, 2, 171
10, 6, 47
10, 16, 17
11, 12, 45
12, 3, 410
12, 4, 293
12, 5, 228
12, 7, 158
12, 8, 137
12, 11, 98
12, 18, 59
12, 20, 53
12, 23, 46
12, 32, 33
14, 22, 191
14, 64, 65
15, 76, 109
16, 43, 386
16, 128, 129
18, 200, 329
18, 256, 257

Richard Hertz wrote:
> On Sunday, November 7, 2021 at 11:31:28 PM UTC-3, Sylvia Else wrote:
>> On 08-Nov-21 11:56 am, Richard Hertz wrote:
>>> On Sunday, November 7, 2021 at 9:03:09 PM UTC-3, Al Coe wrote:
>>>
>>> <snip>
>>>
>>> Obviously, I touched a sensitive nerve on mathematicians, WHICH I never pretended to do.
>>>
>>> I have respect for the realm of PURE MATHEMATICS, which IS NOT the realm of APPLIED MATHEMATICS, got it?
>>>
>>> The ridiculous number that you posted probably has a perfect meaning in the fantasy world of pure math, NOT IN THE REAL WORLD.
>>>
>>> 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063, if fed to a PC,
>>> is truncated to 114547537227949 . 10E+79 (15 decimal digits plus powers of 10).
>>>
>>> This is because a standard i3 FPU dedicates 50 bits to the mantissa and 14 bits to the exponent (signs included).
>>>
>>> And N decimal digits uses about 3.32.N bits.
>>>
>>> To manage a 10E+93 number like you posted would require a FPU managing a mantissa of 309 bits plus K bits for exponents > 330 bits
>>> per WORD. And such STUPID CPU/FPU will not exist in the foreseeable future.
>>>
>>> As far as I know, the most advanced commercial/scientific computer operating today uses 128 bits CPU/FPU. And this is
>>> UNALTERED for the last 30 YEARS, when IBM delivered his RISC RS/6000 in 1991.
>> The fact that the CPU only has hardware instructions for such numbers
>> doesn't mean that the software running on it is constrained by that limit.
>>
>> As for lack of meaning in the real world, the widely used public key
>> encryption system RSA routinely uses calculations of numbers with a
>> thousand or more bits, and every PC, Mac, and smartphone does this with
>> no fuss at all, and without the users, including you apparently, being
>> aware of it.
>>
>> Sylvia.
>
> Sylvia, I've already replied to Python for the same thing. I didn't appreciate your sarcasm with the "apparently".
>
> I was talking about HW floating point "number cruncher" units or FPU, which were sold as a separate unit for most PC since
> it was developed by Intel as i387 (a FPU partner of the i386 line since 1988). After that it came i486/i487 until they were
> integrated with the Pentium I, by 1993. Before that, and since the 8080 or 6502, the code was in software (eventually in
> firmware of advanced uP). Now, most technical people take embedded FPU for granted, until their work require complex
> algebraic math with more than 15 digits and start wondering what's wrong with the PC. Finally, and knowing what happens,
> they have to resort to a double precision SW library (128 bits), which is considerably slower, specially in SW recursive loops.
>
> You know what? For my studies on computer sciences, along with microelectronics development, I had the chance to LIVE
> the timeline for different CPUs, uPs and DSP since the dawn of it, circa 1971. And my personal curiosity brought me to analyze
> the chip internal architecture, with NDA signed with manufacturers. It lasted shortly, after learning about the innermost of 500,000
> transistor's chips. I gave up after trying to follow the pace of developments, and Pentium I was the final stroke to abandon any
> attempt to understand in detail the architecture. Only building blocks, and even that started to be over my head very quickly.
> Today, with 1500 cores with 30 million transistors each, per chip, it's impossible for outsiders to understand such thing.
>
> And I used most of them (It was necessary for my work in defense systems), and I mean EVERY uP AND EVERY DSP, since they
> appeared and for 25 aditional years.
>
> You may believe it or not but, during 1982, and as a hobby, I developed the code (firmware) for basic 32-bits IEEE FP to be
> applied to an TI CPU, and it included the translation decimal-binary-decimal. It worked pretty well, considering that I did it in
> my spare time.
>
> In other order of things, and if you are interested, this is a list of the exact solutions found in a 400x483 matrix, with the
> first odd integers. The data is arranged as: c, a, b. There are less than 40 solutions in 200,000 combinations (or 80, if you swap a and b).
>
> It solves c = log₂ (4ab - 2a - 2b + 2) exactly.
>
> 1, 1, 1
> 2, 1, 2
> 4, 1, 8
> 4, 2, 3
> 5, 1, 16
> 6, 1, 32
> 6, 2, 11
> 6, 4, 5
> 7, 1, 64
> 8, 1, 128
> 8, 2, 43
> 8, 3, 26
> 8, 8, 9
> 9, 1, 256
> 9, 4, 37
> 10, 2, 171
> 10, 6, 47
> 10, 16, 17
> 11, 12, 45
> 12, 3, 410
> 12, 4, 293
> 12, 5, 228
> 12, 7, 158
> 12, 8, 137
> 12, 11, 98
> 12, 18, 59
> 12, 20, 53
> 12, 23, 46
> 12, 32, 33
> 14, 22, 191
> 14, 64, 65
> 15, 76, 109
> 16, 43, 386
> 16, 128, 129
> 18, 200, 329
> 18, 256, 257

This is the MOST self-confidence problem you'll ever see in your life.
Gosh!

On 08-Nov-21 5:54 pm, Richard Hertz wrote:
> On Sunday, November 7, 2021 at 11:31:28 PM UTC-3, Sylvia Else wrote:
>> On 08-Nov-21 11:56 am, Richard Hertz wrote:
>>> On Sunday, November 7, 2021 at 9:03:09 PM UTC-3, Al Coe wrote:
>>>
>>> <snip>
>>>
>>> Obviously, I touched a sensitive nerve on mathematicians, WHICH I never pretended to do.
>>>
>>> I have respect for the realm of PURE MATHEMATICS, which IS NOT the realm of APPLIED MATHEMATICS, got it?
>>>
>>> The ridiculous number that you posted probably has a perfect meaning in the fantasy world of pure math, NOT IN THE REAL WORLD.
>>>
>>> 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063, if fed to a PC,
>>> is truncated to 114547537227949 . 10E+79 (15 decimal digits plus powers of 10).
>>>
>>> This is because a standard i3 FPU dedicates 50 bits to the mantissa and 14 bits to the exponent (signs included).
>>>
>>> And N decimal digits uses about 3.32.N bits.
>>>
>>> To manage a 10E+93 number like you posted would require a FPU managing a mantissa of 309 bits plus K bits for exponents > 330 bits
>>> per WORD. And such STUPID CPU/FPU will not exist in the foreseeable future.
>>>
>>> As far as I know, the most advanced commercial/scientific computer operating today uses 128 bits CPU/FPU. And this is
>>> UNALTERED for the last 30 YEARS, when IBM delivered his RISC RS/6000 in 1991.
>> The fact that the CPU only has hardware instructions for such numbers
>> doesn't mean that the software running on it is constrained by that limit.
>>
>> As for lack of meaning in the real world, the widely used public key
>> encryption system RSA routinely uses calculations of numbers with a
>> thousand or more bits, and every PC, Mac, and smartphone does this with
>> no fuss at all, and without the users, including you apparently, being
>> aware of it.
>>
>> Sylvia.
>
> Sylvia, I've already replied to Python for the same thing. I didn't appreciate your sarcasm with the "apparently".
>
> I was talking about HW floating point "number cruncher" units or FPU, which were sold as a separate unit for most PC since
> it was developed by Intel as i387 (a FPU partner of the i386 line since 1988). After that it came i486/i487 until they were
> integrated with the Pentium I, by 1993. Before that, and since the 8080 or 6502, the code was in software (eventually in
> firmware of advanced uP). Now, most technical people take embedded FPU for granted, until their work require complex
> algebraic math with more than 15 digits and start wondering what's wrong with the PC. Finally, and knowing what happens,
> they have to resort to a double precision SW library (128 bits), which is considerably slower, specially in SW recursive loops.

Why? If you actually had the understanding you claim, then you would
have know already that the precision available from HW floating point
units is completely irrelevant to the topic under discussion.

Sylvia.

On Monday, November 8, 2021 at 4:41:40 AM UTC-3, Sylvia Else wrote:
> On 08-Nov-21 5:54 pm, Richard Hertz wrote:
> > On Sunday, November 7, 2021 at 11:31:28 PM UTC-3, Sylvia Else wrote:
> >> On 08-Nov-21 11:56 am, Richard Hertz wrote:
> >>> On Sunday, November 7, 2021 at 9:03:09 PM UTC-3, Al Coe wrote:
> >>>
> >>> <snip>
> >>>
> >>> Obviously, I touched a sensitive nerve on mathematicians, WHICH I never pretended to do.
> >>>
> >>> I have respect for the realm of PURE MATHEMATICS, which IS NOT the realm of APPLIED MATHEMATICS, got it?
> >>>
> >>> The ridiculous number that you posted probably has a perfect meaning in the fantasy world of pure math, NOT IN THE REAL WORLD.
> >>>
> >>> 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063, if fed to a PC,
> >>> is truncated to 114547537227949 . 10E+79 (15 decimal digits plus powers of 10).
> >>>
> >>> This is because a standard i3 FPU dedicates 50 bits to the mantissa and 14 bits to the exponent (signs included).
> >>>
> >>> And N decimal digits uses about 3.32.N bits.
> >>>
> >>> To manage a 10E+93 number like you posted would require a FPU managing a mantissa of 309 bits plus K bits for exponents > 330 bits
> >>> per WORD. And such STUPID CPU/FPU will not exist in the foreseeable future.
> >>>
> >>> As far as I know, the most advanced commercial/scientific computer operating today uses 128 bits CPU/FPU. And this is
> >>> UNALTERED for the last 30 YEARS, when IBM delivered his RISC RS/6000 in 1991.
> >> The fact that the CPU only has hardware instructions for such numbers
> >> doesn't mean that the software running on it is constrained by that limit.
> >>
> >> As for lack of meaning in the real world, the widely used public key
> >> encryption system RSA routinely uses calculations of numbers with a
> >> thousand or more bits, and every PC, Mac, and smartphone does this with
> >> no fuss at all, and without the users, including you apparently, being
> >> aware of it.
> >>
> >> Sylvia.
> >
> > Sylvia, I've already replied to Python for the same thing. I didn't appreciate your sarcasm with the "apparently".
> >
> > I was talking about HW floating point "number cruncher" units or FPU, which were sold as a separate unit for most PC since
> > it was developed by Intel as i387 (a FPU partner of the i386 line since 1988). After that it came i486/i487 until they were
> > integrated with the Pentium I, by 1993. Before that, and since the 8080 or 6502, the code was in software (eventually in
> > firmware of advanced uP). Now, most technical people take embedded FPU for granted, until their work require complex
> > algebraic math with more than 15 digits and start wondering what's wrong with the PC. Finally, and knowing what happens,
> > they have to resort to a double precision SW library (128 bits), which is considerably slower, specially in SW recursive loops.
> Why? If you actually had the understanding you claim, then you would
> have know already that the precision available from HW floating point
> units is completely irrelevant to the topic under discussion.
>
> Sylvia.

It's derived from a discussion with rotchm about the ability of Excel to deal with larger numbers, that's all.

On Sunday, November 7, 2021 at 10:43:19 AM UTC-3, rotchm wrote:

It derived from my analysis about how far can you go with Excel, limited by the FPU in any PC instead of a program in any language
that skip the use of the microhardware in any modern CPU.

You can model a "virtual ALU" with as many bits as you want, by pure software, to avoid the use of the internal FPU of any uP.
Don't make this issue bigger than it is. This started when I replied your "challenge" with what I thought could be useful, nothing else.

Richard Hertz <hertz778@gmail.com> wrote:
> On Sunday, November 7, 2021 at 9:03:09 PM UTC-3, Al Coe wrote:
>
> <snip>
>
> Obviously, I touched a sensitive nerve on mathematicians, WHICH I never pretended to do.
>
> I have respect for the realm of PURE MATHEMATICS, which IS NOT the realm
> of APPLIED MATHEMATICS, got it?
>
> The ridiculous number that you posted probably has a perfect meaning in
> the fantasy world of pure math, NOT IN THE REAL WORLD.
>
> 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063,
> if fed to a PC,
> is truncated to 114547537227949 . 10E+79 (15 decimal digits plus powers of 10).

It’s adorable that if a number is beyond what Excel can present then it’s
not worth talking about, according to you.

Robert Winn remarked here once that for his welding work, he never need a
length measurement more precise than a tape measure, and therefore nobody
needs any better. Congrats, you’re in the same class as a welder in terms
of physics.

>
> This is because a standard i3 FPU dedicates 50 bits to the mantissa and
> 14 bits to the exponent (signs included).
>
> And N decimal digits uses about 3.32.N bits.
>
> To manage a 10E+93 number like you posted would require a FPU managing a
> mantissa of 309 bits plus K bits for exponents > 330 bits
> per WORD. And such STUPID CPU/FPU will not exist in the foreseeable future.
>
> As far as I know, the most advanced commercial/scientific computer
> operating today uses 128 bits CPU/FPU. And this is
> UNALTERED for the last 30 YEARS, when IBM delivered his RISC RS/6000 in 1991.
>
> I don't deny that a 1024 bits CPU can be built FOR SPECIAL PURPOSES. I
> don't have the slightest doubt about it.
> Using the monstrous power of PGA today, you COULD device 8 x 128 word
> sliced CPU in a single chip, managing mantissas of
> 900 bits (aprox. 300 decimal digits), if you want, have the money, the
> time and the purpose.
>
> So, deal with this fact: with a 128 bits CPU, you can manage no more than
> 30 decimal digits for a mantissa. 40 decimal digits
> if you use it in integer mode. And that's all.
>
> For the rest of the problems with precision above 40 decimal digits, use
> an abacus and tell me how did it work for you.
>
> OR, you can expend your time using decomposition by factoring large
> numbers in products of smaller numbers. There are
> a huge amount of solutions developed in the XX century, including the use
> of logarithms in-between.
>
> Now, don't be so defensive, as if I called names to your mother. Live and
> let live OR deal with a confrontation.
>
> I don't like confrontations unless the other part is calling a fight. Is
> that what happens with you and the other one?
>
>
>

--
Odd Bodkin -- maker of fine toys, tools, tables

On Monday, November 8, 2021 at 12:18:13 AM UTC-5, Richard Hertz wrote:
> On Monday, November 8, 2021 at 1:42:21 AM UTC-3, Python wrote:

> > You seem quite illiterate in computing science, Richard.
> Don't be an asshole, Phyton.
>
> You know very well that I'm talking about "number crunching" FPUs, with 1 nanosec invested to add two 64-bits FP numbers or
> integers in HARDWARE.

Why are you forcing yourself to be limited by the registers of the hardware?
Code or algorithms are hard-coded and soft coated into computers. And you want to *only* use the hard-coded algo's?
The algos can go way beyond 64 or 128 or 256....or 1024 bit registers. Whay are you chosing to limit yourself to the 64 (or less) ?

> 31,415,926,535,897 digits for the value of PI. It took 121 days for Google's virtual machines to reach the number.
> The previous record, set by Peter Trueb in late 2016, was 22.4 trillion digits.

And they used algos that went way beyond 64 or 128 or 256....or 1024 bit registers.
Pytho's algo to find

n= 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063 or
n**2 used algos that went way beyond 64 or 128 or 256....or 1024 bit registers.

Even my old TI calculator handles this n and n**2.

So what we are asking you is why are you limiting yourself to a mere 64-bit? When your computers, even your old computers, can go way beyond that if you use appropriate code?

Sylvia Else wrote:

>> As far as I know, the most advanced commercial/scientific computer
>> operating today uses 128 bits CPU/FPU. And this is UNALTERED for the
>> last 30 YEARS, when IBM delivered his RISC RS/6000 in 1991.
>
> The fact that the CPU only has hardware instructions for such numbers
> doesn't mean that the software running on it is constrained by that
> limit.

Idiot, if the code instruction is selected by the compile faster, it is
selected. But there are no designated FPU nowadays, but its instruction
code is merged into the code instruction block.

rotchm wrote:

>> > You seem quite illiterate in computing science, Richard.
>> Don't be an asshole, Phyton.
>>
>> You know very well that I'm talking about "number crunching" FPUs, with
>> 1 nanosec invested to add two 64-bits FP numbers or integers in
>> HARDWARE.
>
> Why are you forcing yourself to be limited by the registers of the
> hardware?

he is talking about speed, you fucking cretin. The instruction code works
only on local hardware registers, usually 64 bits.

Richard Hertz wrote:

> You can model a "virtual ALU" with as many bits as you want, by pure
> software, to avoid the use of the internal FPU of any uP.
> Don't make this issue bigger than it is. This started when I replied
> your "challenge" with what I thought could be useful, nothing else.

you can't avoid. It's burn fixed into the instruction code. Behind the
scenes, it's very hard to anticipate which instruction will be selected.

On Monday, November 8, 2021 at 11:09:11 AM UTC-3, rotchm wrote:
> On Monday, November 8, 2021 at 12:18:13 AM UTC-5, Richard Hertz wrote:
> > On Monday, November 8, 2021 at 1:42:21 AM UTC-3, Python wrote:
>
> > > You seem quite illiterate in computing science, Richard.
> > Don't be an asshole, Phyton.
> >
> > You know very well that I'm talking about "number crunching" FPUs, with 1 nanosec invested to add two 64-bits FP numbers or
> > integers in HARDWARE.
> Why are you forcing yourself to be limited by the registers of the hardware?
> Code or algorithms are hard-coded and soft coated into computers. And you want to *only* use the hard-coded algo's?
> The algos can go way beyond 64 or 128 or 256....or 1024 bit registers. Whay are you chosing to limit yourself to the 64 (or less) ?
> > 31,415,926,535,897 digits for the value of PI. It took 121 days for Google's virtual machines to reach the number.
> > The previous record, set by Peter Trueb in late 2016, was 22.4 trillion digits.
> And they used algos that went way beyond 64 or 128 or 256....or 1024 bit registers.
> Pytho's algo to find
>
> n= 1145475372279495990836197021764032073310423825887743413516609392898052691867124856815578465063 or
> n**2 used algos that went way beyond 64 or 128 or 256....or 1024 bit registers.
>
> Even my old TI calculator handles this n and n**2.
>
> So what we are asking you is why are you limiting yourself to a mere 64-bit? When your computers, even your old computers, can go way beyond that if you use appropriate code?

Well, clearly there is an attempt to find any excuse to start a fight. The objective is the fight itself, not the reasons than brought
something innocuous (like an stupid formula I derived to use in Excel) vs. the inability for Excel to manage numbers with more
than 15 decimal digits.

I've tried since my first post here, to talk about the capability of Excel to manage an N x M matrix without CRASHING or FAILING, because:

1) The memory, consumption and filing increases with N² if N = M. For 64 bits number it goes from

for N = 10,000 , 100 million active cells and 800 MB files. Time to compute: about 1 min; time to save file: about 3 min.
for N = 20,000 . 400 million active cells and 3200 MB files. Time to compute: about 3 min; time to save file: about 10 min.
for N > 20,000 , the system become unstable and can crash or enter in a forever loop.

2) The incapacity of the CPU to manage numbers greater than 999,999,999,999,999 if I decide to star exploring the region of 10E+16.

The above points are the reasons behind the discussion on using Excel to make the job.

And I have to tell you than I used an algorithm to detect matches in an arbitrary N x M matrix. And it's very simple.

As the formula that I gave to you:

=SI((LOG((4*$B385*C$2-2*$B385-2*C$2+2);2)-TRUNCAR(LOG((4*$B385*C$2-2*$B385-2*C$2+2);2)))=0;LOG((4*$B385*C$2-2*$B385-2*C$2+2);2);"")

generates BLANK ("") CELLS unless an exact value of c is found, then, per each cell and row, by using a simple formula:

=SUMA(D2:D1003)-D2, placed in D1 gives ZERO (no solutions found) or any positive value if one or many "c" were found.

Applying it to every column in a 1000x1000 matrix and a similar on any row (on the top row A=1 and on the column A) allows,
using a 2nd. page, to extract a and b for any existing value of c.

I enjoy transforming programs into cascade of sheets in Excel, with proper algorithms, because in the end most SW problems
can be replaced by tables and two elementary commands: IF..THEN and ON...GOTO. And this come from the beggining of times.

Obviously, I'm digressing, but I like the general subject.

On other hand, I was thinking about my original post, with the formulae:

(2a - 1).(2b - 1) = 2ᶜ - 1
c = log₂ (4ab - 2a - 2b + 2)

If you use (2a + 1).(2b - 1) = 2ᶜ - 1, it gives

c = 1+ log₂ (2ab - a + b)

If you make a = b and a = 2ᵏ

c = 2+ log₂ (a²) = 2 + 2k

Making c = 2N (to be sure it's an even integer)

k = N -1 (both integers)

It allows to analyze the boundaries of half the matrix M x M and see the behavior for BIG values of a.

Maybe, formulae can be developed to find/count values of c between a = 2ᵏ⁻¹ and a = 2ᵏ, and the values of b. I don't know.

Anyways, it's a very complex problem for a general solution with any arbitrary space (a, b), being them very large numbers.

This is where I stop going any further. Infinitely large numbers are not my passion.

Op 08-nov.-2021 om 17:25 schreef Richard Hertz:

> Well, clearly there is an attempt to find any excuse to start a
> fight. The objective is the fight itself,
Exactly the reason why you're here.
And they all stepped right in your turd.
What a bunch of children you found here.
Congratulations!

Dirk Vdm

On Monday, November 8, 2021 at 2:06:27 PM UTC-3, Dirk Van de moortel wrote:
> Op 08-nov.-2021 om 17:25 schreef Richard Hertz:
> > Well, clearly there is an attempt to find any excuse to start a
> > fight. The objective is the fight itself,
> Exactly the reason why you're here.
> And they all stepped right in your turd.
> What a bunch of children you found here.
> Congratulations!
>
> Dirk Vdm

Well, then let this shit become interesting:

Fermat's Last Theorem, formulated in 1637, states that no three distinct positive integers a, b, and c can satisfy the equation

aⁿ + bⁿ = cⁿ

if n is an integer greater than two (n > 2). The only known solution is 3, 4, 5 for n = 2. Forget n = 1.

Anyone want to attempt to prove or disproof it (except for using Andrew Wiles approach)?

On Monday, November 8, 2021 at 2:06:27 PM UTC-3, Dirk Van de moortel wrote:

<snip>

> Exactly the reason why you're here.
> And they all stepped right in your turd.
> What a bunch of children you found here.
> Congratulations!

My reason to be here is to beat the crappy Einstein's theories and relativity itself and, if I can, show the imbecilities embedded into both.

So far, I'm going OK for applications on Earth's neighborhood.

Now, I'm going to prove that the charlatan fudged his paper about Mercury's and light's deflection (and cheated and hacked).

So far, so good.

Then, it will follow other stupid validations in the last decades and the utter-stupid pseudo-science of cosmology, BBT and GR
upgrades in the middle of the once serious field of astronomy (up to Hubble's times).

Richard Hertz wrote:

> This is where I stop going any further. Infinitely large numbers are not
> my passion.

great, can you do this in excel?

Pi =
3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611195909216420198938095257201065485863279

Op 08-nov.-2021 om 18:33 schreef Richard Hertz:
> On Monday, November 8, 2021 at 2:06:27 PM UTC-3, Dirk Van de moortel wrote:
>
> <snip>
>
>> Exactly the reason why you're here.
>> And they all stepped right in your turd.
>> What a bunch of children you found here.
>> Congratulations!
>
> My reason to be here is to

.... have fights with the other kids.
And you are very successful at it.
Congratulations.

Dirk Vdm

On Monday, November 8, 2021 at 9:33:29 AM UTC-8, Richard Hertz wrote:
> On Monday, November 8, 2021 at 2:06:27 PM UTC-3, Dirk Van de moortel wrote:
> <snip>
> > Exactly the reason why you're here.
> > And they all stepped right in your turd.
> > What a bunch of children you found here.
> > Congratulations!
> My reason to be here is to showcase my imbecilities embedded into my demented brain

Agreed

On Monday, November 8, 2021 at 2:44:08 PM UTC-3, Gregor Bicha wrote:

<snip>

> great, can you do this in excel?
>
> Pi =
> 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611195909216420198938095257201065485863279

Sure. Watch:

3.1415926535897
+ 0.932384626433832E-15
+ 0.795028841971693E-30
+ 0.993751058209749E-45
+ 0.445923078164062E-60
+ 0.862089986280348E-75
+ 0.253421170679821E-90
+ 0.480865132823066E-105
+ 0.470938446095505E-120
+ 0.822317253594081E-135
+ 0.284811174502841E-150
+ 0.027019385211055E-165
+ 0.596446229489549E-180
+ 0.303819644288109E-195
+ 0.756659334461284E-210
+ 0.756482337867831E-225
+ 0.652712019091456E-240
+ 0.485669234603486E-255
+ 0.104543266482133E-270
+ 0.936072602491412E-285
+ 0.737245870066063E-300
+ 0.155881748815209E-315
+ 0.209628292540917E-330
+ 0.153643678925903E-345
+ 0.600113305305488E-360
+ 0.204665213841469E-375
+ 0.519415116094330E-390
+ 0.572703657595919E-405
+ 0.530921861173819E-420
+ 0.326117931051185E-435
+ 0.480744623799627E-450
+ 0.495673518857527E-465
+ 0.248912279381830E-480
+ 0.119491298336733E-495
+ 0.624406566430860E-510
+ 0.213949463952247E-525
+ 0.371907021798609E-540
+ 0.437027705392171E-555
+ 0.762931767523846E-570
+ 0.748184676694051E-585
+ 0.320005681271452E-600
+ 0.635608277857713E-615
+ 0.427577896091736E-630
+ 0.371787214684409E-645
+ 0.012249534301465E-660
+ 0.495853710507922E-675
+ 0.796892589235420E-690
+ 0.199561121290219E-705
+ 0.608640344181598E-720
+ 0.136297747713099E-735
+ 0.605187072113499E-750
+ 0.999983729780499E-765
+ 0.510597317328160E-780
+ 0.963185950244594E-795
+ 0.553469083026425E-810
+ 0.223082533446850E-825
+ 0.352619311881710E-840
+ 0.100031378387528E-855
+ 0.865875332083814E-870
+ 0.206171776691473E-885
+ 0.035982534904287E-900
+ 0.554687311595628E-915
+ 0.638823537875937E-930
+ 0.519577818577805E-945
+ 0.321712268066130E-960
+ 0.019278766111959E-975
+ 0.092164201989380E-990
+ 0.952572010654858E-1005
+ 0.63279E-1020

Richard Hertz wrote:

> On Monday, November 8, 2021 at 2:44:08 PM UTC-3, Gregor Bicha wrote:
>
> <snip>
>
>> great, can you do this in excel?
>>
>> Pi =
>>
3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611195909216420198938095257201065485863279
>
> Sure. Watch:
> 3.1415926535897 + 0.932384626433832E-15 + 0.795028841971693E-30 +
> 0.554687311595628E-915 + 0.638823537875937E-930 + 0.519577818577805E-945
> + 0.321712268066130E-960 + 0.019278766111959E-975 +
> 0.092164201989380E-990 + 0.952572010654858E-1005 + 0.63279E-1020

you are a highly intelligent man, the last line tells me you copied the
numbers from my line. Do it with 2048 decimals. And give the formula.

Richard Hertz <hertz778@gmail.com> wrote:
> On Monday, November 8, 2021 at 2:06:27 PM UTC-3, Dirk Van de moortel wrote:
>> Op 08-nov.-2021 om 17:25 schreef Richard Hertz:
>>> Well, clearly there is an attempt to find any excuse to start a
>>> fight. The objective is the fight itself,
>> Exactly the reason why you're here.
>> And they all stepped right in your turd.
>> What a bunch of children you found here.
>> Congratulations!
>>
>> Dirk Vdm
>
> Well, then let this shit become interesting:
>
> Fermat's Last Theorem, formulated in 1637, states that no three distinct
> positive integers a, b, and c can satisfy the equation
>
> aⁿ + bⁿ = cⁿ
>
> if n is an integer greater than two (n > 2). The only known solution is
> 3, 4, 5 for n = 2. Forget n = 1.
>
> Anyone want to attempt to prove or disproof it (except for using Andrew Wiles approach)?
>
>

The beauty of Andrew Wiles’ approach is that it answers the question
unequivocally, without a brute force computational answer.

A notable but exceedingly rare exception is the four-color theorem.

--
Odd Bodkin — Maker of fine toys, tools, tables

On Monday, November 8, 2021 at 4:15:41 PM UTC-3, Gregor Bicha wrote:

<snip>

> > Sure. Watch:
> > 3.1415926535897 + 0.932384626433832E-15 + 0.795028841971693E-30 +
> > 0.554687311595628E-915 + 0.638823537875937E-930 + 0.519577818577805E-945
> > + 0.321712268066130E-960 + 0.019278766111959E-975 +
> > 0.092164201989380E-990 + 0.952572010654858E-1005 + 0.63279E-1020
> you are a highly intelligent man, the last line tells me you copied the
> numbers from my line. Do it with 2048 decimals. And give the formula.

Einstein, the fucker peacock, used to say by 1907: "You do the trick, but you are not obliged to show derivations or original sources,
because I say so. I'm not going to provide you proofs of fudging AND plagiarism. I have a career to develop with this shit".

Ask to Dono, the reptilian lifeform who worship Einstein (as most do, here) to provide a solution. After all, he's a BsC in Mathematics
(he claims) and he has his famous Wolfram Mathematica software, which he used here extensively. Not Excel or MATLAB.

On Monday, November 8, 2021 at 2:38:38 PM UTC-5, Richard Hertz wrote:
> On Monday, November 8, 2021 at 4:15:41 PM UTC-3, Gregor Bicha wrote:

You replied to the troll. You got got. I thought you would be smarter than that.
Since you are entertaining a troll, I will report you as spam.

On Monday, November 8, 2021 at 1:51:51 PM UTC-5, Richard Hertz wrote:
> On Monday, November 8, 2021 at 2:44:08 PM UTC-3, Gregor Bicha wrote:

Since you are entertaining a troll, I will report you as spam. I incite others to do the same.

Richard Hertz wrote:

>> you are a highly intelligent man, the last line tells me you copied the
>> numbers from my line. Do it with 2048 decimals. And give the formula.
>
> Einstein, the fucker peacock, used to say by 1907: "You do the trick,
> but you are not obliged to show derivations or original sources, because
> I say so. I'm not going to provide you proofs of fudging AND plagiarism.
> I have a career to develop with this shit".
>
> Ask to Dono, the reptilian lifeform who worship Einstein (as most do,
> here) to provide a solution. After all, he's a BsC in Mathematics (he
> claims) and he has his famous Wolfram Mathematica software, which he
> used here extensively. Not Excel or MATLAB.

give me a break, all are worshipping Einstine in here. Even a typo they
are protesting. It shows they are NOT good scientists. A good scientist
have to investigate the goods and the bad in Einstine. Good work. Keep it
up. I proved inconsistencies in relativity so many time, but they don't
care.

braindead crackpot idiot, rotchm evacuated:

> On Monday, November 8, 2021 at 2:38:38 PM UTC-5, Richard Hertz wrote:
>> On Monday, November 8, 2021 at 4:15:41 PM UTC-3, Gregor Bicha wrote:
>
> You replied to the troll. You got got. I thought you would be smarter
> than that.
> Since you are entertaining a troll, I will report you as spam.

report your stupid mother, you stinking uneducated crackpot troll. lol