jfries

Well, yes, using strtok works if the data happens to be structured in a certain simple way. Very often you want to do something more advanced though, and using regex for matching tokens is then necessary.

160 bits per second is actually pretty high. As comparison the German radio time signal used by parts of Europe sends out 1 bit per second: https://en.wikipedia.org/wiki/DCF77

Could also be used to accelerate the print of a single item by having different nozzles work at different parts of the design at once. Would need lots of updates to the slicer and solving some tricky optimization problems.

Would be interesting if this kind of map was used to find previously known wolves by looking for appropriately sized areas not covered by any other wolf.

Cool thinking! The linked printer can be seen as optimized for serialized throughput, whereas in the end the total amount of data transferred is what matters.

So parallelize!

Are there FDM printers with multiple nozzles extruding in the same plane? That seems like an obvious incremental step from regular single nozzle printers.

Probably missing some context, but why is it easier to evacuate in the morning than in the afternoon?

If anybody else is curious how the pattern looks: https://en.wikipedia.org/wiki/Penrose_tiling

In that case wrapper functions can be created where needed to normalize the signatures.

What do you consider good hearing skills to practice, except echolocating?

Seems to me that the size of the star would be a problem. Assuming the process of actually building stuff large enough to cover a star is solved, how do you control the polarizer to get any reasonable bandwidth? The light emitted from one side of the star will be shifted in time relative to the light emitted from the other side, in anything other than a very narrow beam. Targets outside of this beam will not really receive much of a signal due to interference.

While definitely cool, I wonder how effective this is. Code/random binary data should have different characteristics than image data.

This is fantastic and there is great potential, but would be better with better accuracy on driving time, and also public transportation times worldwide. Also an important input is commute start times for each entered address (in case spouses start their work day different times). The above are all acailable through the Google Maps API.

I would happily pay $10 or more for an accurate customized commute map. The rational value is likely way higher for families looking for an area to buy in which good commute times for all.

The gps receiver's software could enter the pin. No buttons necessary.

I don't think it's helpful to think of the structure as being based on a 2x2 grid. A bit down on this page (random Google hit) are ways to structure a character: http://www.guavarama.com/2015/03/07/learning-about-character...

Note that this structure can also apply recursively, further subdividing an area.

> They probably didn't spot this one because it passes too close to the Dead Sea, which is below sea level

This is adressed in the paper. The relevant part of the problem statement: "the longest distance one could drive for on the earth without encountering a major body of water"

and about the Dead Sea: "Guy Bruneau of IT/GIS Consulting services calculated [5] a path from Eastern China to Western Liberia as being the longest distance you can travel between two points in straight line without crossing any ocean or any major water bodies. However, the path crosses through the Dead Sea (which can be considered to be a major water body), and hence does not satisfy the constraints originally set out."

Just don't panic when the cruise ship you're on signals that it is operating in reverse by sounding the horn three times.

I was waiting for the article to mention using those 6 sided pencil stubs in the first image as dice. Seems like a good way to disguise a die.

Wow level 3 there was really elegant. In general I try to find use for a strong type system to force correct code, but here it's Rust's ownership model that ends up saving the day.

Very cool, but can't help to wonder.. What is the likelihood of taking a random picture that captures the start of a supernova? How often does one happen in a given photograph-sized portion of space?

Because astronomics is involved it feels like one of those things that either happens all the time or has a 1 in 10^100 chance of happening.

Is there another plausible explanation here? Some kind of eclipse maybe.

This kind of thing always needs some arbitrary line drawing.

Even if there no external libraries and only pure machine code, that machine code still runs in an environment defined by hardware components, and those hardware components have a lot of thought and effort behind them.

At what level is it no longer cheating?

Wow, that is fantastic! :) it looks like the same idea but developed.

Well if the language is flexible enough it doesn't have to be a big annoyance to have types for both fp32 and nnfp32 (no-NaN fp32). nnfp32 guarantees things that a fp32 doesn't, for example that comparison is always legal and works as expected.

This way you can perform calculations on fp32, but then have to sanitize the output before storing it back in the data structure. One way to use the type system to enforce sanitation could be if values in a database are of type nnfp32, and the only way to produce a nnfp32 is using a function which returns Option<nnfp32>, returning Some only if the value is not NaN.

This is definitely nice. But I'm thinking that NaN is a bit like null, in that it's a surprising value that may pop up which suddenly means something completely different, and code must handle it correctly.

Just as some languages (like Rust) provide a way to say that a variable can't be null, I think it would make sense to have a floating point value that can't be NaN. Comparison of two non-NaNnable floating point value can then just return a boolean, because we know it will never fail.

Sure, the worst case would have a large number of re-calculations. But it seems like the common case would converge quickly.

Do you really need to regenerate the whole dynamic programming table though? It seems to me that it could be kept more conservative and only recalculate the needed parts.

  A dump of memory (several kilobytes, megabytes or whatever) is inherently big endian: it proceeds from the base address and goes up.

It only looks "inherently big endian" when you print bytes on each line starting from the left. This way of printing numbers makes little sense as you end up with some kind of mixed-endian where the bytes are ordered one way and the bits another way.

Start each line with bytes from the right instead to make the bytes and bits numbering consistent, and you can print large little-endian dumps with all bits and bytes are where you expect them to be.

I don't understand what you mean. Line breaks can be inserted where ever suitable. Whether the bytes are listed left-to-right or right-to-left makes no difference.

Not at all, you just list the whole dump right-to-left. Then it works out regardless of word size.

  Little-endian is slightly more confusing for humans

I've heard this before, but the reason is that you view hex data and list numbers left-to-right as if they were letters. They are not.

0x12345678 stored big-endian, numbering bytes left-to-right:

  12 34 56 78

Looks good, but I think that this is actually more confusing, because when you number the bytes and bits you will see that the bytes are written left-to-right, while at the same time the bits are written right-to-left.

The solution is to show dumps with bytes numbered right-to-left. This is coherent with how we number bits, and also how we relatively position digits in any other number.

0x12345678 in little-endian, but written right-to-left:

  12 34 56 78

Now the numbering of the bytes is consistent with the numbering of bits. You can easy see that bits 0-7 of the bits interpreted as a 32-bit word belong in byte 0, while bits 16-23 belong in byte 2.

For what it's worth, "Barcode Scanner" on Android was able to scan it effortlessly.