Motorola M68000 Family Programmer's Reference Manual (1992) [pdf] - <AUTHOR> http://cache.nxp.com/docs/en/reference-manual/M68000PM.pdf <comment><USER2> 68k was the easiest 'language' I ever learned. You had the reference manual, the instruction timings, no middleware, it was awesome and I made my future career from the age of 12 by writing Amiga / ST stuff.

Best thing is - it was me against the machine. If anybody did something that moved more sprites than I did, or did better parallax, it was because they were better than I. No driver incompatibility to blame. I loved programming in 1984, it made me tolerate less shit and produce better code than people who were less fortunate to be born later.

I miss those days :(

<comment><USER3> I feel ya. The 68k days were glorious indeed. I'm sure things weren't _really_ as good as I remember them, but man the nostalgia pull is real. I agree with the Raspberry Pi people, it's a lot harder to hack on stuff than it used to be.

<comment><USER4> I completely missed the heyday of microprocessor programming, but I wholeheartedly disagree that hacking on things is harder than it used to be. TI-84 calculators are $100 and let you write Z80 assembly, 68k microprocessors are available for less than $10 from any number of sources, easily available documentation and 30+ years of experience to draw on, freely available plans for whole systems so that you don't actually have to figure anything out yourself, or you can bypass all that and build your own processor in a circuit simulator, like I did, or learn HDL and buy a cheap FPGA and run it for real, or use something like python to control your parallel port with single lines of code connected to a webserver if you don't mind being silly.

Heck, if I want to, I can even massively hack things, write kernel drivers for linux OR windows, do basically whatever I want. Some of them are harder than others, and some are more intended than others, and some require more time than others, but the world of hacking is still one of possibility. Pretty much the only locked down systems are smartphones, which sucks, but I just bought a raspberry Pi zero W for 10 dollars, which is incredible compared to the Basic Stamp 2 micro controller that cost $120 just a decade ago.

Literally the only difficult (at least IMO) thing for hacking whatever you want is analog circuits. I still massively struggle with that.

<comment><USER3> Good points. When I think of hackability tho, I think about the devices and "toys" that I already have. Back in the day you just hacked on what you already had. Also, most of the time you were a kid or teenager that couldn't even afford the 10 bucks for the pi, so unless your parents bought one, you were out of luck. I had to take apart my dad's VCR and computers and stuff in order to learn.

But for an older person, you make some great points.

</comment></comment></comment></comment><comment><USER5> Back in the 1980's, I took one of these chips and ran four copies of the same OS on it, using some virtual memory and driver magic. The full story can be found at [http://jeff-barr.com/2008/01/08/inmsx-running-4-copies-of- an...](http://jeff-barr.com/2008/01/08/inmsx-running-4-copies-of-an-operating- system-at-once/) .

<comment><USER6> Wow dude, you're amazing! How are you able to dig so far into (extremely technical, difficult!) uncharted territory without getting diverted one way or another - frustration, "too hard", give up, etc.? ESPECIALLY since you did it all without the galaxies of information and well-tred paths available today!

<comment><USER7> There was no Internet to distract him.

</comment></comment></comment><comment><USER8> I think one of the greatest things about the M68K _today_ is that it's a relatively powerful processor that's relatively straightforward to program _and_ it's pretty easy to design hardware that uses it.

A single board computer with the m68k is still small enough that you can comprehend the schematics and build it at home (e.g. [http://www.kswichit.com/68k/68k.html](http://www.kswichit.com/68k/68k.html) ), and it's a very valuable learning experience.

<comment><USER9> Are new M68K chips still produced? I looked a while ago, but couldn't find any.

<comment><USER10> Barely. The 68SEC000 is still in production, but is NRND.

<comment><USER11> What about the second-source vendors? Historically I know there were Hitachi ("HD" prefix), Toshiba ("TMP" prefix), and Signetics ("SN" prefix) parts. At one point I saw a modern-looking Atmel data sheet for a TS68C000 (Thomson/STMicro license?), but I don't know how recent that actually was.

The Hitachi line, at least, seems to be explicitly EOL by Renesas. I'm not familiar enough with the other vendors to know who might have picked up their licenses.

<comment><USER10> I suspect those are all gone too. TS68C000 went EOL in 2010 -- it was produced by Thomson-CSF, which was acquired by e2v.

One interesting avenue to explore might be the Sega Genesis. It's still being produced in Brazil, believe it or not -- and there must be some sort of 68000-compatible processor at the core of those.

</comment></comment></comment></comment></comment><comment><USER12> I still program the 68K today in K&R C. I recently released a Dropbox client for Tandy XENIX.

[http://pski.net/trs-box-xenix/](http://pski.net/trs-box-xenix/)

</comment><comment><USER13> Back in the 80's, I wrote a letter to their documentation department asking how much certain manuals were (I was a fan). I got a box of manuals in the mail instead of a price list. They sent the references for both the 68000 and 6809. It was funny when I got to college and one of the EE courses involved programming of a 6809. Its a true shame their isn't a 64-bit 68000 as it is such a nicer processor than the x86.

<comment><USER14> They never charged for manuals, as far as I know. I have a whole bookshelf of 68K and PPC books, datasheets and references.

</comment></comment><comment><USER15> The 68K was such a glorious processor to program, especially after coming from the 6502. Hardware multiply and divide? Sign me up! :D

The assembly code looked like poetry.

<comment><USER16> M68k assembler was so straightforward and beautiful. Easy to read and easy to write. Too bad that the monstrous x86 won out.

<comment><USER15> Totally agreed. The first time I saw x86 assembler I almost cried.

<comment><USER17> My first computer had an Intel 8080 so when I got a 6502 it seemed so backward. How could you do anything with that? Then when the 68000 came along it was wonderful and put both the others to shame. I never understood why IBM didn't use it. I still have a hard copy of a preprint of the 68K manual dated 1979.

<comment><USER18> From [http://yarchive.net/comp/ibm_pc_8088.html](http://yarchive.net/comp/ibm_pc_8088.html)

> 68000 was carefully considered. "AN excellent architecture chip, it has > proven to be a worthy competitor to the Intel-based architecture." there wer > four major concerns:

> 1) 16 bit data path would require more bus buffers, therefore a more > expensive system board.

> 2) more memory chips for a minimum configuration.

> 3) while it had a performance advantage, the 68000 was not as memory > efficient.

> 4) Companion and support chips not as well covered as Intel.o

> He also felt the the 68000 didn't have as good software and support tools, > and the similar register model allowed the porting of 8080 tools to the > 8086/8088.

> "In summary the 8088 was selected because it allowed the lowest cost > implementation of an architecture that provided a migration path to a larger > address space and higher performance implementations. Because it was a > unique choice relative to competitive system implementations, IBM could be > viewed as a leader, rather than a follower. It had a feasible software > migration path that allowed access to the large base of existing 8080 > software. The 8088 was a comfortable solution for IBM. Was it the best > processor architecture available at the time? Probably not, but history > seems to have been kind to the decision."

I don't remember where I read about it, but I remember reading about that IBM ditched the 68008 (8 data bit bus version, like the 8088) because some problem with it... availability of it, perhaps.

</comment></comment></comment></comment></comment><comment><USER19> Did anyone else get into ASM coding through the TI-89 (M68K) and TI-83 (Z80)? I had so much fun drawing sprites on graph paper and working on random projects and games I was thinking about.

Sharing them with my friends through the cable that went into the headphone jacks. The fun of seeing somebody at my school I didn't really know getting a kick out of something I made.

<comment><USER20> I did ASM on the TI-83 when I was in high school. Self-taught from the reference manual. Didn't know how to properly use the stack or write functions in ASM at the time...my code was a mess! Still, was quite a lot of fun with the only danger of having to yank the batteries if you messed up.

By the time I got a TI-89 around 1999, I was in college and just didn't have the time to do anything substantive with programming it.

I'd dust it off, but mine is old enough to just have the I/O port, and don't know that I have any functioning computers with a parallel or serial port for the old TI Link.

<comment><USER10> There are USB versions of the TI-Link.

Alternatively, a while ago I used Emscripten to build an emulator for the TI Voyage 200 (a late revision of the TI-92). There's some minor glitches, but it's mostly functional:

[https://woofle.net/v200/](https://woofle.net/v200/)

</comment></comment></comment><comment><USER21> I wrote this game in the 80's for the Mac in assembler. Loved the 68000! [https://www.macintoshrepository.org/3331-macgolf- classic](https://www.macintoshrepository.org/3331-macgolf-classic)

Wrote some others too: [https://www.macintoshrepository.org/3732-macracquetball](https://www.macintoshrepository.org/3732-macracquetball) [https://www.macintoshrepository.org/3384-road- racer](https://www.macintoshrepository.org/3384-road-racer)

<comment><USER15> Oh my god!! I loved MacGolf!! I think that back in the day I used TMON to break the copy protection scheme (for personal use only, of course!) so many good memories. Thanks so much.

</comment></comment><comment><USER22> In the Air Force, I went to school to learn how to repair and maintain an 18 bit Hewitt-Rand mainframe computer in 1988. It was a four month course taught at Tyndall AFB near Panama City Beach, Florida.

At the time, I was an Amiga fan, and I had this manual. I was totally blown away at how nearly identical the architecture of the M68000 was compared to that mainframe. Imagine my thinking that my Amiga 500 had the equivalent of a room-sized mainframe in that chip!

</comment><comment><USER23> An elegant weapon for a more civilized age.

</comment><comment><USER24> Notice the high quality of documentation. Motorolas were some of the best as I remember it.

<comment><USER14> It was definitely among the very best, but more than 15 years ago I found an error in the E500/Book E reference manual that repeated itself for more than 200 pages. It only was relevant to you if you cared about the actual bit encoding of SPE instructions. Plus there was a random reference to someone named Gary that, obviously, wasn't meant to be there.

Motorola's PowerPC support hotline acknowledged the problem on the same day and published a new version of the manual by the end of the week or the next one. Of course they did, because that's how great they were.

<comment><USER25> But what became of Gary?

<comment><USER14> They never acknowledged Gary, but removed him anyway. The original said

"Scalar floating-point instructions operate on single 32-bit operands that reside in the lower 32-bits of the GPRs. These instructions are considered a proper subset of the SPE APU; this subset is referred to as the SPFPU now called the EFPU Gary cares only that it have embedded in it somewhere."

(more recent e500 chips considered the scalar instructions to be in a separate APU)

</comment></comment></comment></comment><comment><USER26> Good times ... EXCEPT ' you cannot move "word" or "long-word" sized data in and out of memory, if the address is an odd number' .. in other words, a hard fault.. This mis-feature can come up a lot, and was fixed in later CPUs.

[http://mrjester.hapisan.com/04_MC68/Sect01Part06/Index.html](http://mrjester.hapisan.com/04_MC68/Sect01Part06/Index.html)

<comment><USER14> Well, purists would have told you that you had to align your data. Yes, later chips did support misaligned accesses, but that came at a cost: extra bus cycles.

<comment><USER17> And now compilers will make sure your data structures are aligned. Adding circuitry and compromising performance for lazy programmers is a bad idea. This is one thing RISC-V has carried over and I'm not sure they have justified the decision to do so.

<comment><USER27> In some cases, packing data structures with no alignment is more important because it means more data fits in the cache, and cache misses are extremely slow in comparison.

Modern x86 is mostly insensitive to data alignment, since it fetches internally in cacheline-sized blocks (I believe it's 64 bytes) and a very wide barrel shifter is used to access the desired bytes. There's a tiny (single- digit cycles) extra time when the element straddles two cachelines (assuming both lines are in cache)

</comment></comment></comment></comment><comment><USER28> Brings me back in memory lane, where I was a 13-14 yrs old middle-schooler trying to read this extremely thick manual with no or little background in logic design, CPUs etc. Well I could still program, or at the very least hack it to show some graphics, implement sinus scroll from scratch etc :)

</comment><comment><USER29> I started with the 6502, but my second computer was an Atari STE and did a lot of 68k programming. It was great. Then I discovered the book "The Art of Electronics" as a late teen. It had a whole bunch on the 68008 ( which is gone from the current edition ) which was nice for little embedded projects as it interfacedd with the 8 bit world.

[https://en.wikipedia.org/wiki/Motorola_68008](https://en.wikipedia.org/wiki/Motorola_68008)

later on I got to do some work on a 68030 series micro. That was pretty nice also. All assembly based.

</comment><comment><USER30> What is the modern equivalent that kids can use today? Arduino?

<comment><USER31> I am not qualified to answer, so here I go:

If in the USA: Hack a TI-89 calculator. They are still 68K-based, are unfortunately inescapable bricks tied to mandated Maths curriculum, and have an active hacking community.

I re-learned M68K programming via the Palm Pilot, which has a fun SDK clearly inspired by the Classic Macintosh.

I would say that ARM programming can be as fun as 68K, so perhaps a Raspberry Pi to start. You can get closer to the glory days with ARM-M Arduino-like toys such as the Teensy.

I haven't done any assembly-level Arduino programming, so I don't know what that feels like versus 68K. Lots of microcontrollers grew upwards out of the then-popular 8051, which does not feel the same to me.

I got started on the Motorola 6809 CPU and the TRS-80 Color Computer. You could almost call it an 8-bit precursor to the M68K, it is limited but very nice design.

<comment><USER32> Yep, here is a possible starting point with ARM Assembly on the PI.

[https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/i...](https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/introduction.html)

</comment></comment></comment><comment><USER33> Oh, the memories. Being able to predict the exact instructions the compiler would generate. Patching in memory using NOP instructions. Actually being able to write assembler code. Unsegmented memory. It has always disappointed me that Motorola didn't do better in microprocessors but that's water under the bridge.

</comment><comment><USER34> I read old processor manuals for fun as a kid. 68k, x86, the rare ARM or SPARC book...

</comment><comment><USER35> Thanks for posting. Well before my time. But powered some legendary video game consoles such as SNK Neo-Geo and Sega 16.

[http://www.sega-16.com/](http://www.sega-16.com/)

</comment><comment><USER36> [turns to bookshelf] My copy is dated 1984.

<comment><USER37> I have an MC68000 User's Manual edited by Prentice-Hall with the HP logo (and an HP 9800 Computer Systems sub-title) that says December 1981.

<comment><USER38> mine as well (albeit 4th edition, 1984). which is sort of weird because i never saw or touched an M68k HP; i only ever referred to it when debugging stripped binaries on Sun 3s.</comment></comment></comment>


20 months in, Microsoft Ventures shows promise - <AUTHOR> https://venturebeat.com/2017/09/01/20-months-in-microsoft-ventures-shows-promise/ <comment><USER2> I've got a question for those of you who are better versed in teh VC industry than me...

> Over the past year and a half, the Ventures group has made more than 40 > investments, and led or co-led eight of those deals

is there any benefit to being the lead or co-lead in a round?

The only "benefit" I can think of is that you get to be the one who set's the price along with the company. But given the number of stories about fund raising where companies will commit but don't want to be the ones who set the price this doesn't seem to be something that most VC's value.

<comment><USER3> Typically you set the terms as well.</comment></comment>


Science News That Stuck with Us in 2015 - <AUTHOR> http://www.nytimes.com/interactive/2015/12/28/science/2015-top-science-stories.html?rref=collection%2Fsectioncollection%2Fscience&action=click&contentCollection=science&region=rank&module=package&version=highlights&contentPlacement=1&pgtype=sectionfront <comment><USER2> You're forgetting "opiates from engineered yeast". Not quite landing a booster rocket, grappling a comet, or scoring a flyby of Pluto but among biotech types it was kind of a big scientific deal in '15.

</comment><comment><USER3> And CRISPR/cas9</comment>


Forced Out by Deadly Fires, Then Trapped in Traffic - <AUTHOR> https://www.nytimes.com/2018/11/11/us/california-fire-paradise.html <comment><USER2> Australian here. Australia has different wild/bushfires in that the morning is _always_ safe (at least as far as we know for the last 100 years) and easy to evacuate, the danger is in the afternoon. So there is a simple strategy that will always work, let's call it the "Westfield" strategy. If there is elevated risk, grab your irreplaceable and head to your nearest Westfield shopping centre for lunch in the food court. Then see a movie. Then attempt to go home. If your house didn't burn down then I hope you enjoyed your day out. If it did you are still alive. The problem though with this strategy is that chances are, and indeed amply demonstrated by the Victorian 2009 bushfires is that a large number of homes were threatened but only a very small proportion of towns and homes under threat were actually destroyed. Australia being inhabited by happy go-lucky gambler types brings out the worst in us, so people will chance it. (and add to that those without insurance who will stay to protect their asset as they are in a bind)

As to the US, no-one has ever died in traffic save for one single example I found in one canyon fire in California where a police cruiser assisting with evacuations crashed into a tree and blocked the road [You should expect once one person crashes, the next person will crash into them due to poor visibility] and the other end of the road was blocked by the fire and I think some roadworks, I'd need to look it up. That aside evacuation is much safer than "stay in place" particularly as the latter requires a great deal of mental fortitude to remain focussed in dense smoke and loud noise [people fail to do simple things and die], little own having a structure that will provide survivable conditions.

Roads can move a huge number of people even in cars. The only exception to this is to my understanding, again in California where there is a valley with a freeway through it but too many residences and I think limited capacity getting on to the freeway to evacuate everyone quickly.

Takeaway - evacuate early, nobody ever died from evacuating needlessly. Remember its just "stuff", possessions are not worth risking your life.

<comment><USER3> > As to the US, no-one has ever died in traffic save for one single example I > found in one canyon fire in California where a police cruiser assisting with > evacuations crashed into a tree and blocked the road

[http://articles.latimes.com/1991-10-23/news/mn-174_1_fire- vi...](http://articles.latimes.com/1991-10-23/news/mn-174_1_fire-victims)

<comment><USER2> The example you quote is (bar one) people moving as pedestrians rather than with the protection of a vehicle. A vehicle offers a great deal of protection, particularly now with air-conditioning available to give a buffer against the heat. Also a slow moving vehicle moves a lot faster (away from danger) than a fast moving pedestrian. I remember a film, probably made in the 1950's (one of those Magnesium Chloride in your everyday life type thing) about "Always stay in the car in a bushfire, cover yourself with blankets and then put out the fires on the car when the fire has past". If you are out of a vehicle in a bushfire you need to dress appropriately to deal with the radiant heat, long trousers, long sleeves, hat etc. As bushfires are associated with hot weather, sadly, people particularly children are made much more vulnerable by wearing bathers (swimming trunks) and short sleeves when moving. Firefighters cover up with clothing for to deal with the radiant heat, among other things.

<comment> King-Aaron Can I please point out that the radiated heat from a fire will indeed kill the shit out of you even with your air-conditioner running. If you're within safe evacuation times, the car is a good bet, but if you're past the safe evacuation time you'd have better chances by staying put and making do with what you have.

[https://www.cfa.vic.gov.au/plan-prepare/radiant- heat](https://www.cfa.vic.gov.au/plan-prepare/radiant-heat)

(Sauce: I've been involved with volunteer bush firefighters)

<comment><USER4> I had an uncle who got trapped on Mount Macedon in '83 where he spent the night on the floor of a concrete public toilet block.

His car while drivable had the CFA logo magnet welded to the door from the heat of the firestorm.

<comment> King-Aaron Being trapped in a firestorm is a terrifying experience, it sounds like it's a damn good thing your uncle had the sense to find a safe place to take shelter!

<comment><USER4> He was based at the Fiskville training facility for a few years which would have been around that time and explain how he was at Macedon; prior to that he was a station chief so quite experienced.

The way he described the houses around them imploding and how the fire would rush out, take something and then suck back into itself sounded like a nightmare.

It was enough for him to have left the CFA a few years later.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> For first hand accounts and excellent reporting on the Camp fire take a look at the Blancolirio channel on YouTube.

Juan Brown does some great work and has some very interesting content, such as exclusive access to the VLAT refueling and refilling operation, a 50+ minute interview with one of the nurses that helped evacuate the hospital, and he lives just 40 miles from the fire, so lived it's effects.

He also has some truly brilliant content on the Oroville Dam, the near disaster and the subsequent multi year rebuild project.

[https://www.youtube.com/user/blancolirio](https://www.youtube.com/user/blancolirio)

<comment><USER6> There was a firsthand video where a guy came back after the fire was over to find his neighbors as a bunch of skeletons inside their burnt cars.

"I went to their house right here in this white car to get them out.

She had to put her makeup on.

She died because of it."

[https://www.youtube.com/watch?v=4rmu2-P18Is](https://www.youtube.com/watch?v=4rmu2-P18Is)

<comment><USER7> I'd wager that most of the people who managed to die in this fire were doing things that seem inexplicably superficial in their final moments.

<comment><USER8> There was a famous fire in a mall where most of the people who died were in one particular restaurant.

It's because they all tried to pay before they left, the lost time killed them.

The idea haunts me because it was 100% the correct thing to do, they had no idea how bad the fire would be. I even know this design flaw but I still would queue to pay before leaving if a fire alarm went off in a mall.

<comment><USER9> When there is a fire alarm, the only 100% correct thing to do is evacuate the area immediately.

<comment><USER10> But this is in some sense a failure to learn from experience. Every experience of a fire alarm is non-fatal except the last one.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> This is the key quote: _"I don't know that you could build the infrastructure to evacuate an entire town that quickly,"_

I don't feel like this is thought through, not for the wildfires, not for the hurricanes. How do you move 100,000 people out? A little paper exercise should suggest the scale of this problem, and how unprepared everyone is.

<comment><USER11> My instinct is to say buses, and don't wait too long. Let's do some math:

Edit: Corrected math. Thanks!

You can easily fit 20 people/bus. So that's 5,000 bus rides. 2000 busses/hour/lane is a reasonable estimate. They had a 4 lane road, 2 lanes in each direction, so 4000 buses per hour. Divide capacity by 2 to account for inefficiency and round up to get to 3 hours

That's a lot of busses, but not an unreasonable number.

To hit those numbers you have to be forcing people to evacuate by bus. If they try and take a car you need to stop them before they jam up the road. American's aren't going to take that easily. Of course you can encourage them to evacuate by car _before_ you start the mandatory by bus evacuation. It's not like forest fires come with 0 warning.

<comment><USER12> Where on earth do these busses come from? Do you propose we should be ready to produce an army of busses anywhere in the US at a moment's notice?

<comment><USER13> Anywhere with a reasonably anticipated need to evacuate, yeah.

<comment><USER14> In other words, this falls flat as "reasonably anticipated" gets shot down by cost.

<comment><USER13> Human life is generally worth more than the corresponding proportion of a bus.

<comment><USER14> Correct. This is, however, a sentiment which is only expressed during a catastrophe. Give it a few weeks, and see the bean-counters deny this again.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> I think the long term answer here is to either not rebuild or mandate that the houses be built to a wildfire proof standard. Stucco, tile, ember and flame proof soffits etc... and maybe fire shutters and doors.

<comment><USER9> "Built to Burn" is a great podcast episode from 99% Invisible that talked about wildfire prevention and mitigation techniques. It mainly comes down to proper home and surroundings design to prevent the _spread_ of fire, letting it burn itself out.

[https://99percentinvisible.org/episode/built-to- burn/](https://99percentinvisible.org/episode/built-to-burn/)

<comment><USER16> Look at aerial views of the Paradise fire area -- trees survived almost everywhere where buildings burned to the ground.

</comment></comment></comment><comment><USER17> I was in Paradise the morning of the fire. Does anyone have any questions?

<comment><USER18> Have you lived there? I heard that the town had done some sort of evacuation practice after a big fire in ...2008 I believe? How did the previous practice inform the evacuation this time?

<comment><USER17> Yes, I've lived in Paradise many years and was in town for the 2008 fire. I heard that since the 2008 fire the town debated making bigger roads but instead decided on breaking the town into zones and evacuating by zone. This fire was very unusual in that within a couple of hours it seemed to have spread to many location across town. At my location by 745am (the fire begin 10 miles from town at 630am) there were many bits of burnt bark and leaves raining down all around. Many of these were likely falling in different locations as embers. The town is in an area of frequent fires, it's not uncommon to have nearby fires, they generally move in the order of a day so a zoned evacuation in many normal cases could work. I've never seen a fire that moved this quickly.

<comment><USER18> Thanks for your assessment.

> I've never seen a fire that moved this quickly.

I've been hearing a lot of this of late.

</comment></comment></comment></comment><comment><USER19> Interesting. When New Orleans or Texas flooded we heard about how we shouldn't build in places prone to natural disasters. Much less of that talk here about building in the forest.

</comment><comment><USER20> I would think survivable shelters should not be too hard to build if you also place oxygen tanks with breathing masks there as well. After all some properties already have swimming pools, which together with breathing masks should do the trick.

<comment><USER21> shelters might do well in brushfires. Not sure how they do when huge trees are on fire.

Long term solution: don't build there. Even evacuations don't work: nah, my house is too far...I'll leave in a bit...let me just get a few more things etc etc.

<comment><USER22> I imagine underground shelters would be workable. Heat tends to rise, and ground seems like a good insulator. You would still probably need to get rid of most air circulation with the outside, and come up with some plan for safely exiting.

</comment></comment></comment><comment><USER23> Same thing happened in Greece recently...The roads were so narrow that people were burned alive...

</comment><comment><USER24> I know people on Hacker News have no love for multi-level concrete parking garages, but it seems to me that such structures could easily be engineered to withstand the effects of a fire like this one. This way residents could shelter in place, or at least shelter "nearby", in the event of similar massive, fast-moving fires.

If you built structures like this in most every neighborhood, well, I guess they'd be big eyesores, but then, on the other hand, you could get rid of a bunch of on street parking.

<comment> ui-explorer12 if you think a giant concrete parking structure would (a) work to shelter in place in the face of a giant, wind-powered fire or (b) be appropriate in a northern California locale like paradise you are more out of touch than the president telling us we need to "rake the forest floor". I don't want to come down too hard on someone proposing an idea in good faith, but you need to dramatically re-align your perspective to truly understand the scale and scope of this problem.

We can't use simple buildings to mitigate this; it's not a minor change to forest practices. It is a fundamental convergence of decades-old policies, millions of people living in the forest interface and global climatic changes.

<comment><USER24> > _... you are more out of touch than the president telling us we need to > "rake the forest floor". I don't want to come down too hard on someone > proposing an idea in good faith, ..._

I think this is a terrible response. If you want to disagree with me I think you can do it without being a jerk.</comment></comment></comment>


eBay port scans visitors' computers for remote access programs - <AUTHOR> https://www.bleepingcomputer.com/news/security/ebay-port-scans-visitors-computers-for-remote-access-programs/ <comment><USER2> This site is a standard reblogger. They just regurgitate stuff that they find on other sites or even reddit and Facebook. They don't add anything new to the story. If anything they take away some context from when it was originally reported. I some how despise it a lot, the y provide no value but consistently take away advertisement dollars and clicks from the original author.

<comment><USER3> Bleeping isn't churnalism. Daft name, so for the longest time I assumed it was garbage, but Lawrence and crew actually do good work.

</comment></comment><comment><USER4> Previous discussion: [https://news.ycombinator.com/item?id=23246170](https://news.ycombinator.com/item?id=23246170)

<comment><AUTHOR> Ah, sorry. I searched HN stories for "eBay" and didn't find anything. Not sure why that story's author chose "This Website" for the title.

<comment><USER5> Your article links to that exact story though.

<comment><AUTHOR> Yes, and the vague article title was a big reason I submitted this one instead. :-)

I thought about submitting the other article with my own title, but I didn't want to "editorialize".

</comment></comment></comment></comment><comment><USER6> This is suppose to help with fraud? Lets be serious for a moment. The only thing that this is going to change is that the supposedly hacked computers will no longer run VNC on standard ports.

I think what we might be seeing here is the outcome of some overpaid consultant's claim that they can protect ebay from fraud with 'sophisticated' malware detection.

<comment><USER7> Let's be serious for a moment. A computer that is hacked and running remote access programs poses a MUCH higher risk of account hi-jacking for ebay and paypal purposes than another computer.

Feed that into a system that monitors lots of other inputs, and you start to build improved fraud detection systems. Most of these systems benefit significantly from long tail / long history monitoring - all the other providers of systems in this space try to get beacons onto virtually all the pages you visit, monitor all mouse and other movements you carry out etc.

Why not this pretty simple and straightforward explanation vs something complicated about overpaid consultants? Amazon does $80B of sales or something per year. Each 1% of fraud on this platform is worth $800 million. How overpaid must a consultant be who can knock this down?

I'm curious how someone with crypt in their name would ignore obvious remote access trojan installs as a threat vector?

<comment><USER6> I'm not ignoring anything. I'm simply stating that this is not an effective prevention method. I'm even going to argue that this can potentially _hurt_ whatever fraud system they have in place, as it could create a lot of false- negatives. Once the fraudsters pick up on this they'll change the ports. From then on, this script is useless.

At best, the result of the data points created by this script is going to create a temporary drop in fraud, which can be used by the aforementioned 'consultant' to claim (premature) victory. Give it a month or two, and the fraud numbers are going to go back to their previous levels.

<comment><USER7> Do you deal with fraud issues. My guess is not. "The fraudsters may adapt" is a complaint with almost all fraud fighting approaches - and yet many even older methods STILL have value even if fraudsters could work around them. Many fraudsters are using scripts and tools they don't even know how to modify but that circulate and are used. In person use has geo checks, so easy to avoid by using cards in a local area - but fraud prevention STILL picks up out of billing zip attempts at use.

So you'll be wrong here. And even a 6 month decline in fraud is highly valuable to any of these large scale players.

</comment></comment></comment></comment><comment><USER8> Note that a browser firewall like uBlock Origin with EasyPrivacy (easylist.to) already blocks this: [https://imgur.com/s7efEez.png](https://imgur.com/s7efEez.png)

<comment><USER9> This image doesn't show any local ports trying to be accessed. I'm guessing this endpoint is what gets called after the scan is completed, but context is missing to be certain.

</comment></comment><comment><USER10> Copying the JavaScript to "beautifier(.)io" will show that this script does more than just poet scan. It also uses some low-level fingerprinting techniques using flash and various fonts to determine browser type. It also produces a public and private key.

<comment><USER11> So you are saying this violates GDPR if it is done without user consent?

</comment></comment><comment><USER12> Read about this the other day but I have yet to be able to reproduce port scanning.

<comment><USER13> Me and a coworker found that uBO blocks it. Also from my tests without uBO enabled it didn't scan every time (seemed to only scan when logged out, but that could have been a coincidence)

</comment></comment><comment><USER14> Duplicate from this: [https://news.ycombinator.com/item?id=23246170](https://news.ycombinator.com/item?id=23246170)

Also, the BC article is highly sensationalized coverage with no links to actual source. smh, today's journalists

</comment><comment><USER15> It looks like port 63333 is a common forwarding port for Postgresql. [https://github.com/search?q=port+63333+database&type=Code](https://github.com/search?q=port+63333+database&type=Code)

</comment><comment><USER16> [https://www.cbronline.com/news/halifax-port- scans](https://www.cbronline.com/news/halifax-port-scans)

</comment><comment><USER17> Fair enough, they're doing it to protect their business.

But why should a user have to subject their machine internals to inspection by eBay? And, without their consent.

<comment><USER18> Visiting a website implies consent.

<comment><USER19> What percentage of ebay visitors even know what portscanning is? How can somebody consent to something they aren't aware of, don't anticipate, and certainly don't even understand? Your notion of "consent" is an utter joke.

<comment><USER20> They might not know what port scanning is, but can they agree to "anti-fraud measures?"

<comment><USER19> Maybe they might agree to such anti-fraud measures, but I don't think they have. I don't consider _' ignoring the terms of use buried at the bottom of the page or in small print'_ a legitimate form of indicated consent.

<comment><USER20> Agree with you that simply putting something in the terms of use doesn't necessarily indicate agreement. If they're only doing it to signed in users, then presumably they had the terms put in front of them at some point, but I think your objection is still fair in any case.

To what extent do they need consent to port scan, though? They're not intending to do anything malicious, and in fact (assuming you are the owner of the account that's signed in) they're doing it partly to benefit you. Is there a law against port scanning? Does it affect users in any way?

</comment></comment></comment></comment></comment></comment><comment><USER21> > This makes sense as the programs being scanned for are all Windows remote > access tools.

Wait. VNC is a Windows remote access tool? LOL.

</comment><comment><USER22> Is it possible to configure uMatrix so it either blocks WebRTC completely or asks when a page tries to use it?

<comment> TD-Linux eBay's technique does not use WebRTC at all.</comment></comment>


Yet Another Article on Zippers, in Erlang - <AUTHOR> http://ferd.ca/yet-another-article-on-zippers.html

<comment><USER2> I stopped reading where it says that lists are "O(n) (although they can average n/2.)"</comment>


Ask HN: Interview questions for a better Product Hypothesis? - <AUTHOR>

On Venture Hack's Customer Development presentation[1], Customer Discovery starts out with a product hypothesis.
However, as they say, it's "a capital mistake to theorize without data"; and I believe if the goal is limited to "creating a viable online business", and we have a target market set -say, "professionals doing professional stuff"[2]- we can do better.
By asking well-phrased, well-framed questions to a small (but statistically significant) partition of the target market, we can pull out product hypothesizes right from the market.
So, my question is: which questions to ask, if our goal is to limit the answers to have good scaling characteristics?
Why you should care: finding an answer to this problem would contribute to massively de-risking startup creation.
[1] http://www.slideshare.net/venturehacks/customer-development-4-customer-discovery-part-1
[2] http://www.kalzumeus.com/2010/03/20/running-a-software-business-on-5-hours-a-week/ <comment><USER2> From linked slides it seems, that at the beginning is listening. And for that the best questions are:

1\. What is X all about? 2\. What I need to know to really understand X?

It also seems, that Customer Development is not about finding the perfect product hypothesis in one shot, on the contrary - the initial hypothesis is just the starting point, things you learn on the way is what matters. Just like with dancing, it will be better after some dancing, no need for over- thinking it or looking for a perfect steps. It's more about expressing yourself.

That said optimization and automation, a heuristic or even better an algorithm, that will reliably and repeatably take some customers and output brilliant business ideas would be a nice thing to have. But it won't reduce startup risk, not massively for sure, because 'executing' alone is more risky than 'executing on a wrong idea'.

Going back to questions.

3\. What do you want?

Because sometimes the problems in given industry are very well defined and understood. And even the cliché answer "a faster horse" isn't really useless, you just have to go little further asking...

4\. Why?

... a couple of times. Next an obvious candidates will be a "profiling questions":

5\. Where are time and money (and resources, attention, pain, fear...) in X?

Now, form a different angle:

6\. What in X is worth spending money on? And what is not (because of utility/price ratio)?

I have a problem with question that will filter out problems that won't make a scalable startup, maybe because scalability is property of a solution not of a problem?

It's far from complete, but above should already give some hints about what can be done.

Learn more "startup patterns" to spot more potential chances for business.

</comment><comment><USER3> In "Four Steps to the Epiphany" Steve Blank defines an earlyvangelist as "someone who has spent money to develop a solution to a problem but is still unhappy with the result." I would use this to model you to identify which professionals to have a further conversation with: "what problem(s) have spent time or money on in the last year to reduce or eliminate where you are still unhappy with your current solution?"

I would not worry about the "scaling characteristics" as much initially as finding a group of professionals who share the problem and would reference each other's decision to use your product. This does not mean that they have to know each other but that an endorsement, case study, or testimonial that describes their background and how they benefited would influence a buy decision. All innovations start in a niche, some go scale beyond that, but none scale without starting in a niche.

For an elaboration on sources of innovation see [http://www.skmurphy.com/blog/2008/02/15/paul-grahams-six- pri...](http://www.skmurphy.com/blog/2008/02/15/paul-grahams-six-principles- for-making-new-things/) which includes checklists from Paul Graham, Peter Drucker, Gary Hamel, and Bob Bemer the inventor of ASCII.

</comment><comment><USER4> At the earliest stages, you should just be identifying the problem. Interview general folks in your industry and ask, 'would you like a simpler XXX'. 'what is the most painful ZZZ'. 'what would get you to try a new service'.

From that small set, draw up your idea and re-interview those folks. if they like it, you should present the same drawings to a wider scope and see if it still has gravity.

The next step is to test the market and publish your solution through adsense . I'm unaware of another method to test an idea as well as adsense. it would be great to hear some other ways of testing an audience before building.

<comment><AUTHOR> You misunderstood the question completely. simpler XXX, and painful ZZZ _presumes_ an existing problem hypothesis. However, past data points of both my own, and most startupers clearly shows, that our problem hypothesises generally suck at conceptual level.

This is what I mean by de-risking: I want to take out this unnecessary risk of blind guessing, and delegate hypothesis discovery to those _with the data_.

<comment><USER5> I didn't understand your question either. It feels very...jargon-heavy.

It sounds like your question is: if you know who you want to sell to, can you just ask them what they want rather than polling them for feedback on different ideas? Honestly, I think people often don't know what they want because they don't understand which things can be made simpler. That's why someone with a different perspective (hackers) can learn about a market, have some new insight, and come up with something disruptive.

<comment><USER2> > learn about a market, have some new insight, and come up with something > disruptive

This, how to this without the magic?

What are the (universal) questions you would ask to potential customers to come up with a problem worth solving?

</comment></comment></comment></comment><comment><AUTHOR> This question constrains the possibility space by 2 factors:

-It has to tap into the "common headaches" of the target market (say, barbers, teachers, or small restaurant owners), so scalability is given

-It constrains the headaches to those, that are mallable to software solutions

Some early candidates:

"What aching problems do barbers have, that would be a computer's job?"

"In a futuristic society, what things would you except computers to do, that you're currently handling manually -but want to get rid of?"</comment>


Why Can't Virginia Explain How Jamycheal Mitchell Starved to Death in Jail? - <AUTHOR> http://www.slate.com/articles/news_and_politics/jurisprudence/2016/05/what_happened_to_jamycheal_mitchell.html <comment><USER2> Crazy people are hard to deal with. The mental health profession doesn't really care why people are in its care, it just treats the symptoms with FDA- approved drugs. Because the patients never get better, there is an ever- expanding need for beds at treatment facilities.

Robert Whitaker's _Anatomy of an Epidemic_ [1] investigates why "the number of disabled mentally ill in the United States _tripled_ over the past two decades," in spite of all the new drugs that are now available.

[1] [http://www.madinamerica.com/product/62043/](http://www.madinamerica.com/product/62043/)

My girlfriend says she'd rather go to jail, than to another mental hospital. She's started to recover from her "mental health hell". With the help of the firefighters, she was able to switch to using the anti-anxiety drug "as needed" \- the professionals at her 5th mental hospital stay had forced her to get addicted to this drug. She was good for about 2 weeks, then resumed drinking and self-medicating for her depression.

The 6th mental hospital didn't care that she'd been drinking, they just assumed that their patient was delusional because she'd stopped taking her anti-psychotic. After a week at their facility she was still delusional, in spite of their injections. I was surprised they released her - I was certain she was going to the state mental hospital. _(Now that I think about it, after reading this article, I bet there wasn 't a bed available...)_

She called me the day after she'd been released to a "friend's" apartment (I was staying with family, 2 hours away)... Could I pick her up? Her friend had tricked her into buying bus tickets to California; she'd ditched him in Las Vegas. Five hours later I found her at the 7-11 she said she'd be at.

By this point I'd obtained more of the drug that she actually needed (very similar to what the firefighters had provided), and she started to calm down. "Feeling safe" is very important for optimizing a person's mental health.

When she missed her appointment the next day, they issued an arrest warrant. The next Monday she checked in to my county's local mental health system. A week after being released, the psychiatric nurse wanted to keep her on the anti-psychotic that the previous places had forced her to take, but someone neglected to pre-authorize the injection.

After another two weeks had passed, they started calling to have her come in for her shot, which she avoided. We talked to her case manager, and he talked to the psychiatry team. When she went to her medication-review appointment the following week, the psychiatric nurse didn't see any need to re-start the anti-psychotics, as the patient was NOT psychotic in spite of being off the drug for a month, and agreed to the anti-depressant that my girlfriend wanted all along. (This is not to imply that I think the anti-depressant is going to help, I just acknowledge that the patient's complaints are actually being listened to.)

Her medical cannabis card should arrive in a few weeks... I am optimistic that this "herb" will be the right "crutch" to get her to be much more stable.

edit: typo & clarifications</comment>


Show HN: getAmplify - Ice breaker for user engagement - <AUTHOR> https://getamplify.com People want to connect with real people and not brands. Brands are not people but it's people who make brands. So why not use a real person from your company to represent your brand.<p>Amplify Connect helps you present a human face to your users. This encourages users to engage with you. It is an ice breaker between you and your site visitors. <comment><USER2> Hmm, I looked through the site and I still don't know what this is. I'm guessing it's a lightweight alternative to intercom.io. Try adding a live demo or video for viewers to understand your product better. Also, the sign up button's display is messed up and the about us page is completely broken.</comment>


Show HN: Datafork classic Macintosh typefaces (with FontForge source) - <AUTHOR> https://github.com/JohnDDuncanIII/ClassicMacintoshFonts <comment><AUTHOR> I posted this in a response the other day, but I thought the greater HN community would probably be interested as well. Only files that I can think of that are missing are: the Apple Casual bitmap from the Newton (I have contacted splorp about this) and Podium Sans/Univers TTFs (branding)</comment>


The rise of IBM's supercomputing platform Watson - <AUTHOR> http://meshedsociety.com/the-rise-of-ibms-supercomputing-platform-watson/

<comment><USER2> Watson is a _very_ nice tech, a strong example of how machine intelligence extends human capacity. If a computer is a bicycle for the mind, Watson is a moon rocket.</comment>


New Quad Core iMacs - <AUTHOR> http://www.apple.com/imac/ <comment><USER2> See <http://news.ycombinator.com/item?id=2509723> for discussion</comment>


GNU GCC does not round floating-point divisions to the nearest value - <AUTHOR> https://lemire.me/blog/2020/06/26/gcc-not-nearest/ <comment><USER2> An example where this matters -- a new Mario 64 trick on the Virtual Console version because summing round-towards-zero numbers over a sine wave cycle produces a small delta which builds up over a couple of days to make a jump possible

[https://www.kotaku.com.au/2018/06/the-mario-64-trick-that- ta...](https://www.kotaku.com.au/2018/06/the-mario-64-trick-that-takes-three- days-to-complete/)

<comment><USER3> For anyone else interested in similar tricks, here is an in-depth video where someone talks about getting a star with half a button press. It starts out straightforward enough, but eventually gets really interesting when they start talking about parallell worlds that you can only access by abusing bugs to reach unrealistic speeds.

[https://www.youtube.com/watch?v=kpk2tdsPh0A&t=77s](https://www.youtube.com/watch?v=kpk2tdsPh0A&t=77s)

<comment><USER4> Best followed by this video, which made me laugh my ass off for several minutes: [https://www.youtube.com/watch?v=hSa- pwML4z4](https://www.youtube.com/watch?v=hSa-pwML4z4)

(I grew up watching SpongeBob, if that matters)

<comment><USER5> That was excellent. If I may suggest a followup: [https://youtu.be/Pyn3N55elS4](https://youtu.be/Pyn3N55elS4)

</comment></comment></comment></comment><comment><USER6> I believe the issue is that some of this ends up evaluated at compile-time, and the compiler really has no idea how to do rounding correctly at that point. When implementing floating point tests for an x86 emulator, we had to create a macro that would ensure that the calculation was done at runtime rather than at compile time for this exact reason: [https://github.com/ish- app/ish/blob/18176b6931d69bdabe48f137...](https://github.com/ish- app/ish/blob/18176b6931d69bdabe48f137e48d8e8118c22122/emu/float80-test.c#L11). If anyone knows how to control floating point rounding in C reliably, I'd be interesting in hearing it :)

<comment><USER7> > If anyone knows how to control floating point rounding in C reliably, I'd be > interesting in hearing it

I skimmed over that code and it seems that hack is required because a) you're not happy with what the compiler does with a double b) insisting on using a "double" type.

It's easy to get your own semantics for numbers in C, it's not easy to do so while insisting on using C's own types whose behavior are contrary to what you want.

If you want your own floating point semantics why not make a struct with a significand & base and pass that around? Something like that is how established numbers-in-C-without-native-C-semantics libraries do it, e.g. GMP.

</comment></comment><comment><USER8> If you add '-ffast-math' to the compiler parameters in his godbolt link you get the 'right' answer. Doing that means the division is done with the 'divsd' instruction, which clang uses even without the 'fast-math' flag.

That doesn't mean it's necessarily the right thing to do though.

Clang can be made generate the same code as the 'broken' gcc output by declaring the variables as 'long double' instead of 'double'. So I think this is where the issue lies?

Edit: godbolt link requiring large monitor: [https://godbolt.org/z/tFiZwW](https://godbolt.org/z/tFiZwW)

<comment><USER6> -ffast-math should rebrand itself to -ffast-and-more-correct-math ;)

<comment><USER9> It's normally not more correct.

<comment> all-fakes I thought fast-math meant (among other things) that the compiler could algebraically simplify things using some rules for real numbers that don't apply to 32-/64-bit floating point numbers. I'd expect that reducing the number of operations would more often than not reduce the error due to rounding, which is what most people would want when they talk about "correctness".

Which step in this (very naive) argument is wrong?

<comment><USER10> Stuff like Kahan summation breaks horribly with -ffast-math, because if you assume that sum is associative the error term, which is ((s+x)-s)-x, simplifies to zero.

[https://en.m.wikipedia.org/wiki/Kahan_summation_algorithm](https://en.m.wikipedia.org/wiki/Kahan_summation_algorithm)

<comment><USER11> That's where you dust off volatile.

<comment><USER12> Sadly true. That's the only portable way I found to implement something akind to a Kahan sum so that no compiler / flag would destroy it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> As I understand it, the IEEE floating point standards do not require exact rounding for binary to decimal conversions. See _What Every Computer Scientist Should Know About Floating-Point Arithmetic_ [https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)

The behavior appears to be consistent with the standard. Keep in mind that GCC needs to provide the same result irrespective of the architecture it runs on and one reason to use GCC for floating point is to take advantage of dedicated hardware. And the reason to use floating point is speed not precision (at least when using decimal floating point). If precision is critical then arbitrary precision or fixed point is the way to go. Normally it isn't that critical.

<comment><USER14> Look for the heading, "The IEEE Standard" in "What Every Computer Scientist Should Know About Floating-Point Arithmetic," then scroll down to the subheading "Operations." That section begins, "The IEEE standard requires that the result of addition, subtraction, multiplication and division be exactly rounded. That is, the result must be computed exactly and then rounded to the nearest floating-point number (using round to even)."

A few paragraphs later, it adds, "There is not complete agreement on what operations a floating-point standard should cover. In addition to the basic operations +, -, × and /, the IEEE standard also specifies that square root, remainder, and conversion between integer and floating-point be correctly rounded. It also requires that conversion between internal formats and decimal be correctly rounded (except for very large numbers)."

I will admit that I worked as a programmer for several years without knowing that. I learned it from a former physics professor who has now moved on to become a quant with a hedge fund. He usually didn't worry much about it, but when he needed to be sure a particular calculation was as accurate as possible, he'd start counting individual operations and stay away from particular function calls.

<comment><USER13> Yes, you are correct. Thanks. This stuff is hard for me.

Reading down thread, I see that the behavior might be related to x87 since the build script references i386...which makes IEEE 754 conformance moot. The methods of achieving conformance when targeting i386 are described in the GCC documentation.

</comment></comment></comment><comment><USER15> x87 is crazy. Especially since you can't easily know when something is truncated from 80 bits to 64. Add a parameter to a function and an unrelated calculation behaves differently because it now ran out of 80bit registers. Congratulations, you now have a spurious test failure you will spend weeks trying to find.

The only way of doing FP on x86 and keeping your sanity is by making sure you use 32/64 bit floats 100% of the time. That is: use SSE registers and never the 80-bit x87 arithmetic.

I thought compilers for 64 bit programs these days did exactly this. I know the .NET Jit does for example.

<comment><USER16> The article is about 32 bit gcc. 64 bit gcc defaults to SSE, although you can force x87 if you want to. (although... maybe don't do that)

</comment></comment><comment><USER17> Perhaps the title should mention that this is 32-bit x86, which is rather obsolete. This should work okay on x86_64.

<comment><USER18> Are you sure? The FPU instruction set is the same.

<comment><USER19> The platform ABI can differ on the same cpu.

I originally had the wrong answer here, but I'm including below for historical purposes and embarrassment. Re-reading on my laptop meant I didn't misread/read-the-expected?

Basically by default when compiling for IA32 gcc assumes that there is no SSE unit, and so must use the x87 fpu.

Alas the x87 unit doesn't have either 32 or 64 bit ieee floating point types, so the calculation at runtime must be rounded to float/double at the end of the computation. That results in a double round that is incorrect.

Minor additional comment - x87's reduced precision modes (that reduce mantissa precision to ieee754-32/64) don't reduce the exponent size so it's conceivable you could get multiple-rounding derived errors even then. But no one would be toggling x87 state like that anyway, so theoretically not something that would matter in most cases.

 __Old incorrect answer:

On ia32 long double is the x87 80bit ieee754 numeric type.

On x86_64 on windows, and maybe Linux, long double is just a 64bit ieee float.

So my guess is that GCC computes constant evaluation of floating point expressions in "long double" for maximum precision, and then _rounds_ to the required precision at the end. This is not valid going from 64->32 bit floats and you could probably induce this bug if you tried hard enough.

Anyway it is not sound to round twice in any numeric operation, and by doing the calculation at one precision and then _rounding_ that to the required precision that is what gcc is doing.

This is a bug in GCC, floating point is well defined, there isn't randomness to it, and they've introduced additional rounding that is not valid.

<comment><USER10> > Anyway it is not sound to round twice in any numeric operation, and by doing > the calculation at one precision and then rounding that to the required > precision that is what gcc is doing. > > This is a bug in GCC, floating > point is well defined, there isn't randomness to it, and they've introduced > additional rounding that is not valid.

Except the C standard has a way to communicate how the extra rounding is being introduced, and it's not random (for C, not C++).

There is simply no way around this issue with the x87 instruction set, GCC (again only for C only, not C++) implements FLT_EVAL_METHOD==2 which is the most sensible that can be implemented with decent performance and without breaking 80-bit long double.

If you are sure you don't need long doubles, use -mpc64.

<comment><USER19> as my edit said the problem was gcc was confined to using x87 as the compile args required x87 - the older version of the comment incorrectly thought it was the optimizer going wrong, rather than runtime.

If you are constrained to x87 your only option is multiple roundings which is bad. Ideally you'd just keep processing in the x87 stack as long as possible, but that would result in a different version of "incorrect" results.

Honestly if you're a compiler required to use x87 with non-80bit floating point I'm not sure how you can do the right thing :-/

I don't know what gcc has but llvm has a full software floating point implementation to handle cross compiling so it can match native arithmetic.

<comment><USER10> Yes, FLT_EVAL_METHOD 2 is an extension of "keep values on the stack as much as possible" that also requires the compiler to spill intermediate results as long doubles. Apparently it also doesn't cover constant folding, but knowing who implemented it in GCC (Joseph Myers) he's extremely thorough and I have no doubt it's allowed by the standard.

That's the best they can do.

<comment><USER19> yeah, once you are restricted to performing (at runtime) computation at a precision that does not match the specified storage precision, the compiler is kind of screwed :-/

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> This seems like a property of the Intel 8087 math coprocessor and its distant descendants found in x86 chips, not anything to do with gcc?

<comment><USER21> But then why does python and JavaScript on the same machines get it right?

<comment><USER16> Because they're compiled to use SSE instructions instead of x87 FPU instructions.

If you are still writing 32 bit x86 C code, it's probably some embedded or legacy CPU, and it's wrong to assume SSE instructions are available. So GCC correctly defaults to using FPU instructions instead of SSE instructions on 32 bit x86.

Javascript and python will basically never be run in embedded environments, and their legacy environments probably aren't _that_ legacy that SSE instructions aren't available. So it's reasonable to default to SSE.

<comment><USER22> Plus JavaScript is interpreted and JITed, it can detect and decide at runtime whether to use SSE or x87.

</comment></comment></comment></comment><comment><USER23> Learning C recently, I ran into confusion around FLT_EVAL_METHOD as my dirty (not recommended) trick for getting machine epsilon didn't work (7.0/3.0 - 4.0/3.0 - 1.0). With strict IEEE 754 floating points it works fine (Python, Julia, Go all work as expected). But gcc, with c11 flags at least, performed the computation using the 80 bit upsampling mentioned in this post. Caused some head-scratching initially.

Edit: Also, curiously, things worked as expected for me using -std=gnu11. This was a fairly old version of GCC though, things might have changed.

</comment><comment><USER24> The worst of this is that internal 80 bit x87 registers are truncated to 64 bit when written to memory. You have essentially no control over when this happens from the language level. It meant that floating point code was all rather undefined and you got different results on different compilers. As someone who has had to write multi platform numerical code I'm very thankful it's gone from AMD64.

</comment><comment><USER25> If you're interested in the accuracy of floating point operations, I recommend taking a look at the khronos openCL[1], it's not as clear cut as you would think. I think there are good reasons not to expect floating point ot be bit accurate.

[1]:[https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenC...](https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_C.html#relative- error-as-ulps)

</comment><comment><USER26> Clang with default settings seems to get it right:

[https://imgur.com/a/d3LBlLK](https://imgur.com/a/d3LBlLK)

<comment><USER10> It may gets it right for this particular test case, but it will get others wrong. It's impossible to say "it gets it right" from a single testcase or three, you have to look at the compiler innards.

See [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323) for the gory details; clang works the same as GCC's C++ frontend and the same that GCC <4.5 used to behave for C.

</comment></comment><comment><USER27> DIY rounding function is given here;

In unbiased rounding, .5 rounds to even, rather than always up, so 1.5 rounds to 2 but 4.5 rounds to 4

[https://www.gnu.org/software/gawk/manual/html_node/Round- Fun...](https://www.gnu.org/software/gawk/manual/html_node/Round- Function.html)

</comment><comment><USER28> So the complaint is that this loses half a bit of precision on average? Is that a lot?

<comment><USER29> If you lose half a bit on every operation and do multiple operations, that could be pretty bad. If it's half a bit at the end of a long chain of operations, that's tolerable and not worse than the precision specified by the docs for some execution environments (GPU shaders, for example)

It also matters a lot whether the error is predictable and possible to compensate for.

</comment></comment><comment><USER30> Back in the 90's I was working on some Ada code with some problems that were traced to conversion of strings to floating point at run time differing from conversion at compile time.

</comment><comment><USER31> I haven't seen anyone mentioning it, but I wonder if -ffloat-store fixes this?

</comment><comment><USER32> rust (default settings, amd64) gets 0.501782303180000055

<comment><USER33> Does Rust still uses LLVM? If so, I'd tend to expect a result similar to Clang.

</comment></comment><comment><USER34> The thread comments didn't dissapoint:

> someone defended gcc

> someone attacked it

> someone who just started learning C or C++ made a comment

> someone mentioned clang did it right

> someone mentioned Rust

<comment><USER34> and I got downvoted for not contributing meaningfully to the topic! The set is full</comment></comment>


Advantages of Tcl over Lisp - <AUTHOR> http://wiki.tcl.tk/13410 <comment><USER3> Tcl does not get a lot of love. I think some of it is due to the fact that it is not lisp, it does not have closures, and perhaps the association with the famous Tcl wars. I have always found it a lively little language to code quick and dirty things. Dirty Tcl, isn't particularly dirty (well, it's not particularly quick either, but better than what I expected it to be) and pretty easy to embed. Upvar is sort of nonstandard, but one can get by with it.

It is one of the very few interpreted languages that had a nice threading support since ages. But for me the best part has been the community and wiki.tcl.tk. I dont think it is very common in other communities that you get responses in real time. To me Tcl was (I know I will be violently killed for this) a cleaner non-cowboy Perl (as well as Lua of the 90s).

If it interests HN readers, Jim, an implementation of Tcl, has closures. <http://wiki.tcl.tk/13840>

</comment><comment><USER4> _many thinks[sic] like HTML, XML, Networking Protocols, are about strings more than they are about lists._

HTML and XML structured as trees made from nested lists. Manipulating them as strings is difficult and error-prone. Dealing with them as lists is much cleaner in most cases, even when your language isn't Lisp.

</comment><comment><USER5> In the industry I work in, Tcl is used extensively as the application language, and it works out well enough in practise (funnily enough, one of the larger players in this space use a dialect of Scheme.)

I guess the greatest advantage Tcl has is of being embedded deep into peoples workflows (changing which tends to be a huge investment both in terms of money, and what is more valuable, time) so it's very difficult to be dislodged from there. Also, once an EE manages to grok "everything is a string", there's absolutely nothing to stop him from writing horrible code :)

As for advantages, meh. The only one that really stands out for me is this one:

> There aren't a big number of implementations of Tcl, and there is a bigger > default library.

<comment><USER6> What is the industry you work in?

</comment></comment><comment><USER7> Tcl is brainlessly easy to extend in C, too. An enjoyable language all around.

</comment><comment><USER8> Lots of Maya (Autodesk property now) users are in fact TCL users. Maya's MEL script is very close to TCL.

I've seen it also used in Konami's Metal Gear Solid for scripting the levels, and in one game studio for the sound tool and processing.

Also Tk is used a lot, and through many languages.

</comment><comment><USER9> My favorite cool feature of Tcl: A return statement that can return by arbitrary number of levels instead of 1. <http://www.tcl.tk/man/tcl8.5/TclCmd/return.htm#M15>

I found this very useful, for example when writing a webapp that expected a session ID in a cookie. When not found, it was supposed to redirect to an error page.

In Tcl:

      proc handler {} {
        load_session
        # do stuff
      }

load_session will use two-level return to redirect to the error page.

In python etc:

      def handler:
        if load_session() == error:
          return
        # do stuff

Minor, yes, but we're talking language nerdery. :)

<comment><USER10> Continuations handle this more cleanly. Heck, you can return to an arbitrary point 1 or more functions back on the stack _in C_ , via setjmp/longjmp, when you really need to.

<comment><USER9> Can you explain how continuations apply here. I don't really have a good idea about that.

Wrt setjmp/longjmp, I think the key differences are the lack of a 'setjmp' and that you don't have to pass in the setjmp buffer down the calls. If you ignore those aspects and focus only the barest essence, yes they're the same (just like nitrogen and a cake are the same because they're both made of protons, neutrons, and electrons).

<comment><USER10> Think of a first class continuation as a heap-allocated setjmp buffer - <USER2> than unwinding the stack, it changes the stack to a saved stack (which, since it isn't unwound, can be returned to multiple times).

Continuations and longjmp can't return an arbitrary number of levels up the call stack without placing some sort of marker there first, but IMHO that's a good thing. Continuations are a "structured" version of that Tcl return construct. While I haven't done much with Tcl, is it typically used to implement other language constructs with more specific semantics, or is it typically used directly?

<comment><USER9> I've never seen it used (except by myself once). :) Because the control flow becomes hard to understand, and the called function becomes extremely context sensitive. But I think it has its uses within libraries' private functions or in code which can afford to be blub-incompatible.

</comment></comment></comment></comment></comment><comment><USER11> Educate me, because I think I've found an outright error in the linked page:

> In Tcl serialization just happens for many types because almost everything > has a string representation. You can write a Tcl list in a file just with: > puts $fd $list. This is not possible in Lisp, where you need to perform > serialization.

This is, from what I can see, wrong: In Lisp, you have the write function, which can 'serialize' arbitrarily complex data structures in a form acceptable to the read function. That's pretty much it, unless you're trying to do something odd like applying write to a compiled function or some other implementation-specific bizarre internal data structure that doesn't have a write-able representation.

Therefore, the linked page seems to be missing or mis-stating a core feature of Lisp. Am I wrong about this? Does the Tcl world have something significantly different in this regard?

<comment><USER8> Can you serialize the hash-table?

<comment><USER11> Yes, you can:

         > (write (make-hash-table :initial-contents '((a . b) (c . d))))
        #S(HASH-TABLE :TEST FASTHASH-EQL (C . D) (A . B))

If you wrote the output to a file and used read to input that file, you'd get precisely the same hash table back into your program.

(That's Common Lisp. Scheme might be different.)

<comment><USER12> Does hash tables stores only values or they can store other data structures? What happen when they store references to other data structures?

In Tcl, list and dict _always_ are values so their string representation is already a serialization.</comment></comment></comment></comment>


Soli Radar-Based Perception and Interaction in Pixel 4 - <AUTHOR> https://ai.googleblog.com/2020/03/soli-radar-based-perception-and.html <comment><USER2> The tradeoff of putting a giant bezel on top of the phone in order to support being able to take a tiny number of actions in a few apps by waving your hands instead of touching your phone was... Probably not the right tradeoff. How often do you use your phone without, y'know, also holding it in your hand, and thus being able to touch it? And if they hadn't shipped Soli in the 4, I wonder if they would've saved enough manufacturing $$ to put an ultrawide camera in to compete with the iPhone 11...

From the current leaks it sounds like Soli isn't going to make it into the Pixel 4a; I'm curious whether it makes it into the 5 (and TBH hope it doesn't, unless they can figure out how to not make it take up a huge amount of bezel space).

Soli makes a lot of sense for the Google/Nest Home line of products, where you rarely are close enough to touch them. But for your phone? I just don't get it, and it seems like few people find it useful. I'm pretty surprised it shipped and would be very curious to learn how that happened, since it seems to have negatively impacted the product pretty heavily.

<comment><USER3> The Pixel 4a is a budget pixel. Of course it's not going to get Solo as for the Pixel 5...that remains to be seen since this is Google

<comment><USER2> Yeah, it's just interesting that in many ways it seems like the "budget Pixel" will actually be superior to the non-budget version: a bezel-less design (at least, according to many of the current leaks) because they aren't shipping the generally-pointless Soli hardware, and likely much improved battery life because they aren't shipping a 90hz screen (that the Pixel 4 couldn't handle anyway and has had to keep software-locked to 60hz half the time just to make it through the day on a single charge). The outdated, lopsided design and the anemic battery life were two of the most-disliked features in critic reviews of the 4; interesting that the 4a will basically be a better version of the 4, with the exception of missing the telephoto camera and (probably) lack of waterproofing.

Responding to critical feedback is a good and sensible thing to do. But ideally you would be able to get feedback on large issues internally, without needing the market to reject your product (Pixel 4 sales have been reported to be quite low): Soli seems so clearly useless, and caused such obvious product design tradeoffs, that I'm curious what led to it shipping in the first place. Was it an exec who was excited about Soli pushing it through? Was there a design/engineering communication breakdown? Would be very interesting to be a fly on the wall in the retro.

<comment><USER4> Maybe I'm an outlier here but I love my Pixel 4! Battery life isn't great, but the 90Hz screen is amazing and I definitely wouldn't go back to 60Hz if you paid me.

Aside from that, the Pixel 3a doesn't have wireless charging, so if that also applies to the 4a it's a total deal-breaker for me. And I really enjoy the performance of the Snapdragon 855 - especially with 90Hz forced at all times and animations tweaked to run at 2x speed, it's extremely noticeable how fast this phone is.

Not saying the Pixel 4a won't be a good phone, but the 4 is definitely better for premium features imo.

</comment></comment></comment></comment><comment><USER5> I have a Pixel 4, so far this feature has been near useless. At times it's nice to reach towards my phone and wake up the always-on display to see what notifications are present but that's about it. Song changing, etc feels gimmicky and impractical.

Overall, it feels like this is a tech demo lacking a killer app.

<comment><USER6> Can confirm, despite the recent updates, the gestures are gimmicky and sometimes activate when not needed e.g song skips to the next one when reaching to pick up the phone.

The only truly useful thing is waking up the phone on detecting motion nearby, which could probably be done with a much simpler sensor.

</comment></comment><comment><USER7> Is there any way to access the "raw" sensor data from the Soli device in a Pixel 4, even with root? As far as I can tell, the best an Android developer can access is some pre-calculated gestures. I'd like to play with using this for other applications, not just snoozing my alarm more easily.

<comment><USER8> I don't think there is.

It would be a cool thing to play around with, and I wish they would make it available. The problem is the raw data isn't likely to be very useful without using ML to filter out false positives for any gestures you want to implement.

</comment></comment><comment><USER9> Motion sense could be used in a lot of applications.

I'd like to use an ATM without touching anything.

The coronavirus scare should open up markets.

<comment><USER10> Soli is supposedly very accurate for minute movements and is very small and low-powered allowing it to be embedded in a phone, but this kind of tech has existed for a while. The Leap Motion comes in a really small, embeddable package and works over USB and can track hand movements quite accurately. It's been around for 10 years and was recently acquired by a haptics company. It's never managed to go mainstream or find any real applications outside of niche gaming.

<comment><USER11> > The Leap Motion comes in a really small, embeddable package and works over > USB and can track hand movements quite accurately.

I've never tried one, but everyone I know that did said it was so bad they stopped using it after maybe 10 minutes of frustration.

<comment><USER10> "So bad" depends on what they were trying to do. If they were trying to observe skeletal tracking of their fingers, then they should be pretty happy. If they were trying to use it in place of a mouse or something, then it probably sucked because no one has solved the UX for one of these things which is my point. The Soli is even better than the Leap at tracking fingers, but exactly what good is that?

</comment></comment></comment></comment><comment><USER12> Cool but completely useless on my phone.

<comment><USER13> I think that's the point. They want you to buy theirs.

</comment></comment><comment><USER14> Since I first saw the Soli demo video some years ago, I have been waiting to buy a small physical hackable version of the product.

Adding it to a phone seems like an unintelligent move -- maybe they should release a smart watch (if they know how)?

Guess I will have to wait at least a few years more.

</comment><comment><USER15> What is the point of putting motion sense in a device that spends its entire life either in your hand or within arm's reach? They stuck a kinect in a phone but won't give us a damn headphone jack?

<comment><USER16> > Motion Sense additionally detects when you're near your phone and when you > reach for it, allowing your Pixel to be more helpful by anticipating your > actions, such as by priming the camera to provide a seamless face unlock > experience, politely lowering the volume of a ringing alarm as you reach to > dismiss it, or turning off the display to save power when you're no longer > near the device.

<comment><USER15> There is no way in hell it has the kind of viewing angle to pick up my hand more than a fraction of a second before I touch the phone. Not that it matters, since the camera and the accelerometer can do all those things already.

</comment></comment></comment><comment><USER17> I am reminded of the radio in the book "Hitchhiker's Guide to the Galaxy", where things had gotten to the point that you merely had to wave at it to change the channel.

</comment><comment><USER18> Could this be used as an input method in games or music apps?

Touchscreens are such crap to use.

</comment><comment><USER19> I'd much rather have a device with a keyboard..

<comment><USER20> I wish the Palm Pre would have taken off. Loved the keyboard layout; it was extremely well thought out</comment></comment>


We must preserve Bitcoin's principles of privacy and freedom of financial speech - <AUTHOR> https://darkwallet.unsystem.net/

<comment><AUTHOR> > _Many prominent Bitcoin developers are actively in collusion with members of > law enforcement and seeking approval from government legislators. We believe > this is not in Bitcoin user 's self interest, and instead serves wealthy > business interests that make up the self-titled Bitcoin Foundation._

I actually agree with this. I'm a little bit concerned with the role of the Bitcoin Foundation. Do we really need such a group to control the direction of Bitcoin?</comment>