KDE help from a practical time
All, To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it: https://paste.opensuse.org/pastes/b1300d1770a4 Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple: ./configure make make install The good ole days.... :) -- David C. Rankin, J.D.,P.E.
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
On 2023-12-05 03:37, Darryl Gregorash wrote:
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
Yet the processor has those types,, I assue so someone uses them. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-12-04 20:52, Carlos E. R. wrote:
On 2023-12-05 03:37, Darryl Gregorash wrote:
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
Yet the processor has those types,, I assue so someone uses them.
Yeah, if you are working, for example, at places like CERN or LIGO.
On 12/4/23 21:56, Darryl Gregorash wrote:
On 2023-12-04 20:52, Carlos E. R. wrote:
On 2023-12-05 03:37, Darryl Gregorash wrote:
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
Yet the processor has those types,, I assue so someone uses them.
Yeah, if you are working, for example, at places like CERN or LIGO.
Precisely! /* estimate the solar declination angle (in radians) */ sp.decl = 0.006918 - 0.399912 * cos(sp.fracyr) + 0.070257 * sin(sp.fracyr) - 0.006758 * cos(2 * sp.fracyr) + 0.000907 * sin(2 * sp.fracyr) - 0.002697 * cos(3 * sp.fracyr) + 0.00148 * sin(3 * sp.fracyr); -- David C. Rankin, J.D.,P.E.
On 2023-12-05 01:00, David C. Rankin wrote:
On 12/4/23 21:56, Darryl Gregorash wrote:
On 2023-12-04 20:52, Carlos E. R. wrote:
On 2023-12-05 03:37, Darryl Gregorash wrote:
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
Yet the processor has those types,, I assue so someone uses them.
Yeah, if you are working, for example, at places like CERN or LIGO.
Precisely!
/* estimate the solar declination angle (in radians) */ sp.decl = 0.006918 - 0.399912 * cos(sp.fracyr) + 0.070257 * sin(sp.fracyr) - 0.006758 * cos(2 * sp.fracyr) + 0.000907 * sin(2 * sp.fracyr) - 0.002697 * cos(3 * sp.fracyr) + 0.00148 * sin(3 * sp.fracyr);
I rather doubt one needs that much precision for astronomical calculations, especially when working with an object that a) has an angular diameter of approximately 0.5 degrees, and b) is an oblate spheroid whose oblateness isn't really known to very much precision. I used LHC and LIGO as examples, because those are two examples where high precision is really needed. In the case of LIGO, for example, the delay is very, very small between receiving a true wave signal at each detector (gravitational waves travel at the speed of light). With the LHC, the time windows are even more critical, given a) the huge numbers of decay products that happen between the original collision and detection of the final decay products, and b) the relatively small sizes of the detectors. Besides, that equation you give looks to me like a perturbation expansion, unlikely anything close to single precision, and only taken out to 3 terms.
On 12/5/23 01:26, Darryl Gregorash wrote:
I rather doubt one needs that much precision for astronomical calculations, especially when working with an object that a) has an angular diameter of approximately 0.5 degrees, and b) is an oblate spheroid whose oblateness isn't really known to very much precision. I used LHC and LIGO as examples, because those are two examples where high precision is really needed. In the case of LIGO, for example, the delay is very, very small between receiving a true wave signal at each detector (gravitational waves travel at the speed of light). With the LHC, the time windows are even more critical, given a) the huge numbers of decay products that happen between the original collision and detection of the final decay products, and b) the relatively small sizes of the detectors. Besides, that equation you give looks to me like a perturbation expansion, unlikely anything close to single precision, and only taken out to 3 terms.
All depends on the number of coordinate system transformations involved before and after where precision bleed hurts. The transendentals and angular conversions (especially for angles near 0 and Pi). LHC and LIGO are both good examples. Monitoring for 10 billion year old gravity-waves is serious business :) -- David C. Rankin, J.D.,P.E.
On 2023-12-06 21:36, David C. Rankin wrote:
LHC and LIGO are both good examples. Monitoring for 10 billion year old gravity-waves is serious business :)
Fantastic. Now let's get back to the real question I asked you at the start: when was the last time you needed double precision calculation, much less long double?
On 2023-12-05 04:56, Darryl Gregorash wrote:
On 2023-12-04 20:52, Carlos E. R. wrote:
On 2023-12-05 03:37, Darryl Gregorash wrote:
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
Yet the processor has those types,, I assue so someone uses them.
Yeah, if you are working, for example, at places like CERN or LIGO.
Looong ago, when you had to buy the coprocesor separately, I was told that long integers (whatever was the type back then) were needed for finantial calculations. You could not add trillions of dollars and drop a cent out to rounding. I remember the curiosity that the types available to the coprocesor did not match the ieee types, back then. Maybe the Intel people thought differently. I have not read again on the matter, but I am curious what is the status today. Maybe a wikipedia article? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Tue, 5 Dec 2023 12:01:51 +0100, Carlos E. R. wrote:
Looong ago, when you had to buy the coprocesor separately,
80387 you mean? That was a loooong time ago indeed.
I remember the curiosity that the types available to the coprocesor did not match the ieee types, back then. Maybe the Intel people thought differently.
As far as I am aware, the 387 had floating types corresponding to IEEE 754-1985 -- Per Jessen, Zürich (5.6°C) Member, openSUSE Heroes
On 2023-12-05 12:11, Per Jessen wrote:
On Tue, 5 Dec 2023 12:01:51 +0100, Carlos E. R. wrote:
Looong ago, when you had to buy the coprocesor separately,
80387 you mean? That was a loooong time ago indeed.
Or 8087 :-)
I remember the curiosity that the types available to the coprocesor did not match the ieee types, back then. Maybe the Intel people thought differently.
As far as I am aware, the 387 had floating types corresponding to IEEE 754-1985
I think it had those and others of its own. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
* Per Jessen <per@opensuse.org> [12-05-23 06:12]:
On Tue, 5 Dec 2023 12:01:51 +0100, Carlos E. R. wrote:
Looong ago, when you had to buy the coprocesor separately,
80387 you mean? That was a loooong time ago indeed.
I remember the curiosity that the types available to the coprocesor did not match the ieee types, back then. Maybe the Intel people thought differently.
As far as I am aware, the 387 had floating types corresponding to IEEE 754-1985
the 286 required an additional chip for floating point computations, 80287 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-12-05 04:56, Darryl Gregorash wrote:
On 2023-12-04 20:52, Carlos E. R. wrote:
On 2023-12-05 03:37, Darryl Gregorash wrote:
On 2023-12-04 18:24, David C. Rankin wrote:
All,
To celebrate the list working again, I'll pass along something that brought a smile to my face a bit ago. I was looking at help for kcalc, and I noticed a entry for long-double precision and clicked it:
https://paste.opensuse.org/pastes/b1300d1770a4
Remember when user-choice and customization was the touchstone of Linux? Back when the help pages told you about defines to tailor the app to your needs and then a simple:
./configure make make install
The good ole days.... :)
Ordinarily I hesitate to ask silly questions, but when was the last time you needed double precision calculation, much less long double? Never mind it's not even a IEEE standard..
Yet the processor has those types,, I assue so someone uses them.
Yeah, if you are working, for example, at places like CERN or LIGO.
Looong ago, when you had to buy the coprocesor separately, I was told that long integers (whatever was the type back then) were needed for finantial calculations. You could not add trillions of dollars and drop a cent out to rounding. First off, there is a substantial difference between integer data types and float point data types, which is what things like double precision are. Integers can be represented exactly in computer memory, provided one has a large enough number of bytes to represent them. Think bytes, words (2 bytes), double words (4 bytes), and so on. Float point data types are used to store numbers which are not integers. A float point data type contains 3 fields: the sign bit, the exponent field (variable in size, depending on the precision), and the significand field (again, length dependent on the precision). All of these fields are unsigned integers. For example, a single precision number is 32 bits in length, consisting of the sign bit, 8 exponent bits, and 23 bits for the significand, while a double precision number is 64 bits total, containing 11 exponent bits and 52 bits for the significand. This is really getting too long to continue, so I really recommend you go to Wikipedia, starting with https://en.wikipedia.org/wiki/Floating-point_arithmetic
On 2023-12-05 05:01, Carlos E. R. wrote: then continuing to https://en.wikipedia.org/wiki/Double-precision_floating-point_format When you've digested that, you may (well, probably will) have a question about how the number 0 is stored in float-point format. This is simple. If the exponent and significand are both zero, and the sign bit is "don't care", then the stored number is 0.
I remember the curiosity that the types available to the coprocesor did not match the ieee types, back then. Maybe the Intel people thought differently.
Certainly back in the Dark Ages (ie. 30+ years ago), I believe Intel did not follow IEEE format. Today, however, I believe they do use IEEE format.
I have not read again on the matter, but I am curious what is the status today. Maybe a wikipedia article?
On 2023-12-05 05:01, Carlos E. R. wrote:
Looong ago, when you had to buy the coprocesor separately, I was told that long integers (whatever was the type back then) were needed for finantial calculations. You could not add trillions of dollars and drop a cent out to rounding.
Oops, I didn't directly address this point in my earlier post. The names used today for the integer data types are somewhat confusing. Originally there were bytes, words, and double words (8, 16 and 32 bits, respectively). Then came the quadword, which is 64 bits. In the earliest days, the CPUs had only 16 bit general purpose registers. The 386 was the first CPU to have 32 bit GPRs; this was the situation up until the development of the Intel 64-bit IA-64 processors. Since AMD wasn't invited to the table for that, they developed their own, which is today the x86-64, the industry standard since 1999. IBM found themselves forced to follow suit, so today, I don't think you'll find any new processors adhering to the IA-64 standard. OK, enough of the history lesson. Before the appearance of 64-bit processors, you definitely needed to use a math processor, or else do some fancy dancing with integer arithmetic, to be able to handle signed numbers exceeding approximately 2.14 billion (2³¹ -1). With 64-bit GPRs, the largest signed integer that can be handled directly with integer arithmetic exceeds 9.22x10¹⁸ (2⁶³-1), so unless you are doing something fancy like squaring a number in excess of about 3.04 billion, the CPU can handle it with integer math.
participants (5)
-
Carlos E. R. -
Darryl Gregorash -
David C. Rankin -
Patrick Shanahan -
Per Jessen