Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Say "twenty-three-skiddoo" to logout.


tech / sci.electronics.design / Re: high accuracy math library

SubjectAuthor
* high accuracy math libraryHul Tytus
+* Re: high accuracy math libraryjlarkin
|`- Re: high accuracy math libraryHul Tytus
+* Re: high accuracy math libraryMartin Brown
|`* Re: high accuracy math libraryJoe Gwinn
| `* Re: high accuracy math libraryMartin Brown
|  +* Re: high accuracy math libraryjlarkin
|  |+- Re: high accuracy math libraryRick C
|  |`* Re: high accuracy math libraryMartin Brown
|  | +* Re: high accuracy math libraryDon Y
|  | |`* Re: high accuracy math libraryjlarkin
|  | | `* Re: high accuracy math libraryDavid Brown
|  | |  `- Re: high accuracy math libraryClifford Heath
|  | +* Re: high accuracy math libraryDavid Brown
|  | |`* Re: high accuracy math libraryLasse Langwadt Christensen
|  | | +- Re: high accuracy math libraryDavid Brown
|  | | `* Re: high accuracy math librarywhit3rd
|  | |  `- Re: high accuracy math libraryDavid Brown
|  | +* Re: high accuracy math libraryjlarkin
|  | |+* Re: high accuracy math libraryDavid Brown
|  | ||`* Re: high accuracy math libraryLasse Langwadt Christensen
|  | || `- Re: high accuracy math libraryDavid Brown
|  | |+* Re: high accuracy math libraryMartin Brown
|  | ||+- Re: high accuracy math libraryJan Panteltje
|  | ||`* Re: high accuracy math libraryDavid Brown
|  | || `* Re: high accuracy math libraryJan Panteltje
|  | ||  +* Re: high accuracy math libraryPhil Hobbs
|  | ||  |`- Re: high accuracy math libraryJan Panteltje
|  | ||  +* Re: high accuracy math libraryjlarkin
|  | ||  |`- Re: high accuracy math libraryJan Panteltje
|  | ||  `- Re: high accuracy math libraryDecadentLinuxUserNumeroUno
|  | |`- Re: high accuracy math libraryPhil Hobbs
|  | `* Re: high accuracy math libraryPhil Hobbs
|  |  `- Re: high accuracy math libraryMartin Brown
|  `* Re: high accuracy math libraryJoe Gwinn
|   +* Re: high accuracy math libraryPhil Hobbs
|   |`- Re: high accuracy math libraryJoe Gwinn
|   `- Re: high accuracy math libraryMartin Brown
`- Re: high accuracy math libraryClifford Heath

Pages:12
Re: high accuracy math library

<ss3qph$pao$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88022&group=sci.electronics.design#88022

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!OIRGNq1ADRVRlWCMma5QPA.user.46.165.242.75.POSTED!not-for-mail
From: '''newsp...@nonad.co.uk (Martin Brown)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 13:26:09 +0000
Organization: Aioe.org NNTP Server
Message-ID: <ss3qph$pao$1@gioia.aioe.org>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org>
<vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
<ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org>
<6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="25944"; posting-host="OIRGNq1ADRVRlWCMma5QPA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: Martin Brown - Mon, 17 Jan 2022 13:26 UTC

On 16/01/2022 15:50, jlarkin@highlandsniptechnology.com wrote:
> On Sun, 16 Jan 2022 09:26:42 +0000, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 15/01/2022 17:58, jlarkin@highlandsniptechnology.com wrote:
>>> On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>
>>>> 32, 64 are native x87 and full SSE floating point support
>>>> 80 x87 only but GCC does it fairly well
>>>
>>> Power Basic has a native 80-bit float type and a 64-bit integer.
>>
>> I'm so impressed. NOT
>
> Of course not. The word BASIC triggers too much emotion, facts not
> required.

I don't have any problem with Basic. I sometimes use it as VBA dialect
in inside Excel to automate jobs I can't otherwise be bothered doing.

Ripping content authored by someone else as output by MS Office "save
for web" into a compact shape fit to go on a web page for instance!

> We had a couple of cases where we wanted to do a signal processing
> routine that processed an array of adc samples, on x86. My official
> programmer guys did it in gcc and I did it in Power Basic. Mine used
> subscripts in the most obvious loop and they used pointers. Mine ran
> 4x as fast. After a day of mucking with code and compiler switches,
> many combinations, they got within about 40%.

There is something wrong with how they are doing it then! One
dimensional arrays should be roughly equivalent performance in any
compiled language. C can do 1-D array indexing the same way as Basic.

C becomes messy when there are 2D or higher dimensional arrays since
that is implemented as a pointer to a pointer which does not cache well.
If they were using that array construct then they would be at a
disadvantage but it should not be by a factor of 4. Nothing like.

GCC is a lukewarm optimiser too - its main claim to fame is being free.
They should evaluate the latest MSC 2022 compiler if speed is important.
(free to download you have to license it for business use)

Almost all serious large scale computing in C people flatten their huge
arrays to 1 dimension using clumsy macros to do the indexing (or use
another language like Fortran which supports N dimensional arrays well).

> Python looks a lot like Basic to me. Some of the goofier features were
> added so that it couldn't be directly accused of being Basic syntax,
> which would have been toxic.
>
> PB has wonderful string functions. It has TCP OPEN and such, and can
> send/receive emails if you really want to. The cool stuff is native,
> not libraries; make an EXE file in half a second and you're done.

Whatever turns you on...

--
Regards,
Martin Brown

Re: high accuracy math library

<ss3tgk$rrd$1@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88023&group=sci.electronics.design#88023

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pNaonStp...@yahoo.com (Jan Panteltje)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 14:11:52 GMT
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <ss3tgk$rrd$1@dont-email.me>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org> <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jan 2022 14:12:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f162c8d3742574b7fc3269bb89bda147";
logging-data="28525"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/lSEBLUDTGCIa0TRkmNkkoOie+xXXY29A="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:5ZgHGSXU3jsB++mulNKE+NQTmKU=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
 by: Jan Panteltje - Mon, 17 Jan 2022 14:11 UTC

On a sunny day (Mon, 17 Jan 2022 13:26:09 +0000) it happened Martin Brown
<'''newspam'''@nonad.co.uk> wrote in <ss3qph$pao$1@gioia.aioe.org>:

>There is something wrong with how they are doing it then! One
>dimensional arrays should be roughly equivalent performance in any
>compiled language. C can do 1-D array indexing the same way as Basic.
>
>C becomes messy when there are 2D or higher dimensional arrays since
>that is implemented as a pointer to a pointer which does not cache well.
>If they were using that array construct then they would be at a
>disadvantage but it should not be by a factor of 4. Nothing like.
>
>GCC is a lukewarm optimiser too - its main claim to fame is being free.
>They should evaluate the latest MSC 2022 compiler if speed is important.
>(free to download you have to license it for business use)

The big plus of GCC is the portability
for example all that X86 stuff I wrote compiles and runs on ARM, a RISC machine (Raspberry Pi 4),
and sometimes even better.
Only problems is some libraries broken by 'maintainers', I had to rewrite libforms.
As to multidimensional arrays...
I use structures and linked lists, yes all pointers, but as fast as it goes.
libc is nice, and leaves little to be wished for.

>Almost all serious large scale computing in C people flatten their huge
>arrays to 1 dimension using clumsy macros to do the indexing (or use
>another language like Fortran which supports N dimensional arrays well).

What macros?

>> Python looks a lot like Basic to me. Some of the goofier features were
>> added so that it couldn't be directly accused of being Basic syntax,
>> which would have been toxic.

Python is something that I hope will just disappear
written by people who did not want to understands C and the hardware it seems.
And Cplusplus is a crime against humanity.

I designed some vector processing card for the IBM PC back in the eighties.
That was fast.
These days people use GPUs for bitcoin mining....
Do not think it is energy efficient .... so no bitcoins here,
but there computing power versus power consumption counts.

I looked up FFT multiplication after reading about it here... Never done that,
Makes sense somehow.

Re: high accuracy math library

<36868e69-03ef-ed1a-8742-8c5e5d86c722@electrooptical.net>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88025&group=sci.electronics.design#88025

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 09:27:13 -0500
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <36868e69-03ef-ed1a-8742-8c5e5d86c722@electrooptical.net>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org>
<vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
<ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org>
<6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="383ffaaa4e26978f241397a3351658aa";
logging-data="13976"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/rYlqbfL8neQlK/BYdncZB"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.0
Cancel-Lock: sha1:Xf54qBFuoLRkAGUWV2ue7v6rGBY=
In-Reply-To: <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com>
 by: Phil Hobbs - Mon, 17 Jan 2022 14:27 UTC

jlarkin@highlandsniptechnology.com wrote:
> On Sun, 16 Jan 2022 09:26:42 +0000, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 15/01/2022 17:58, jlarkin@highlandsniptechnology.com wrote:
>>> On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>
>>>> On 14/01/2022 21:01, Joe Gwinn wrote:
>>>>>
>>>>> In the old days, only VAX/VMS had hardware support for 128-bit floats
>>
>> Probably a very wasteful decision that cost them dear. The requirement
>> for anything above a 64 bit FP word length is very esoteric.
>>
>> The most popular back in that era for high speed floating point was the
>> Cyber 7600 (60 bit word) which powered Manchester universities Jodrell
>> Bank processing and BMEWS early warning system amongst other things.
>>
>>>>> (not IEEE format though). In the cited GCC list, which of these are
>>>>> directly supported in hardware, versus software emulation?
>>>>
>>>> 32, 64 are native x87 and full SSE floating point support
>>>> 80 x87 only but GCC does it fairly well
>>>
>>> Power Basic has a native 80-bit float type and a 64-bit integer.
>>
>> I'm so impressed. NOT
>
> Of course not. The word BASIC triggers too much emotion, facts not
> required.
>
> We had a couple of cases where we wanted to do a signal processing
> routine that processed an array of adc samples, on x86. My official
> programmer guys did it in gcc and I did it in Power Basic. Mine used
> subscripts in the most obvious loop and they used pointers. Mine ran
> 4x as fast. After a day of mucking with code and compiler switches,
> many combinations, they got within about 40%.
>
> Python looks a lot like Basic to me. Some of the goofier features were
> added so that it couldn't be directly accused of being Basic syntax,
> which would have been toxic.
>
> PB has wonderful string functions. It has TCP OPEN and such, and can
> send/receive emails if you really want to. The cool stuff is native,
> not libraries; make an EXE file in half a second and you're done.

Back in the very long ago, when I was a grad student, I used to really
like HP's Rocky Mountain Basic. I had a 9816 with some huge 20 MB hard
drive and a bunch of hardware I/O to run my laser microscope.

I managed to cadge an Infotek math coprocessor board plus their
RMB-compatible compiler, which really helped the speed.

The great thing about RMB was that it made instrument control a
breeze--it was written by the outfit that made the instruments, which
helps. ;)

Haven't used BASIC since about 1987, even though I have a few
instruments that run RMB and can be used as controllers for other boxes
(notably the HP 35665A).

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Re: high accuracy math library

<ss47o2$ohn$1@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88031&group=sci.electronics.design#88031

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: david.br...@hesbynett.no (David Brown)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 18:07:14 +0100
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <ss47o2$ohn$1@dont-email.me>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org>
<vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
<ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org>
<6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jan 2022 17:07:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="1f3da9c03866acc468cd6738a39f9dee";
logging-data="25143"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19hxqMp5Dz4FXrxp5e9UTg1B5Mq0kzc7BY="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:2kAHxibFfkFUP7CzFD7sgFDQQOo=
In-Reply-To: <ss3qph$pao$1@gioia.aioe.org>
Content-Language: en-GB
 by: David Brown - Mon, 17 Jan 2022 17:07 UTC

On 17/01/2022 14:26, Martin Brown wrote:
> On 16/01/2022 15:50, jlarkin@highlandsniptechnology.com wrote:
>> On Sun, 16 Jan 2022 09:26:42 +0000, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 15/01/2022 17:58, jlarkin@highlandsniptechnology.com wrote:
>>>> On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
>>>> <'''newspam'''@nonad.co.uk> wrote:
>>>>
>>>>> 32, 64  are native x87 and full SSE floating point support
>>>>> 80     x87 only but GCC does it fairly well
>>>>
>>>> Power Basic has a native 80-bit float type and a 64-bit integer.
>>>
>>> I'm so impressed. NOT
>>
>> Of course not. The word BASIC triggers too much emotion, facts not
>> required.
>
> I don't have any problem with Basic. I sometimes use it as VBA dialect
> in inside Excel to automate jobs I can't otherwise be bothered doing.
>
> Ripping content authored by someone else as output by MS Office "save
> for web" into a compact shape fit to go on a web page for instance!
>
>> We had a couple of cases where we wanted to do a signal processing
>> routine that processed an array of adc samples, on x86. My official
>> programmer guys did it in gcc and I did it in Power Basic. Mine used
>> subscripts in the most obvious loop and they used pointers. Mine ran
>> 4x as fast. After a day of mucking with code and compiler switches,
>> many combinations, they got within about 40%.
>
> There is something wrong with how they are doing it then! One
> dimensional arrays should be roughly equivalent performance in any
> compiled language. C can do 1-D array indexing the same way as Basic.
>

Indeed.

When someone uses pointers for C arrays, it's an indication that they
are being smart-arse rather than smart - they are trying to
micro-optimise the source code instead of writing it clearly and letting
the compiler do the job. Without other information or seeing the code,
it is of course impossible to tell - but there is certainly no simple
explanation why the same array code could not be written in the same way
in C and get at least as good performance.

> C becomes messy when there are 2D or higher dimensional arrays since
> that is implemented as a pointer to a pointer which does not cache well.

No, two dimensional arrays in C are /not/ pointer-to-pointer accesses.

If you have:

int xs[10][100];

Then accessing "xs[a][b]" is just like accessing element "100 * a + b"
of a one-dimensional array. There are no extra levels of indirection,
and xs is /not/ an array of pointers.

> If they were using that array construct then they would be at a
> disadvantage but it should not be by a factor of 4. Nothing like.
>

There is no disadvantage. It would be absurd if C were designed in such
a way that access to two-dimensional arrays had a pointless layer of
extra pointers to slow it down and waste memory. (Poor quality
compilers might generate poor quality object code from multi-dimensional
array access, but that's a matter of the compiler optimisation. It used
to make sense to use manual pointer arithmetic instead of array
expressions, in the old days when compilers were weak.)

> GCC is a lukewarm optimiser too - its main claim to fame is being free.
> They should evaluate the latest MSC 2022 compiler if speed is important.
> (free to download you have to license it for business use)
>

gcc is an excellent optimiser. MSVC is not bad too (for C++ - it's a
shitty C compiler), and the same goes for clang and Intel icc. Each
will do better on some examples, worse on others. And each requires
extra effort, careful flag selection, and compiler-specific features if
you want to squeeze the last few drops of performance out of the
binaries. (This can make a big difference if you can vectorise the code
with SIMD instructions.)

> Almost all serious large scale computing in C people flatten their huge
> arrays to 1 dimension using clumsy macros to do the indexing (or use
> another language like Fortran which supports N dimensional arrays well).
>

Nonsense. That was the case 20 years ago, but not now.

(They might do horrible things to their code to make them work well with
SIMD, as automatic vectorisation is still more of an art than a science.)

>> Python looks a lot like Basic to me. Some of the goofier features were
>> added so that it couldn't be directly accused of being Basic syntax,
>> which would have been toxic.
>>
>> PB has wonderful string functions. It has TCP OPEN and such, and can
>> send/receive emails if you really want to. The cool stuff is native,
>> not libraries; make an EXE file in half a second and you're done.
>

The cool stuff in PB is libraries, not native - but it might be
libraries that are always included by the tool so that you don't need
any kind of "import" statement.

Certainly it is insanity to use C when you want networking, emails, and
the like. If you are doing something big enough that you want the speed
and efficiency of C, use C++, Go, Rust, D, or anything else that will do
a better job of letting you write such code easily and safely. If not,
use Python as it makes such code vastly simpler and faster to write, and
has more libraries for that kind of thing than any other language.

Basic was probably a solid choice for such things a couple of decades
ago. And of course if you are used to it, and it is still good enough,
then that's fine - good enough is good enough.

Re: high accuracy math library

<ss4apv$r3n$1@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88036&group=sci.electronics.design#88036

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pNaonStp...@yahoo.com (Jan Panteltje)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 17:58:42 GMT
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <ss4apv$r3n$1@dont-email.me>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org> <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org> <ss47o2$ohn$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jan 2022 17:59:28 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d6dc2779469206ace701d957e6797f1a";
logging-data="27767"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19njAHKPp0NeGgJ6b2g7s28Kf+zzfdBzCU="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:rxl4K9j6HOXymueDU0Sw03Uealg=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
 by: Jan Panteltje - Mon, 17 Jan 2022 17:58 UTC

On a sunny day (Mon, 17 Jan 2022 18:07:14 +0100) it happened David Brown
<david.brown@hesbynett.no> wrote in <ss47o2$ohn$1@dont-email.me>:

>Certainly it is insanity to use C when you want networking, emails, and
>the like.

That is not correct, read libcinfo, it should be on your lLinux system, else it is here:
http://panteltje.com/pub/libc.info.txt
I use networking in C all the time
wrote several servers, irc client, email client, this newsreader, so much, no problem.
If it [networking] is TOO difficult for you, then call 'netcat' from C (or your script or from anything else).
In Linux that is,
But really, writing a server in C is only a few lines.

>If you are doing something big enough that you want the speed
>and efficiency of C, use C++

C++ is a crime against humanity.

,>Go, Rust, D, or anything else that will do
>a better job of letting you write such code easily and safely. If not,
>use Python as it makes such code vastly simpler and faster to write, and
>has more libraries for that kind of thing than any other language.
>
>Basic was probably a solid choice for such things a couple of decades
>ago. And of course if you are used to it, and it is still good enough,
>then that's fine - good enough is good enough.

The Sinclair ZX80 / ZX81 BASIC was very very good.
asm is even more fun.

Re: high accuracy math library

<2e88109f-2296-25b5-31fd-0df2425004b8@electrooptical.net>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88040&group=sci.electronics.design#88040

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 13:43:31 -0500
Organization: A noiseless patient Spider
Lines: 26
Message-ID: <2e88109f-2296-25b5-31fd-0df2425004b8@electrooptical.net>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org>
<vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
<ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org>
<6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org>
<ss47o2$ohn$1@dont-email.me> <ss4apv$r3n$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="383ffaaa4e26978f241397a3351658aa";
logging-data="17867"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/omS/vovHYbrl5JDrvGJDW"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.0
Cancel-Lock: sha1:gmPEtptoxgqXpO/L+l865v6TgUA=
In-Reply-To: <ss4apv$r3n$1@dont-email.me>
 by: Phil Hobbs - Mon, 17 Jan 2022 18:43 UTC

Jan Panteltje wrote:
> On a sunny day (Mon, 17 Jan 2022 18:07:14 +0100) it happened David Brown
> <david.brown@hesbynett.no> wrote in <ss47o2$ohn$1@dont-email.me>:
>
>> Certainly it is insanity to use C when you want networking, emails, and
>> the like.
>
> That is not correct, read libcinfo, it should be on your lLinux system, else it is here:
> http://panteltje.com/pub/libc.info.txt
> I use networking in C all the time
> wrote several servers, irc client, email client, this newsreader, so much, no problem.
> If it [networking] is TOO difficult for you, then call 'netcat' from C (or your script or from anything else).
> In Linux that is,
> But really, writing a server in C is only a few lines.
>
>
>> If you are doing something big enough that you want the speed
>> and efficiency of C, use C++
>
> C++ is a crime against humanity.

If you don't like the poison gas, lay off the pickled herring. ;)

Cheers

Phil Hobbs

Re: high accuracy math library

<7aibug14ktp8a81263veavq4phq9tq8tpg@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88045&group=sci.electronics.design#88045

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!nntp.supernews.com!news.supernews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 17 Jan 2022 13:57:59 -0600
From: jlar...@highlandsniptechnology.com
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 11:58:00 -0800
Message-ID: <7aibug14ktp8a81263veavq4phq9tq8tpg@4ax.com>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org> <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org> <ss47o2$ohn$1@dont-email.me> <ss4apv$r3n$1@dont-email.me>
X-Newsreader: Forte Agent 3.1/32.783
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 48
X-Trace: sv3-vOQ309vxWmWbr0z2/AHL4Pn40zO1kzHwBbvAWz0odfEzxjBITNMsBfQe+lSV4OLQRrCjoQwZpruaLKb!knph7mwMXbSbxzpkXv0e0WUQUwyVwN1EqM+DvEV2Fa6CpajqD7InmygOIOV7wDpv5R3iGX4DOWEw!VTRUNA==
X-Complaints-To: www.supernews.com/docs/abuse.html
X-DMCA-Complaints-To: www.supernews.com/docs/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3057
 by: jlar...@highlandsniptechnology.com - Mon, 17 Jan 2022 19:58 UTC

On Mon, 17 Jan 2022 17:58:42 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (Mon, 17 Jan 2022 18:07:14 +0100) it happened David Brown
><david.brown@hesbynett.no> wrote in <ss47o2$ohn$1@dont-email.me>:
>
>>Certainly it is insanity to use C when you want networking, emails, and
>>the like.
>
>That is not correct, read libcinfo, it should be on your lLinux system, else it is here:
> http://panteltje.com/pub/libc.info.txt
>I use networking in C all the time
>wrote several servers, irc client, email client, this newsreader, so much, no problem.
>If it [networking] is TOO difficult for you, then call 'netcat' from C (or your script or from anything else).
>In Linux that is,
>But really, writing a server in C is only a few lines.
>
>
>>If you are doing something big enough that you want the speed
>>and efficiency of C, use C++
>
>C++ is a crime against humanity.
>
>
>,>Go, Rust, D, or anything else that will do
>>a better job of letting you write such code easily and safely. If not,
>>use Python as it makes such code vastly simpler and faster to write, and
>>has more libraries for that kind of thing than any other language.
>>
>>Basic was probably a solid choice for such things a couple of decades
>>ago. And of course if you are used to it, and it is still good enough,
>>then that's fine - good enough is good enough.
>
>The Sinclair ZX80 / ZX81 BASIC was very very good.
>asm is even more fun.
>

PowerBasic is wonderful. A serious compiler will a great UI and all
sorts of intrinsic goodies. It also allows inline asm with variable
names common to Basic and ASM. That is handy now and then.

--

I yam what I yam - Popeye

Re: high accuracy math library

<ss4kd8$o3d$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88051&group=sci.electronics.design#88051

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!5U2ooNuM5UP0Ynf/GmOnCg.user.46.165.242.91.POSTED!not-for-mail
From: Decadent...@decadence.org
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 20:43:20 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <ss4kd8$o3d$1@gioia.aioe.org>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org> <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org> <ss47o2$ohn$1@dont-email.me> <ss4apv$r3n$1@dont-email.me>
Injection-Info: gioia.aioe.org; logging-data="24685"; posting-host="5U2ooNuM5UP0Ynf/GmOnCg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Xnews/5.04.25
X-Notice: Filtered by postfilter v. 0.9.2
 by: Decadent...@decadence.org - Mon, 17 Jan 2022 20:43 UTC

Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote in news:ss4apv$r3n$1
@dont-email.me:

> C++ is a crime against humanity.
^^^^
More like "Jan Pantltje's whore mother committed a crime against
humanity."

Re: high accuracy math library

<neubughqjksn5p95ig15f2pihaker739gu@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88079&group=sci.electronics.design#88079

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 17 Jan 2022 17:35:20 -0600
From: joegw...@comcast.net (Joe Gwinn)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 18:35:19 -0500
Message-ID: <neubughqjksn5p95ig15f2pihaker739gu@4ax.com>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
User-Agent: ForteAgent/8.00.32.1272
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 133
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-cZVQy/iW2kkwniJ9qDLWm6TIzVHtfOzyEKdiaRl1Vwa7RHWKk77AtVTmYUJp/iEVW/j2jL7MdkvpDq0!hMUFxO1C4lFT3wnndZTfqcCQRYy/Euex8ooFhqez4Q+MsPpQ0zwexi6wBCNg4OKsYiwOFoI=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6722
 by: Joe Gwinn - Mon, 17 Jan 2022 23:35 UTC

On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 14/01/2022 21:01, Joe Gwinn wrote:
>> On Fri, 14 Jan 2022 18:12:43 +0000, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 14/01/2022 16:50, Hul Tytus wrote:
>>>> There was once a math library in c, if memory serves, with the
>>>> basic functions, ie +, -, * and / and some others also. The resolution
>>>> was adjustable so changing a reference variable (or was that a #define?)
>>>> from 32 to 256 would change the size of the variables to 256 bits.
>>>> Anyone rember the name or location of that library?
>>>
>>> I don't recall that particular one but GCC can be fairly easily
>>> persuaded to go up to 128 bit reals which are usually good enough for
>>> all but the most insane of floating point calculations.
>>>
>>> I think your choices there are limited to 32, 64, 80, 128
>>>
>>> <https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html>
>>>
>>> It includes the most common transcendental functions as well.
>>>
>>> Quad floating precision runs slowly so do as much as you can at a lower
>>> precision and then refine the answer using that as a seed value.
>>>
>>> I used to like having 80 bit reals available in the good old prehistoric
>>> days of MSC v6. Today it requires some effort to use them with MSC :(
>>
>> In the old days, only VAX/VMS had hardware support for 128-bit floats
>> (not IEEE format though). In the cited GCC list, which of these are
>> directly supported in hardware, versus software emulation?
>
>32, 64 are native x87 and full SSE floating point support
>80 x87 only but GCC does it fairly well
>128 emulated and slower
>
>Always work in the hardware supported ones to obtain an approximate
>answer unless and until you need that extra precision.

Yes.

>Preferably frame it so you refine an approximate starting guess.

If possible. Sometimes I use a coarse-fine two-step algorithm.

>> Most current machines directly support multi precision integer
>> arithmetic for power-of-2 lengths, but it is done in multiple
>> coordinated machine-code operations, so it's partly in software.
>
>32, 64 and 128 integer support are sometimes native at least for some
>platforms. +, - and * all execute in one nominal CPU cycle* too!
>(at least for 32, 64 bit - I have never bothered with 128 bit int)

Nor have I, although for such things as time, integers are preferred
because the precision does not vary with magnitude.

Depending on the hardware, a pair of 64-bit integers can be scaled
such that one integer is the integer part and the other integer is the
fractional part, the decimal point being between the two integers.
Depending on hardware and compiler, this may be faster than floating
point.

>* sometimes they can appear to take less than one cycle due to out of
>order execution and the opportunities to do work whilst divides are in
>progress. Divides are always best avoided or if that is impossible their
>number minimised. Divide is between 10-20x slower than all the other
>primitive operations and two divides close together can be *much*
>slower. Pipeline stalls typically cost around 90 cycles per hit.
>
>divide remains a PITA and worth eliminating where possible.

It's usually possible to reformulate to multiply by the reciprocal.

>I have an assembler implementation for a special case division that can
>be faster than the hardware divide for the situation it aims to solve.
>
>Basically 1/(1-x) = 1 + x + x^2 + x^3 + x^4 + ...
> (1 + x)*(1 + x^2)*(1 + x^4)*(1 + x^8)
>
>And for smallish x it converges faster than hardware FP divide.

Yes, that example comes up in practice a good bit.

>> Of course, when the word size goes up, the various approximations
>> polynomials must improve, which generally means to use higher-order
>> polynomials, so the slowdown isn't all due to slower computational
>> hardware.
>
>There aren't all that many that need it.

Later in this thread you did mention Pade approximations, which turned
out to be good enough for simulating planetary systems with chaos.

In ray-tracing problems, the big hitters are sine and cosine, and some
tangent. I have not needed to determine if the current approximations
are good enough, but I'm suspicious, given that a slight displacement
of the intersection point on a curved optical surface will deviate the
ray ever so slightly, most likely changing the ray segment length ever
so slightly, ...

>Most planetary dynamics can be done with 80 bit reals with a bit to spare.
>
>> The only real application of 128-bit floats that I am aware of was the
>> design of interferometers such as LIGO, where one is tracking very
>> small fractions of an optical wavelength over path lengths in the
>> kilometers, with at least two spare decimal digits to absorb numerical
>> noise from the ray-trace computations.
>
>That might be a genuine application.

I'm pretty sure that it was an actual application. Probably been
replaced by now.

>The only times I have played with them have been to investigate the
>weird constants that play a part in some chaotic equations. I was
>curious to see how much of the behaviour was due to finite mantissa
>length and how much was inherent in the mathematics. Doubling the length
>of the mantissa goes a long way to solving that particular problem.
>(but it is rather slow)

Yes, that would be the classic test, needed only once in a while.

Joe Gwinn

Re: high accuracy math library

<26acd7fd-e25b-b147-7d08-d3acbd34995e@electrooptical.net>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88084&group=sci.electronics.design#88084

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pcdhSpam...@electrooptical.net (Phil Hobbs)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Mon, 17 Jan 2022 19:23:58 -0500
Organization: A noiseless patient Spider
Lines: 187
Message-ID: <26acd7fd-e25b-b147-7d08-d3acbd34995e@electrooptical.net>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org>
<vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
<neubughqjksn5p95ig15f2pihaker739gu@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="3376dee3418e4ac0ab49fcd41ec1d20b";
logging-data="7087"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dlWzI89FC3uFqrjNMZ4kn"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.0
Cancel-Lock: sha1:+cgGISNHTL5uSxHaO73H82z6IxA=
In-Reply-To: <neubughqjksn5p95ig15f2pihaker739gu@4ax.com>
 by: Phil Hobbs - Tue, 18 Jan 2022 00:23 UTC

Joe Gwinn wrote:
> On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 14/01/2022 21:01, Joe Gwinn wrote:
>>> On Fri, 14 Jan 2022 18:12:43 +0000, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>
>>>> On 14/01/2022 16:50, Hul Tytus wrote:
>>>>> There was once a math library in c, if memory serves, with the
>>>>> basic functions, ie +, -, * and / and some others also. The resolution
>>>>> was adjustable so changing a reference variable (or was that a #define?)
>>>>> from 32 to 256 would change the size of the variables to 256 bits.
>>>>> Anyone rember the name or location of that library?
>>>>
>>>> I don't recall that particular one but GCC can be fairly easily
>>>> persuaded to go up to 128 bit reals which are usually good enough for
>>>> all but the most insane of floating point calculations.
>>>>
>>>> I think your choices there are limited to 32, 64, 80, 128
>>>>
>>>> <https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html>
>>>>
>>>> It includes the most common transcendental functions as well.
>>>>
>>>> Quad floating precision runs slowly so do as much as you can at a lower
>>>> precision and then refine the answer using that as a seed value.
>>>>
>>>> I used to like having 80 bit reals available in the good old prehistoric
>>>> days of MSC v6. Today it requires some effort to use them with MSC :(
>>>
>>> In the old days, only VAX/VMS had hardware support for 128-bit floats
>>> (not IEEE format though). In the cited GCC list, which of these are
>>> directly supported in hardware, versus software emulation?
>>
>> 32, 64 are native x87 and full SSE floating point support
>> 80 x87 only but GCC does it fairly well
>> 128 emulated and slower
>>
>> Always work in the hardware supported ones to obtain an approximate
>> answer unless and until you need that extra precision.
>
> Yes.
>
>
>> Preferably frame it so you refine an approximate starting guess.
>
> If possible. Sometimes I use a coarse-fine two-step algorithm.
>
>
>>> Most current machines directly support multi precision integer
>>> arithmetic for power-of-2 lengths, but it is done in multiple
>>> coordinated machine-code operations, so it's partly in software.
>>
>> 32, 64 and 128 integer support are sometimes native at least for some
>> platforms. +, - and * all execute in one nominal CPU cycle* too!
>> (at least for 32, 64 bit - I have never bothered with 128 bit int)
>
> Nor have I, although for such things as time, integers are preferred
> because the precision does not vary with magnitude.
>
> Depending on the hardware, a pair of 64-bit integers can be scaled
> such that one integer is the integer part and the other integer is the
> fractional part, the decimal point being between the two integers.
> Depending on hardware and compiler, this may be faster than floating
> point.
>
>
>> * sometimes they can appear to take less than one cycle due to out of
>> order execution and the opportunities to do work whilst divides are in
>> progress. Divides are always best avoided or if that is impossible their
>> number minimised. Divide is between 10-20x slower than all the other
>> primitive operations and two divides close together can be *much*
>> slower. Pipeline stalls typically cost around 90 cycles per hit.
>>
>> divide remains a PITA and worth eliminating where possible.
>
> It's usually possible to reformulate to multiply by the reciprocal.
>
>
>> I have an assembler implementation for a special case division that can
>> be faster than the hardware divide for the situation it aims to solve.
>>
>> Basically 1/(1-x) = 1 + x + x^2 + x^3 + x^4 + ...
>> (1 + x)*(1 + x^2)*(1 + x^4)*(1 + x^8)
>>
>> And for smallish x it converges faster than hardware FP divide.
>
> Yes, that example comes up in practice a good bit.
>
>
>>> Of course, when the word size goes up, the various approximations
>>> polynomials must improve, which generally means to use higher-order
>>> polynomials, so the slowdown isn't all due to slower computational
>>> hardware.
>>
>> There aren't all that many that need it.
>
> Later in this thread you did mention Pade approximations, which turned
> out to be good enough for simulating planetary systems with chaos.
>
> In ray-tracing problems, the big hitters are sine and cosine, and some
> tangent. I have not needed to determine if the current approximations
> are good enough, but I'm suspicious, given that a slight displacement
> of the intersection point on a curved optical surface will deviate the
> ray ever so slightly, most likely changing the ray segment length ever
> so slightly, ...

Right. Of course manufacturing errors in a real lens will limit the
accuracy of a given ray trace faster than the mumerical limitations.

This is a slower version of the classical pool table problem. Go ahead
and rack up a nice set of perfectly elastic balls on a lossless table
with perfectly elastic cushions in a vacuum at zero kelvins, (*) Then
pick up your perfectly elastic cue, put some very high friction chalk on
it, and break.

Your eye-hand coordination is perfect, of course, but nevertheless the
cue ball's position and momentum are slightly uncertain due to the
Heisenberg inequality, $\delta P \delta S \ge \bar{h}/2 $. This is a
very small number, so your break appears perfect. Two balls go straight
into pockets, and the rest keep rattling round the table.

Any uncertainty in the momentum of a given ball causes an aiming
uncertainty that builds up linearly with distance. That makes the point
of collision with the next ball slightly uncertain, causing an angular
error, which builds up linearly with distance till the next
collision.... The result is an exponential error amplifier.

In the absence of loss, the Heisenberg uncertainty of the motion of the
cue ball gets multiplied exponentially with time, until after 30 seconds
or so it becomes larger than the ball's diameter--in other words, past
that point it's impossible even in principle to predict from the initial
conditions which balls will hit each other.

(At that point you start simulating the pool table as though it were a
globular star cluster instead of a planetary system.) ;)

Cheers

Phil Hobbs

(*) Yes, like the spherical cow emitting milk isotropically at a
constant rate...

>
>
>> Most planetary dynamics can be done with 80 bit reals with a bit to spare.
>>
>>> The only real application of 128-bit floats that I am aware of was the
>>> design of interferometers such as LIGO, where one is tracking very
>>> small fractions of an optical wavelength over path lengths in the
>>> kilometers, with at least two spare decimal digits to absorb numerical
>>> noise from the ray-trace computations.
>>
>> That might be a genuine application.
>
> I'm pretty sure that it was an actual application. Probably been
> replaced by now.
>
>
>> The only times I have played with them have been to investigate the
>> weird constants that play a part in some chaotic equations. I was
>> curious to see how much of the behaviour was due to finite mantissa
>> length and how much was inherent in the mathematics. Doubling the length
>> of the mantissa goes a long way to solving that particular problem.
>> (but it is rather slow)
>
> Yes, that would be the classic test, needed only once in a while.
>
>
> Joe Gwinn
>

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Re: high accuracy math library

<ss5luo$8nt$1@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88107&group=sci.electronics.design#88107

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pNaonStp...@yahoo.com (Jan Panteltje)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Tue, 18 Jan 2022 06:14:38 GMT
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <ss5luo$8nt$1@dont-email.me>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org> <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org> <ss47o2$ohn$1@dont-email.me> <ss4apv$r3n$1@dont-email.me> <7aibug14ktp8a81263veavq4phq9tq8tpg@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 18 Jan 2022 06:15:52 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="761c2d2ef93c710b0f842c591c9e10b7";
logging-data="8957"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZBVOufSVeJOMNmsU7z5srg9wJV8cqmhM="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:S2jhQ6NXaltaSyLFoI6OK8M7YRg=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
 by: Jan Panteltje - Tue, 18 Jan 2022 06:14 UTC

On a sunny day (Mon, 17 Jan 2022 11:58:00 -0800) it happened
jlarkin@highlandsniptechnology.com wrote in
<7aibug14ktp8a81263veavq4phq9tq8tpg@4ax.com>:

>On Mon, 17 Jan 2022 17:58:42 GMT, Jan Panteltje
><pNaonStpealmtje@yahoo.com> wrote:
>
>>On a sunny day (Mon, 17 Jan 2022 18:07:14 +0100) it happened David Brown
>><david.brown@hesbynett.no> wrote in <ss47o2$ohn$1@dont-email.me>:
>>
>>>Certainly it is insanity to use C when you want networking, emails, and
>>>the like.
>>
>>That is not correct, read libcinfo, it should be on your lLinux system, else it is here:
>> http://panteltje.com/pub/libc.info.txt
>>I use networking in C all the time
>>wrote several servers, irc client, email client, this newsreader, so much, no problem.
>>If it [networking] is TOO difficult for you, then call 'netcat' from C (or your script or from anything else).
>>In Linux that is,
>>But really, writing a server in C is only a few lines.
>>
>>
>>>If you are doing something big enough that you want the speed
>>>and efficiency of C, use C++
>>
>>C++ is a crime against humanity.
>>
>>
>>,>Go, Rust, D, or anything else that will do
>>>a better job of letting you write such code easily and safely. If not,
>>>use Python as it makes such code vastly simpler and faster to write, and
>>>has more libraries for that kind of thing than any other language.
>>>
>>>Basic was probably a solid choice for such things a couple of decades
>>>ago. And of course if you are used to it, and it is still good enough,
>>>then that's fine - good enough is good enough.
>>
>>The Sinclair ZX80 / ZX81 BASIC was very very good.
>>asm is even more fun.
>>
>
>PowerBasic is wonderful. A serious compiler will a great UI and all
>sorts of intrinsic goodies. It also allows inline asm with variable
>names common to Basic and ASM. That is handy now and then.

I once wrote
http://panteltje.com/panteltje/newsflex/download.html#hxl
it is sort of a way to allow inline asm in MCS BASIC for the 8052 micro I think it was...
also from the eighties.
https://ininet.org/chapter-1-introduction-to-mcs-basic-52.html

Re: high accuracy math library

<ss5mcs$alo$1@dont-email.me>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88108&group=sci.electronics.design#88108

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: pNaonStp...@yahoo.com (Jan Panteltje)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Tue, 18 Jan 2022 06:22:38 GMT
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <ss5mcs$alo$1@dont-email.me>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <ae26ugdp13878t22faknfcnm5133ir8e1o@4ax.com> <ss0oci$apf$1@gioia.aioe.org> <6he8ug9j479o12bprsegh4vtf5ucl2m786@4ax.com> <ss3qph$pao$1@gioia.aioe.org> <ss47o2$ohn$1@dont-email.me> <ss4apv$r3n$1@dont-email.me> <2e88109f-2296-25b5-31fd-0df2425004b8@electrooptical.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 18 Jan 2022 06:23:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4bf5fa9b1e2bf82172ed25fefd85280b";
logging-data="10936"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/A2Jrjr2RSpe6ZjItQYHLJylnW4vX9ufQ="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:YjBsu915s5+AS7VKDaoFamOTQnU=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
 by: Jan Panteltje - Tue, 18 Jan 2022 06:22 UTC

On a sunny day (Mon, 17 Jan 2022 13:43:31 -0500) it happened Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote in
<2e88109f-2296-25b5-31fd-0df2425004b8@electrooptical.net>:

>Jan Panteltje wrote:
>> On a sunny day (Mon, 17 Jan 2022 18:07:14 +0100) it happened David Brown
>> <david.brown@hesbynett.no> wrote in <ss47o2$ohn$1@dont-email.me>:
>>
>>> Certainly it is insanity to use C when you want networking, emails, and
>>> the like.
>>
>> That is not correct, read libcinfo, it should be on your lLinux system, else it is here:
>> http://panteltje.com/pub/libc.info.txt
>> I use networking in C all the time
>> wrote several servers, irc client, email client, this newsreader, so much, no problem.
>> If it [networking] is TOO difficult for you, then call 'netcat' from C (or your script or from anything else).
>> In Linux that is,
>> But really, writing a server in C is only a few lines.
>>
>>
>>> If you are doing something big enough that you want the speed
>>> and efficiency of C, use C++
>>
>> C++ is a crime against humanity.
>
>If you don't like the poison gas, lay off the pickled herring. ;)
>
>Cheers
>
>Phil Hobbs

Good protection clothes are essential,
http://panteltje.com/pub/asbestos_aliens_1.gif
guys here yesterday replacing asbestos roof.
Same for Cpushplush dispose of it with care.
I like herring, the smell does not bother me,
when I was very young my father could not get me past a herring stand (many in Amsterdam)
without me having one.

These days those may be contaminated with anything from plutonium to plastics though.

Re: high accuracy math library

<qoaeugttnip17o9amlgke602a3qam4f70h@4ax.com>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88161&group=sci.electronics.design#88161

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 18 Jan 2022 15:25:31 -0600
From: joegw...@comcast.net (Joe Gwinn)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Tue, 18 Jan 2022 16:25:30 -0500
Message-ID: <qoaeugttnip17o9amlgke602a3qam4f70h@4ax.com>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org> <vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org> <neubughqjksn5p95ig15f2pihaker739gu@4ax.com> <26acd7fd-e25b-b147-7d08-d3acbd34995e@electrooptical.net>
User-Agent: ForteAgent/8.00.32.1272
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 174
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CnucVfmLvyFCyMT+nqg5H9WQ1OxJlzYWx5pPatnvLHgZuwKXYv8bPUmFaHPNwBYk5d+hfqPbrTU6nze!MtSWWge3T1wdD8L7Xo2vTCg57nVT1VmefGLtX+eADUDiwG7nYOzTu2zRKNj4Fy9owCKyGhs=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8559
 by: Joe Gwinn - Tue, 18 Jan 2022 21:25 UTC

On Mon, 17 Jan 2022 19:23:58 -0500, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>Joe Gwinn wrote:
>> On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 14/01/2022 21:01, Joe Gwinn wrote:
>>>> On Fri, 14 Jan 2022 18:12:43 +0000, Martin Brown
>>>> <'''newspam'''@nonad.co.uk> wrote:
>>>>
>>>>> On 14/01/2022 16:50, Hul Tytus wrote:
>>>>>> There was once a math library in c, if memory serves, with the
>>>>>> basic functions, ie +, -, * and / and some others also. The resolution
>>>>>> was adjustable so changing a reference variable (or was that a #define?)
>>>>>> from 32 to 256 would change the size of the variables to 256 bits.
>>>>>> Anyone rember the name or location of that library?
>>>>>
>>>>> I don't recall that particular one but GCC can be fairly easily
>>>>> persuaded to go up to 128 bit reals which are usually good enough for
>>>>> all but the most insane of floating point calculations.
>>>>>
>>>>> I think your choices there are limited to 32, 64, 80, 128
>>>>>
>>>>> <https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html>
>>>>>
>>>>> It includes the most common transcendental functions as well.
>>>>>
>>>>> Quad floating precision runs slowly so do as much as you can at a lower
>>>>> precision and then refine the answer using that as a seed value.
>>>>>
>>>>> I used to like having 80 bit reals available in the good old prehistoric
>>>>> days of MSC v6. Today it requires some effort to use them with MSC :(
>>>>
>>>> In the old days, only VAX/VMS had hardware support for 128-bit floats
>>>> (not IEEE format though). In the cited GCC list, which of these are
>>>> directly supported in hardware, versus software emulation?
>>>
>>> 32, 64 are native x87 and full SSE floating point support
>>> 80 x87 only but GCC does it fairly well
>>> 128 emulated and slower
>>>
>>> Always work in the hardware supported ones to obtain an approximate
>>> answer unless and until you need that extra precision.
>>
>> Yes.
>>
>>
>>> Preferably frame it so you refine an approximate starting guess.
>>
>> If possible. Sometimes I use a coarse-fine two-step algorithm.
>>
>>
>>>> Most current machines directly support multi precision integer
>>>> arithmetic for power-of-2 lengths, but it is done in multiple
>>>> coordinated machine-code operations, so it's partly in software.
>>>
>>> 32, 64 and 128 integer support are sometimes native at least for some
>>> platforms. +, - and * all execute in one nominal CPU cycle* too!
>>> (at least for 32, 64 bit - I have never bothered with 128 bit int)
>>
>> Nor have I, although for such things as time, integers are preferred
>> because the precision does not vary with magnitude.
>>
>> Depending on the hardware, a pair of 64-bit integers can be scaled
>> such that one integer is the integer part and the other integer is the
>> fractional part, the decimal point being between the two integers.
>> Depending on hardware and compiler, this may be faster than floating
>> point.
>>
>>
>>> * sometimes they can appear to take less than one cycle due to out of
>>> order execution and the opportunities to do work whilst divides are in
>>> progress. Divides are always best avoided or if that is impossible their
>>> number minimised. Divide is between 10-20x slower than all the other
>>> primitive operations and two divides close together can be *much*
>>> slower. Pipeline stalls typically cost around 90 cycles per hit.
>>>
>>> divide remains a PITA and worth eliminating where possible.
>>
>> It's usually possible to reformulate to multiply by the reciprocal.
>>
>>
>>> I have an assembler implementation for a special case division that can
>>> be faster than the hardware divide for the situation it aims to solve.
>>>
>>> Basically 1/(1-x) = 1 + x + x^2 + x^3 + x^4 + ...
>>> (1 + x)*(1 + x^2)*(1 + x^4)*(1 + x^8)
>>>
>>> And for smallish x it converges faster than hardware FP divide.
>>
>> Yes, that example comes up in practice a good bit.
>>
>>
>>>> Of course, when the word size goes up, the various approximations
>>>> polynomials must improve, which generally means to use higher-order
>>>> polynomials, so the slowdown isn't all due to slower computational
>>>> hardware.
>>>
>>> There aren't all that many that need it.
>>
>> Later in this thread you did mention Pade approximations, which turned
>> out to be good enough for simulating planetary systems with chaos.
>>
>> In ray-tracing problems, the big hitters are sine and cosine, and some
>> tangent. I have not needed to determine if the current approximations
>> are good enough, but I'm suspicious, given that a slight displacement
>> of the intersection point on a curved optical surface will deviate the
>> ray ever so slightly, most likely changing the ray segment length ever
>> so slightly, ...
>
>Right. Of course manufacturing errors in a real lens will limit the
>accuracy of a given ray trace faster than the mumerical limitations.

Yes, although I'd venture that the LIGO conspiracy will have rather
better optics than is common.

>This is a slower version of the classical pool table problem. Go ahead
>and rack up a nice set of perfectly elastic balls on a lossless table
>with perfectly elastic cushions in a vacuum at zero kelvins, (*) Then
>pick up your perfectly elastic cue, put some very high friction chalk on
>it, and break.

Hmm. Slower?

I'm not sure that it would be a good idea to witness billiard balls
traveling at the speed of light colliding with anything solid. A few
light years standoff might be safe.

Well, 50 light years would be safer, as we'd all be dead before the
radiation pulse arrived at Earth.

>Your eye-hand coordination is perfect, of course, but nevertheless the
>cue ball's position and momentum are slightly uncertain due to the
>Heisenberg inequality, $\delta P \delta S \ge \bar{h}/2 $. This is a
>very small number, so your break appears perfect. Two balls go straight
>into pockets, and the rest keep rattling round the table.

Yes, that is the bounding case for sure. My hand isn't quite that
steady, probably for lack of sufficient practice.

>Any uncertainty in the momentum of a given ball causes an aiming
>uncertainty that builds up linearly with distance. That makes the point
>of collision with the next ball slightly uncertain, causing an angular
>error, which builds up linearly with distance till the next
>collision.... The result is an exponential error amplifier.
>
>In the absence of loss, the Heisenberg uncertainty of the motion of the
>cue ball gets multiplied exponentially with time, until after 30 seconds
>or so it becomes larger than the ball's diameter--in other words, past
>that point it's impossible even in principle to predict from the initial
>conditions which balls will hit each other.
>
>(At that point you start simulating the pool table as though it were a
>globular star cluster instead of a planetary system.) ;)

Yes.

>Cheers
>
>Phil Hobbs
>
>
>(*) Yes, like the spherical cow emitting milk isotropically at a
>constant rate...

Well, I've known babies like that.

Joe Gwinn

Re: high accuracy math library

<ss8o66$189e$1@gioia.aioe.org>

  copy mid

https://www.novabbs.com/tech/article-flat.php?id=88203&group=sci.electronics.design#88203

  copy link   Newsgroups: sci.electronics.design
Path: i2pn2.org!i2pn.org!aioe.org!OIRGNq1ADRVRlWCMma5QPA.user.46.165.242.75.POSTED!not-for-mail
From: '''newsp...@nonad.co.uk (Martin Brown)
Newsgroups: sci.electronics.design
Subject: Re: high accuracy math library
Date: Wed, 19 Jan 2022 10:12:21 +0000
Organization: Aioe.org NNTP Server
Message-ID: <ss8o66$189e$1@gioia.aioe.org>
References: <srs9k9$217$2@reader1.panix.com> <srsef1$1trj$1@gioia.aioe.org>
<vgo3ug5dgh6k6m9kt38msf197j7d80quhb@4ax.com> <srv1gt$119o$1@gioia.aioe.org>
<neubughqjksn5p95ig15f2pihaker739gu@4ax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="41262"; posting-host="OIRGNq1ADRVRlWCMma5QPA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: Martin Brown - Wed, 19 Jan 2022 10:12 UTC

On 17/01/2022 23:35, Joe Gwinn wrote:
> On Sat, 15 Jan 2022 17:50:14 +0000, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>>
>> There aren't all that many that need it.
>
> Later in this thread you did mention Pade approximations, which turned
> out to be good enough for simulating planetary systems with chaos.
>
> In ray-tracing problems, the big hitters are sine and cosine, and some
> tangent. I have not needed to determine if the current approximations
> are good enough, but I'm suspicious, given that a slight displacement
> of the intersection point on a curved optical surface will deviate the
> ray ever so slightly, most likely changing the ray segment length ever
> so slightly, ...

Funnily enough the same is true of astrodynamics.

It is a bad idea to use cosine directly since:

cos(x) = 1 - 2*sin(x/2).

Quite often physics problems have terms in "cos(x)-1" or nearly so.

The terms in "sin(x)-x" are much more problematic and in the limit
x<0.25 pretty much have to be computed by a Pade approximation (or a
much older method of summing a fairly well convergent polynomial series)

One of the other tricks I have been working on is moving everything into
expressions in tan(x/2) which eliminates some independent ripple errors
on the lsb of the sin and cos expansions. Only really worthwhile on
platforms that don't compute sincos as a matched pair.

>> Most planetary dynamics can be done with 80 bit reals with a bit to spare.
>>
>>> The only real application of 128-bit floats that I am aware of was the
>>> design of interferometers such as LIGO, where one is tracking very
>>> small fractions of an optical wavelength over path lengths in the
>>> kilometers, with at least two spare decimal digits to absorb numerical
>>> noise from the ray-trace computations.
>>
>> That might be a genuine application.
>
> I'm pretty sure that it was an actual application. Probably been
> replaced by now.

I expect the codebase survives somewhere in an archive.
Big scientific kit often gets revamped at some point.
The sheer mechanical inginuity of the mirror supports in that thing are
amazing at holding it still. Remarkable the number of black hole mergers
that they and the other gravitational wave detectors have seen.

>> The only times I have played with them have been to investigate the
>> weird constants that play a part in some chaotic equations. I was
>> curious to see how much of the behaviour was due to finite mantissa
>> length and how much was inherent in the mathematics. Doubling the length
>> of the mantissa goes a long way to solving that particular problem.
>> (but it is rather slow)
>
> Yes, that would be the classic test, needed only once in a while.

It is what got me into using the GCC compiler for certain tests.
Normally I stick with the MS VC/C++ environment. But their lack of 80bit
real support is annoying. I might get around to writing a C++ stub to
implement the most useful parts one day. But for now GCC and Salford's
Fortran will do everything I need for extended precision.

--
Regards,
Martin Brown


tech / sci.electronics.design / Re: high accuracy math library

Pages:12
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor