- The toast disappears quickly, so you might not have time to read it / take a screenshot

- It's not possible to copy the text

- Long text is truncated (e.g. exception messages)

I've been really impressed with Wolfram Alpha over the years (both the natural language parsing and the power of Mathematica); my main issue until now has been that the natural language parser tends fail on inputs beyond some length (fortunately Mathematica syntax is also supported and works well). So I was very surprised when this glaring bug in math input mode was shared with me.

Full steps to reproduce:

1. Go to https://www.wolframalpha.com/

2. Click "MATH INPUT"

3. Click the "power" button (second from the right, icon is two boxes with one in superscript)

4. Type "e" (it should go in the first box)

5. Click the superscript box

6. Type "2n"

7. Click the "=" button

Result: The input field correctly shows e²ⁿ (with the "n" in superscript), but the formula shown in the "Input" section is e²n (the "n" is outside the exponent) and the "Plot" section shows a straight line which confirms that the input was misinterpreted as e² * n.

Explicitly adding parentheses around the "2n" fixes this. Ironically, when you do that the "Input" section shows the formula as e²ⁿ (without the parentheses; the same version that fails when entered in the input field).

Comments URL: https://news.ycombinator.com/item?id=41299507

Points: 4

# Comments: 2

  ps() { for i in /proc/[0-9]*; do readarray -d '' -t cmdline < "$i/cmdline"; printf "%s: %s\n" "${i#/proc/}" "${cmdline[*]}"; done; }

> The slow cases usually tend to be trying to find wider slots and skipping through many smaller slots. There are often a lot of bookings up to the first wide enough slot too though, so it's a little bit of both.

This right here is the first critical issue. It doesn't matter how fast the data structure is if you're then going to do a linear search over the available slots to find the next one wide enough.

A good data structure for doing this efficiently is a range tree (https://en.wikipedia.org/wiki/Range_tree), where in each node you store the maximum width of the available slots covered by the node. That lets you find the first available slot after some time t and wider than some duration w in O(log(n)), where n is the number of available slots. (It might not be obvious if you're not familiar with range trees; I'm happy to provide more details.)

For the implementation, there are a few options:

A. The simplest is to use a complete range tree, where the leaf nodes are all the possible times. You can lazily create nodes to avoid massive memory usage for sparse ranges. The advantage is that you don't need to do any balancing; the disadvantage is that the time complexity is O(long(T)) where T is the total number of possible times; so it's going to be a little slower on very sparse datasets.

B. The O(log(n)) implementation that's being called for is a self-balancing binary tree (e.g. red-black), modified to also store the maximums in each node. Unfortunately most libraries don't give you low-level control over the tree's nodes, so you'd likely need to copy the code and modify it (or implement the self-balancing tree from scratch).

C. If those are still too slow (and you're certain that your implementation is really O(log(n))), you'll need to improve the cache efficiency. That basically comes down to using larger nodes. The obvious approach is to switch to a B-tree; but you could also keep your nodes binary and just change the way they are allocated to emulate the memory layout of a B-tree (this is simpler but slower because it still uses lots of pointers). Another idea is to replace the first few layers of the tree with a hash table (or a simple array if your data is dense enough). Likewise you can replace the leaf nodes with small arrays.

This is a temporary suspension while investigating "after media companies complained it was allowing users to upload their content without permission".