Where do you see that? I see "No significant associations were found for milk chocolate intake" and "Intake of milk, but not dark, chocolate was positively associated with weight gain."
Ah, I stand corrected: the study starts by stating "After adjusting for personal, lifestyle, and dietary risk factors, participants consuming ≥5 servings/week of any chocolate showed a significant 10% (95% CI 2% to 17%; P trend=0.07) lower rate of T2D compared with those who never or rarely consumed chocolate", but goes on to split by chocolate types and then the positive effect disappears for milk chocolate.
AFAIK I think Igalia is/was working on WasmGC support for Webkit/Javascript Core [0]. Not sure about the status though, it's tracked here I think [1]. It says it's updated earlier this month, but don't know of the progress made.
All messages sent to/received from the cube are encrypted using AES128 in ECB mode with the fixed key 57b1f9abcd5ae8a79cb98ce7578c5108 ([87, 177, 249, 171, 205, 90, 232, 167, 156, 185, 140, 231, 87, 140, 81, 8])
No, Logitech mice and keyboards generally use Logitech's proprietary HID++ protocol which is built on top of standard HID. WebUSB considers HID a "protected interface class" and blocks access to USB HID interfaces. USB HID devices are protected because they include devices like keyboards which handle sensitive user data, such as passwords.
WebHID also restricts access to mice and keyboards, but it uses information available at the HID protocol level to selectively block access to sensitive capabilities while leaving other capabilities unblocked. So, you can't implement an input logger but you can configure LEDs and other device behavior.
In general, WebUSB isn't useful for devices that already have some system-level support. If there's a driver, it will have already claimed the USB interface and needs to release it before the browser can access it. Even if the HID interface class were not protected, you still wouldn't be able to claim it because the USB HID interface is already claimed by the system's generic HID driver. The generic HID driver exposes a non-exclusive "raw" HID interface to applications. WebHID uses this non-exclusive interface which is why it doesn't have the same limitation as WebUSB.
yes, it was fully vetted and open design that had a strong acceptance for the vision impaired. The following Design criteria were considered:
1. durability
2. reuse, repairs and maintenance
3. manufacturability
4. adoption and adherence
5. skill level of the target population to use the device
6. price
Why would you do this instead of just converting the digits to a fraction over a power of 10 and then reducing the fraction (or power of 2, if it's a floating point datatype)? I was thinking it was faster, but the recursive procedure involves a division step, so I would assume that calculating GCD using the binary algorithm (which is just uses shifts and subtraction) would be faster? I guess this is if your numeric data-type can't fit the size of the denominator?
If you assume/know the decimal you got is the result of rounding some computation, and are more interested in a short description than in the most accurate one.
For example 0.142857 would be 142,857/1,000,000 in your algorithm, but ⅐ in one using best rational approximations (which I assume that paper does, as they’re easy to calculate and, according to a fairly intuitive metric, best)
Common Lisp gives you this choice (this being HN, a Lisp mention is obligatory :-)
The CL function #'rational converts a float to a rational assuming the float is completely accurate (i.e. every decimal digit after the last internally-represented one is assumed to be 0), while #'rationalize assumes the float is only accurate to the limit of float precision (i.e. the decimal digits after the last internally-represented one can be anything that would round to the last one).
Both functions preserve the invariant that
(float (rational x) x) == x
and
(float (rationalize x) x) == x
...which is another way of saying they don't lose information.
In practice these tend to be not very useful to me because they don't provide the ability to specify which decimal digit should be considered the last one: They take this parameter from the underlying float representation, which sometimes causes unexpected results (the denominator can end up being larger than you expected) because the input number can effectively have zeros added at the end if the underlying float representation is large enough to capture more bits than you specified when you typed in the number.
In addition, what I really need much of the time is the ability to limit the size of the resulting denominator, like "give me the best rational equivalent of 0.142857 with at most a 3-digit denominator". That function is not built in to Common Lisp but one can write it using the methods in TFA. It loses information of course so a round trip from float->rational->float won't necessarily produce the same result.
> assuming the float is completely accurate (i.e. every decimal digit after the last internally-represented one is assumed to be 0)
Careful though - the float is probably not actually a set of decimal digits but most likely binary ones, so it would be assuming that every binary digit after the last one is zero.
Just because you wrote ‘0.1’ in your source code that doesn’t mean you only have a single significant figure in the float in memory. It’s going to be 0.0001100110011… (repeating 0011 to the extent of your float representation’s precision).
Although the Common Lisp language doesn’t actually appear to require that the internal float radix be 2 - a floating point decimal type would be valid implementation.
> if the underlying float representation is large enough to capture more bits than you specified when you typed in the number.
If you typed in `0.142857` (or however IEEE floats are syntaxed), the correct rational is 142857/1000000. If you want to rationalize relative to number of decimal significant digits, that should be something like `(rationalize "0.142857")` or `(rationalize (radix-mp-float 10 '(1 4 2 8 5 7) -1))`.
That would be correct if the underlying representation were decimal. If it's binary, as it is in most Common Lisps,
(rational 0.142857) --> 9586971/67108864
because the underlying representation is binary, and that denominator is 0x4000000.
My original comment about the representation being large enough to capture more bits than you specified was wrong; the unexpected behavior comes from the internal binary representation and the fact that 9586971/67108864 cannot be reduced.
If you start with integers you get
(/ 142857 1000000) --> 142857/1000000
so you could write a version of #'rational that gives the expected base-10 result, but you'd first have to convert the float to an integer by multiplying by a power of 10.
You might want a simpler representation (smaller denominator) than that will give you.
An example is converting musical pitch ratios to simple fractions (e.g. as used in just intonation).
Literally yesterday I was writing code to do this. The mediant method works beautifully for this, and it can be optimized further than what's presented in the article.
The basic idea to optimize the algorithm (which I got from this [1] SO answer) is to recognize that you only ever update the numerator and denominator of either bound in a linear fashion. So rather than potentially repeatedly update a given bound, you alternate between the two, and use algebra to determine the multiple by which the bound should be updated.
Regarding the intersection of fractions and music, "just intonation" is the term you want to research.
I don't think it's that good. At the very least I implemented it and got different answers for the test case of 0.263157894737 = 5/19 depending on the choice of numerical representation.
float64 ended up at 87714233939/333314088968 while decimal and fraction ended up at 87719298244/333333333327.
Here is the code.
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("Q", nargs="?", default="0.263157894737")
parser.add_argument("--method", choices = ("float", "decimal", "fraction"), default="float")
args = parser.parse_args()
if args.method == "float":
print(f"Using float64 for {args.Q!r}")
one = 1.0
Q = float(args.Q)
int2float = float
elif args.method == "decimal":
print(f"Using decimal for {args.Q!r}")
import decimal
one = decimal.Decimal(1)
Q = decimal.Decimal(args.Q)
int2float = decimal.Decimal
elif args.method == "fraction":
print(f"Using fractions for {args.Q!r}")
import fractions
one = fractions.Fraction(1)
Q = fractions.Fraction(args.Q)
int2float = fractions.Fraction
def to_frac(X):
Da = 0
Db = 1
Za = X
while 1:
Zb = one / (Za - int(Za))
Dc = Db * int(Zb) + Da
N = round(X * Dc)
frac = N / int2float(Dc)
print(f" {N}/{Dc} = {frac} (diff: {X-frac})")
if float(N) / float(Dc) == float(X):
return (N, Dc)
Da, Db = Db, Dc
Za = Zb
print("solution:", to_frac(Q))
Another issue is the numerical range. Consider the input "1.5e-318". It causes overflow in the float, decimal, and fraction implementations I gave:
% python frac.py 1.5e-318 --method float
Using float64 for '1.5e-318'
Traceback (most recent call last):
File "frac.py", line 40, in <module>
print("solution:", to_frac(Q))
File "tmp.py", line 31, in to_frac
Dc = Db * int(Zb) + Da
OverflowError: cannot convert float infinity to integer
% python frac.py 1.5e-318 --method fraction
Using fractions for '1.5e-318'
1/666666666... many 6s removed ...6666 = 1/666666666... many 6s removed ...6666
(diff: -1/666 .. more 6s removed ... 6600.. even more zeros removed ...00)
Traceback (most recent call last):
File "frac.py", line 40, in <module>
print("solution:", to_frac(Q))
File "frac.py", line 35, in to_frac
if float(N) / float(Dc) == float(X):
OverflowError: int too large to convert to float
while with the mediant solution I don't need to worry about the input range beyond infinity and NaN:
>>> from fractions import Fraction
>>> Fraction(1.5e-318).limit_denominator(1000000)
Fraction(0, 1)
(I used the float() calls to ensure the fraction and decimal methods stop at the limits of float64. If I remove them I still end up with numbers like 3/2E319 which would not be representable as a Turbo Pascal integer, while the Turbo Pascal mediant implementation would not have a problem.)
Finally, the mediant solution is easier to implement.
