Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion
On Sat, Dec 18, 2021 at 11:33 AM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > On 2021-Dec-18, at 09:30, Ed Maste wrote: > > > On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > >> > >> I'm confused, beyond just LGPL claims in the (fairly > >> current) source code, but GPL more generally: > >> > >> # grep -rl "SPDX.*GPL" /usr/main-src/ > > > > You need to exclude the ones with SPDX tags like: > > SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 > > > > but also note that this text in README.md is just documenting the > > top-level gnu/ subdirectory. > > # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|Linux-OpenIB)" > | grep -v sys/contrib/device-tree/ | more > /usr/main-src/sys/gnu/gcov/gcc_4_7.c:// SPDX-License-Identifier: GPL-2.0 > /usr/main-src/sys/gnu/gcov/gcov_fs.c:// SPDX-License-Identifier: GPL-2.0 > /usr/main-src/sys/dts/include/dt-bindings/soc/qcom,tcsr.h:/* > SPDX-License-Identifier: GPL-2.0 */ > > But . . . > > # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|Linux-OpenIB)" > | grep sys/contrib/device-tree/ | wc > 31049958 345089 > Yea, that doesn't matter that much... Those are generally not used for tier 1 platforms, except for some arm64 boards. And when they are used, they create a separate work (the .dtb files). And that's even assuming these files are expressive enough to have enough creative content that a copyright could attach... It's not used at all the build kernels, userland, etc (though one does have an option to attach a dtb to a kernel, to be fair). And they are all well marked with SPDX tags, so we're not misrepresenting anything and the project's use of them is in full compliance with whichever GPL they are released under. Downstream users will, as with all license things, need to ensure their uses comply. There have been various statements about these files over the years which one should consult if one ships a system with the .dtb w/o the .dts sources to determine compliance measures necessary (though the standard GPL measures will work, some folks have disclaimed the need to do them for their .dts files, ymmv). Warner
Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion
On 2021-Dec-18, at 09:30, Ed Maste wrote: > On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: >> >> I'm confused, beyond just LGPL claims in the (fairly >> current) source code, but GPL more generally: >> >> # grep -rl "SPDX.*GPL" /usr/main-src/ > > You need to exclude the ones with SPDX tags like: > SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 > > but also note that this text in README.md is just documenting the > top-level gnu/ subdirectory. # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|Linux-OpenIB)" | grep -v sys/contrib/device-tree/ | more /usr/main-src/sys/gnu/gcov/gcc_4_7.c:// SPDX-License-Identifier: GPL-2.0 /usr/main-src/sys/gnu/gcov/gcov_fs.c:// SPDX-License-Identifier: GPL-2.0 /usr/main-src/sys/dts/include/dt-bindings/soc/qcom,tcsr.h:/* SPDX-License-Identifier: GPL-2.0 */ But . . . # grep -r "SPDX.*GPL" /usr/main-src/ | egrep -vi "(mit|bsd|Linux-OpenIB)" | grep sys/contrib/device-tree/ | wc 31049958 345089 === Mark Millard marklmi at yahoo.com
Re: What to do about tgammal?
> On 18 Dec 2021, at 17:51, Steve Kargl > wrote: > > On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote: >> >> Hmm. I think my understanding of ULP is missing something? >> >> I thought that ULP could not be greater than the mantissa size >> in bits? >> >> I.e., I thought it represents average rounding error (compared with >> "perfect rounding"), not truncation error, as the above very large >> ULPs suggest. >> > > The definition of ULP differs according which expert you > choose to follow. :-) For me (a non-expert), ULP is measured > in the system of the "accurate answer", which is assumed to > have many more bits of precision than the "approximate answer". > From a very old das@ email and for long double I have Thank you! I checked the definition that I was used to, and it is roughly "how many bits of the mantissa are inaccurate (because of rounding error)". I can see how both work. For utterly massive numbers like from Gamma(), I can see how accounting for a much larger range works. It still feels slightly tricky, as e.g. how many digits after the floating point do you account for? > I don't print out the hex representation in ld128, but you see > the number of correct decimal digits is 33 digits compared to > 36. Looking good! M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion
On Sat, Dec 18, 2021, 10:31 AM Ed Maste wrote: > On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > > > > I'm confused, beyond just LGPL claims in the (fairly > > current) source code, but GPL more generally: > > > > # grep -rl "SPDX.*GPL" /usr/main-src/ > > You need to exclude the ones with SPDX tags like: > SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 > > but also note that this text in README.md is just documenting the > top-level gnu/ subdirectory. > Yes. Readme.md has never been a comprehensive guide to license compliance. I'm working on revamping the project's license policies to be more in line with current industry practices. Warner >
Re: What to do about tgammal?
On Sat, Dec 18, 2021 at 10:41:14AM +, Mark Murray wrote:
>
> Hmm. I think my understanding of ULP is missing something?
>
> I thought that ULP could not be greater than the mantissa size
> in bits?
>
> I.e., I thought it represents average rounding error (compared with
> "perfect rounding"), not truncation error, as the above very large
> ULPs suggest.
>
The definition of ULP differs according which expert you
choose to follow. :-) For me (a non-expert), ULP is measured
in the system of the "accurate answer", which is assumed to
have many more bits of precision than the "approximate answer".
>From a very old das@ email and for long double I have
/* From a das email:
*
* ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(accurate).
*
* I use:
*
* mpfr_sub(err, accurate, approximate, RNDN);
* mpfr_abs(err, err, RNDN);
* mpfr_mul_2si(ulpx, err, -mpfr_get_exp(accurate) + LDBL_MANT_DIG, RNDN);
* ulp = mpfr_get_d(ulpx, RNDN);
* if (ulp 0.506 && mpfr_cmpabs(err, ldbl_minx) 0) {
* print warning...;
* }
*/
Here, "err = |accurate - approximate|" is done in the precision
of the "accurate answer", and RNDN is round-to-nearest. The
line 'mpfr_mul_2si(...)' is doing the scaling to manipulate the
exponent of the radix 2.
This is agreement with Goldberg. IIRC, Jean-Michel Muller et al
have much more detailed discussion about error and ULPs in their
book "Handbook of Floating-Point Arithmetic".
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
So, on ld80 and tgamma, I have
% tlibm -l -x 8 -X 1755 -n 10 -P tgamma
Interval tested for tgammal: [8,1755]
ulp <= 0.5: 90.207% 90207 | 90.207% 90207
0.5 < ulp < 0.6: 7.085% 7085 | 97.292% 97292
0.6 < ulp < 0.7: 2.383% 2383 | 99.675% 99675
0.7 < ulp < 0.8: 0.314% 314 | 99.989% 99989
0.8 < ulp < 0.9: 0.011%11 | 100.000%10
Max ulp: 0.853190 at 9.236118561185611856579e+02
The "ulp <= 0.5" line indicates the number of correctly
rounded case. If the value of ULP exceeds 1, then you are
starting to lose more than 1 bit in the significant. Consider
individual points. Here's a correctly rounded case:
% tlibm -l -a 9.23611856118500 tgamma
xu = LD80C(0x93c72441a44a57a9, 3, 9.2361185611849994e+00L),
libmu = LD80C(0x82f85b3fe4b36f9b,16, 6.70567128873706962722e+04L),
mpfru = LD80C(0x82f85b3fe4b36f9b,16, 6.70567128873706962722e+04L),
ULP = 0.42318
Notice, ULP < 0.5 and the bits in libm and mpfr answer rounded to
long double are all the same as is the decimal representation. Now
consider the max ULP case:
% tlibm -l -a 9.236118561185611856579e+02 tgamma
xu = LD80C(0xe6e728a690c4fa87, 9, 9.23611856118561185658e+02L),
libmu = LD80C(0xba6bea661a7eda3c, 7762, 5.7294439856327202e+2336L),
mpfru = LD80C(0xba6bea661a7eda3d, 7762, 5.7294439856327245e+2336L),
ULP = 0.85319
ULP is < 1, which is desireable. The bits agree except for the
last place where we're off by 1, ie, 0xc vs 0xd. The decimal
representation is of course off.
So, now on grimoirei without my patch, I have
% ./tlibm_libm -l -a 1.59255925592559255925592559255925594e+01 tgamma
x = 1.59255925592559255925592559255925594e+01L
libm = 1.06660136733166064453125e+12L
mpfr = 1.06660136733166211967839038834033459e+12L,
ULP = 13932370826141802496.0
You have 16 correct decimal digits out of 36, which is the best
you can expect from mapping tgammal to tgamma. ULP is significant
larger than 1. The ulp is almost guaranteed to be larger than
2**(113-53).
Now with my patch and worse case for 1 x in [10:16]
% ./tlibm_lmath -l -a 1.59255925592559255925592559255925594e+01 tgamma
x = 1.59255925592559255925592559255925594e+01L
libm = 1.06660136733166211967839038834033897e+12
mpfr = 1.06660136733166211967839038834033459e+12L,
ULP = 41.40877
I don't print out the hex representation in ld128, but you see
the number of correct decimal digits is 33 digits compared to
36.
--
Steve
Re: git: 30780c3f584a - stable/13 - README.md: correct GPL expansion
On Fri, 17 Dec 2021 at 11:09, Mark Millard wrote: > > I'm confused, beyond just LGPL claims in the (fairly > current) source code, but GPL more generally: > > # grep -rl "SPDX.*GPL" /usr/main-src/ You need to exclude the ones with SPDX tags like: SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0 but also note that this text in README.md is just documenting the top-level gnu/ subdirectory.
Re: What to do about tgammal?
> On 18 Dec 2021, at 03:52, Steve Kargl > wrote: > > On Tue, Dec 14, 2021 at 10:21:55PM +, Mark Murray wrote: >> On 14 Dec 2021, at 21:51, Steve Kargl >> wrote: >>> Interval max ULP x at Max ULP >>> [6,1755.1]0.873414 at 1.480588145237629047468e+03 >>> [1.0662,6]0.861508 at 1.999467927053585410537e+00 >>> [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 >>> [-1.,-1.0001] 3.157770 at -1.246957268051453610329e+00 >>> [-2.,-2.0001] 2.987659 at -2.220949465449893090070e+00 >>> >>> Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or >> >> Extra diffs most welcome! >> > > Hi Mark, > > Don't know if you noticed, but I borroewed a few cpu cycles > from grimoire. Didn't notice a thing! :-) > My WIP is already better than the imprecise.c > kludge from theraven@. I need to work out the details of > computing logl(x) in extra precision or see if I can leverage > what Bruce did a few years ago. Anywho, current results: > > Interval tested for tgammal: [128,1755] > count: 100 > xm = 1.71195767195767195767195767195767183e+03L > libm = 7.79438030237108165017007606176403036e+4790L > mpfr = 7.79438030237108165017007606175285456e+4790L > ULP = 14869.19517 > > Interval tested for tgammal: [16,128] > count: 100 > xm = 1.27687183687183687183687183687183690e+02L > libm = 6.61421998891483212224382625339007663e+212L > mpfr = 6.61421998891483212224382625338960267e+212L > ULP = 731.00958 > > Interval tested for tgammal: [10,16] > count: 100 > xm = 1.54261654261654261654261654261654251e+01L > libm = 2.74203137295418912508367515208072654e+11L > mpfr = 2.74203137295418912508367515208073861e+11L > ULP = 45.61161 > > Interval tested for tgammal: [1.2446e-60,10] > count: 100 > xm = 6.26200626138006138006138006138006065e-02L > libm = 1.54507103764516989381203274093299079e+01L > mpfr = 1.54507103764516989381203274093299091e+01L > ULP = 0.76751 Hmm. I think my understanding of ULP is missing something? I thought that ULP could not be greater than the mantissa size in bits? I.e., I thought it represents average rounding error (compared with "perfect rounding"), not truncation error, as the above very large ULPs suggest. M -- Mark R V Murray signature.asc Description: Message signed with OpenPGP
