What are your early financial tips? Should I start a 401K - <AUTHOR>

An ADP Retirement service broker dealer connected to an office I'm interning at came to talk to the employees that have been here for a while about a simple IRA which had been set up for them. Are there any financial tips you can give, both short-term and long-term, for a college student/graduate? <comment><USER3> I have surpassed a lot of my peers who have made significantly more than me in net worth & possibly net happiness. Here's how:

1) Maximize your employee 401K benefits - This has been stated before but 401k matching is tax sheltered and more importantly, is free money from your employeer

2) Treat your credit card like a debit card - Never carry a balance, never use it to buy things you don't have savings to buy.

3) Carry cash assets in high yield savings accounts - While interest rates currently, suck, there is no reason to let your money sit in a non-interest bearing account.

4) Avoid paying tax on income as much as possible - There are a lot of financial instruments (401K, IRA) that allow you to defer tax. If you are in a state with significant tax rates (i.e. California) deferring tax can hugely valuable.

5) Learn how to financially model - This is probably my most valuable tip. You should understand the implications of every significant expenditure you make. Since I love modeling, I go a bit overboard on this but it really makes your decisions a lot more clearer. Some typical decisions that you should be able to model with a DCF: competing job offers, buying vs. renting, going to grad school, etc.

6) Financially model & think heavily before going to graduate school. As you hit the mid to late 20s, you may feel a lot of pressure to go grad school due to changing careers, getting pedigree, peer pressure, etc. Higher education in the US is extremely expensive; make sure you model the costs (including the lost opportunity cost of salary) before cutting a check. I've had a lot of colleagues waste money on MBAs that were largely un-necessary. There are also a lot of ways to switch careers without another degree (I did it myself 3 times without any new degree).

7) If you are open to working outside of the US, consider working for a few years in countries like Dubai where you can legally reduce your tax payments. A reduction in your taxes can easily double or triple your take home salary (even if your salary stays the same or even reduces). This benefit erodes as your salary increases so consider this in early stages of your career (it also becomes harder to move internationally as you grow older).

8)Negotiate every salary offer, ideally with competing offers, even if the offer is your dream job. Most people stop looking for jobs when they are close to the offer. What do I do? I accelerate my interview process and reach out to competitors to see if I can get competing offers before I have to decide on the offer. No good company will fault you for negotiating your offer and negotiation almost always improves your offer significantly.

9) When comparing & contrasting offers in different cities consider your "savings income": i.e. pay - taxes - living expenses. Some people instead rely on cost of living which results in incorrect decisions (a 50% increase in cost of living doesn't mean you need 50% higher in salary to net the same money).

10) Choose credit cards that give you the highest cashback (usually). This isn't always the right choice (i.e. if you fly a lot mile cards may be better) but in most cases 2% cashback card will beat out any card and cash is conveniently liquid (unlike miles). Also don't open more than a few cards as that will just open you to risk, abuse, and a lower credit score. Do NOT open a credit card just to get a free t-shirt or $40 off a purchase. My rule of thumb is that a credit card should return at least $300 annually (not just the first year).

11) Try to allocate expenditure on your "happiness ROI". I am extremely frugal on things that do not improve my happiness for the long term and relatively extravagant on things that do.

Things worth splurging money on [for me]: Experiences & travel, reducing commute time, fitness activities, books, a comfortable bed Things probably not worth splurging on [for me]: Fancy & shiny new car, a bigger apartment/house, expensive new furniture, expensive non-work clothes

As you get older you will feel a lot of peer pressure to buy the things your peers are buying - don't cave in and focus your discretionary spend on things that make you happy.

12) Keep your cost of living relatively stable when your income spikes. You are likely to experience a income spike sometime in your career. Resist the urge to scale up your spending immediately - unless you were unhappy before (and purchases make you happy), what's the point? You will thank yourself when you experience the other common salary spike across most careers: lay-offs.

13) Build 6 months of runaway as soon as possible. Ideally this should happen within few years of graduating (assuming no loans). Extend the runaway as your career progresses and esp. if you want to be become an entrepreneur.

14) Depreciation is your friend - consider buying used when it makes sense. Many items lose significant value within a few months even though they have the relatively same value to you. Purchasing used makes a lot of sense in many purchase decisions (books, cars, furniture) but also makes no sense in other decisions (mattresses, bike helmets, swimsuits, car seats).

15) Advanced tip - Make sure you read the _Intelligent Investor_. Chances are you've been brainwashed with way too much EMH theory in undergrad which has convinced you that you can't pick undervalued stocks because the market prices everything perfectly. This book will teach you the flip side of the coin - <USER2> side that guys like Buffet made billions with. Even if you don't want to invest in stocks or mutual funds, it will give you the right philosophy for financial decisions.

</comment><comment><USER4> My first internship offered a 401k with company match. The trick for that is to put in exactly as much to get the company "free" money. If they match 100% up to the first 3% of your salary, you just got a 3% raise so long as you agree to put your money in a 401k. If you ever leave, then you'll just roll the account over. Not all of that money could be yours (read the vesting rules), but a good chunk of it probably will be. At worst, did you miss 3% of your salary? You'll get it back in 40 years.

After that point, you're going to get wildly different ideas of how to save your money. Most commonly people will suggest high risk, high return assets (stocks or stock funds, as opposed to bonds or bond-based mutual funds), since even if you lose everything, then you still have the rest of your life ahead of you. Basically what it comes down to is how to compound your earnings combined with the tax burden. Each of these have different rules as to maximum contributions per year, when you can take your money out, etc.

* Traditional 401k or IRA - Pre tax money, lowers your income taxes now in favor of paying tax later (you suspect your tax rate will decrease -- probably not true as a student)

* Roth 401k or IRA - Post tax money. Pay tax now, and none later (you suspect your taxes will go up)

* Brokerage accounts - Pay taxes on gains as income or capital gains (most tax, most liquidity).

Within each of these you can choose how to invest your money for your risk/reward tolerance. Bonds, Funds, and Stocks are how most people invest. Some choose to do real estate. Some choose to do more riskier things like derivatives. Wikipedia has a full list ([http://en.wikipedia.org/wiki/Financial_market](http://en.wikipedia.org/wiki/Financial_market)).

So long as you diversify, you should get an overall good return and won't be subject to volatility in one particular investment. However, due to minimum investments for the first few years it's probably best to diversify over time, rather than right from the beginning.

I graduated 2 years ago, so I've had to brush up on all of this stuff, along with supplemental benefits like AD&D, life insurance, etc. If you have any questions my email is in my profile.

<comment><USER5> +1 for good advice about matching, vesting, and diversifying.

Here is a postcard cheat-sheet of "what to do with your money," per the OP's request:

1) Pay down credit cards and never carry a balance.

2) Keep 3-6 months' worth of income in a savings account for emergencies.

3) Invest in your 401k up to company match. Put everything in a TSM or SP500 index fund and forget about it.

4) Pay down mortgage, car payments, student loans.

5) If you still have any money, talk to an accountant for investment advice. 401k, IRA, etc are good options.

6) Invest for the future, and live a full life in the present!

</comment></comment><comment><USER6> First, one of my coworkers who will be retiring within the next 10 years recently attended a retirement seminar provided by our company. He mentioned to me that the seminar speaker said that it should be young people going to these, because by the time you are 50, it's too late to make the changes which will have the biggest financial impacts on your retirement.

I don't know what the future will hold, so I am maxing out my TSP (Thrift Savings Plan for US federal employees, like a 401k). I even front-load it, paying as much as I can in the first couple of months of the year, and leaving it at 5% for the rest of the year to get all the matching funds I can. By front-loading, the interest has more principle to compound for the rest of the year. I've also found several TSP websites where people get together to discus ways on maxing their retirement savings. I imagine there might be similar websites for people with 401k plans if you look.

Because I'm at sea and have almost no expenses, I'm investing almost all of my paychecks which will help me achieve financial independence within a matter of years. I have a brokerage account in which I'm buying stocks. When you are younger, you can afford to take more risk with your investments. As you get older, you should be taking less risk, because essentially you can't afford to start all over.

I also recently discovered Early Retirement Extreme (0). You don't have to be as "extreme" as the author, but there is some sound advice in there. I think it helps that I'm an INTJ like the author and most of the readers of the blog. You have to embrace the idea that saving is better for the individual than perpetuating debt.

(0) [http://earlyretirementextreme.com](http://earlyretirementextreme.com)

</comment><comment><USER7> If you ever work at a company with a 401k, make sure you read the matching rules and vesting rules for company contributed funds! If you are not earning 100% of company matched money, you're throwing away money that the company already allocated as part of your total compensation. Maybe that's OK if you want to take the cash home instead, but at least be aware of your options.

Also make sure you look at fund fees; some employers will let you continue operating your 401k after you terminate employment, but you may pay higher fees. Some funds may look great but may have very high fees.

If your company makes automatic contributions (not matching; straight-up contributions) make sure the cash is actually invested in something. Company contributions may have wildly differing vesting schedules, too, be aware.

</comment><comment><USER8> I enjoyed reading this book by Ramit Sethi: [http://www.amazon.com/Will-Teach- You-Be-Rich/dp/0761147489/r...](http://www.amazon.com/Will-Teach-You-Be- Rich/dp/0761147489/ref=sr_1_1?s=books&ie=UTF8&qid=1378261980&sr=1-1)

Its full of very basic fundamental advice. It doesn't go into depth into securities options, but emphasizes practical "set and forget" tactics.

TLDR; invest early, invest often, keep a good credit score, stock market is great for returns over the long run (index funds/mutual funds), keep a savings account, automate your investing. Also, did you know your credit card offers perks like extended warranties on purchases (at no cost)?

</comment><comment><USER9> First is to figure out what your goals are long term. Then figure out how to work towards those goals. If a 401k fits those goals then start a 401k. Most of the time, though not always, you need to be full time before you can contribute to a company 401k plan.

Best advice I can give, though, is 1) read a lot and 2) never take anything you read at face value.

</comment><comment><USER10> Get a few different perspectives. Here's one: [http://www.mrmoneymustache.com/](http://www.mrmoneymustache.com/)

<comment><AUTHOR> Do you have any other business related community sites?

</comment></comment><comment><USER11> Financial tip for a college grad..

Do either option 1 or 2: Option 1: Spend as much as you want during your college years, go party, and go get laid w/o caring about your grades or getting a job. You still are gonna have to work for the next 40 years anyway.

Option 2: Do a startup while you're in school, ignore everything else(girls, grades, getting a job, etc) so you can strike it rich. Even if you fail, you're still gonna have to work for the next 40 years anyway.

</comment><comment><USER12> Bogleheads.org is an incredible resource. It's like "HN for investments", IMHO.</comment>


Craigstarter: DIY Replacement for Kickstarter - <AUTHOR> https://github.com/cmod/craigstarter <comment><USER2> As more and more "curation" happens with the big providers, it's fun to see people rediscover the benefits of running their own sites that they control.

I'd love to see more distributed models around forming and maintaining communities start to pop up. A distributed directory similar to DNS that no one entity totally controls pointing to independent content publishers.

It's time for the Internet to get back more on the distributed side of things, especially since the modern equivalent of a nuclear attack is a large site just up and banning someone for a vague TOS violation with no human to appeal to unless you get lucky in shaming them enough on Twitter to respond. Yeah, I want my livelihood dependent on that service model.

<comment><USER3> I did the same thing right from the start with my newsletter* — referral engine, editor, archives, mail stuff, etc. Nothing worse than building a massive audience on the back of substack & co.

* [https://briefingday.com](https://briefingday.com)

<comment><USER4> Have a blog post or other documentation on your endeavors to own your destiny to share with other content creators? I think there's enormous value in communicating to those folks the value prop of what you describe.

<comment><USER3> I guess your handle would be the reason why not — but will consider it ;)

<comment><USER4> I feel you :) Appreciate it!

</comment></comment></comment></comment></comment><comment><USER5> My initial reaction to this was that this was dumb because Kickstarter gives you something very important: a large userbase.

But Craigstarter makes a good point - > if you already have a community built up, and have communication channels in place (via a newsletter, for example), and already run an online shop, then Kickstarter can be unnecessarily cumbersome.

I'm sure there are lots who meet that criteria. Now I just need to build my newletter mailing list...

<comment><USER6> > _But Craigstarter makes a good point - > if you already have a community > built up, and have communication channels in place (via a newsletter, for > example), and already run an online shop, then Kickstarter can be > unnecessarily cumbersome._

I think the above mainly applies for projects that are looking for minimum viable funding (for example, to fulfill a minimum order quantity).

For projects that are looking to sell as much as possible, Kickstarter's value comes from the discovery they provide, including them emailing a user's followers whenever the user backs something.

</comment></comment><comment><USER7> A (now sold out) example: [https://shop.specialprojects.jp/products/kissa-by- kissa](https://shop.specialprojects.jp/products/kissa-by-kissa)

<comment><USER8> That's really cool - wish I would have caught it when it was being funded. I'd love to take a more walking-focused trip to Japan

<comment><USER9> According to the newsletter there'll be a second, slightly different print coming out later this year. So you might be able to!

</comment></comment></comment><comment><USER10> Successful crowdfunding campaigns require substantial marketing efforts outside the crowdfunding platform, such as email lists, a community or customer base familiar with the brand/product/team, social media ads, etc. Exceptions exist, such as getting funded solely by being featured on the homepage or having an extraordinary product featured by the media, but those are relatively rare. Thus a campaign's success is mostly decoupled from the platform itself.

This is a great idea to avoid substantial platform usage fees in exchange for the ever reducing value proposition that Kickstarter or other centralized crowdfunding platforms provide.

<comment><USER11> Kickstarer's search is useless. Not sure what value they provide other than collecting money and a page to describe the proposal.

</comment></comment><comment><USER12> Book maker here. This is a great idea! For my 2nd book, I kinda hacked my own system to just do this. I was targeting a low amount and paying a middleman any % of that was atrocious to me.

Kudos on this. Craig always delivers when it comes to making books.

What will it take to make it Wordpress friendly?

<comment><USER13> It sounds like you were self-publishing, right? If so, did you consider a POD solution like Lulu or any of the others out there?

<comment><USER12> I did not consider Lulu or other such platforms. I was only focused on crowdfunding at that stage and most of these platforms felt overwhelming/doing too much to me.

</comment></comment></comment><comment><USER14> Isn't there some amount of trust in backers using kickstarter that the funds are returned if they don't reach their targets?

While this looks great, it seems like you are donating directly to the creators. Are people willing to hand over their money that easily?

<comment><USER15> I believe this value proposition was more important at the start of contemporary crowdfunding (~2010), in order for folks to trust crowdfunding. As I note in the Craigstarter README:

> The lack of goal-triggered payments is probably the biggest "downside" to > Craigstarter. Technically, I believe you can have charges be authorized on > checkout, but only pushed through on "shipping" — allowing one to > approximate the Kickstarter experience on Shopify. However, these charge > authorizations are short lived, and this would only work (as far as I can > tell) for quick campaigns.

> That said, many Kickstarter campaigns are run as promotional tools more than > strict fundraising tools, with the intent by creators to ship no matter > what. In theory, one could set a minimum goal on Shopify which, if not met, > would trigger a manual refunding of all backers (minus the ~2.8% processing > fees). Robin Sloan rigged up something similar with his 2020 Sloanstarter > campaign.

> In the end, if you have an audience, and you have reasonable baseline goals, > then the issue of "raising enough funds" for a project launch is often not > an issue.

</comment></comment><comment><USER16> As with all tools, they can be used for good or bad but as a frequent contributor to /r/shittykickstarters I am afraid my worldview might be warped and I think this will be used a lot more by scammers to sidestep whatever meagre checks Kickstarter has in place.

</comment><comment><USER17> I assumed this was so named because it was supposed to disrupt kickstarters cut in the same way craigslist disrupted classifieds, but it seems it's because the creators name is Craig. A happy accident, then, because I think my interpretation still works

<comment><USER18> This won't stop Craigslist from sending him a Cease and Desist anyway, but hopefully they won't back it up with a lawsuit, wasting everyone's time.

<comment><USER19> I'd bet they'd actually have strong case.

</comment></comment></comment><comment><USER20> I looked through the tutorial video, and it doesn't seem very simple... thought Shopify would have a plugin system where everything would be wired up without you having to edit templates and code.

<comment><USER21> Shopify does have a plugin system, and there are several freemium/paid crowdfunding plugins that seem to require minimal configuration.

[https://apps.shopify.com/search?q=crowdfunding](https://apps.shopify.com/search?q=crowdfunding)

</comment></comment><comment><USER22> I've been meaning to do something like this, but imagined it as an interface that takes information, saves Stripe payment tokens, and only charges them when the goal had been met and optionally the timer was up. I'd provide a minimally styled HTML template for the low-code crowd and let others style it however they like after grabbing the info from an API. Still losing about 3% but then the user wouldn't be beholden to Shopify.

</comment><comment><USER23> Built on shopify, so presumably shopify is taking their usual cut of payments. Seems weird to me to self-host with another middle-man...

<comment><USER24> The project is pretty clear that the benefit is you're merely paying 2.8% instead of 10%. It's not about completely cutting out the payment processor as a middleman--that's essentially a requirement for credit card transactions-- it's about clawing back the 7.2% you're paying for the platform. I think it's great.

<comment><USER23> Interesting, you are right. I was under the impression that shopify added a pretty sizable transaction fee, above the base rate of the payment processor, but that is not really the case. Shopify's base rate is basically the same as paypal and stripe's base cc processing rate. Cynicism retracted!</comment></comment></comment>


How to Hang Chrome, Firefox and Node.js Native Func - <AUTHOR> http://codingsight.com/how-to-hang-chrome-firefox-and-node-js-inside-native-func/ <comment><USER2> Here's another way.

        while(true){};</comment>


0.30000000000000004 - <AUTHOR> http://0.30000000000000004.com/ <comment><USER2> Once I wrote a library for double-to-string conversion and vice versa, which handles such roundings nicely: [https://github.com/mkupchik/dconvstr](https://github.com/mkupchik/dconvstr)

Key idea is not just to map binary floating point value X to a decimal floating point value Y, but instead (in extended precision, with 64-bit mantissa) compute an interval of decimal floating point values [Y1, Y2] which maps back to X (in standard precision, with 53-bit mantissa). Then choose such Y from [Y1, Y2] that Y has the shortest decimal representation.

<comment><USER3> The state-of-the-art is the Errol algorithm of Adrysco, Jhala and Lerner (2016), which is proven to be always correct: [https://cseweb.ucsd.edu/~lerner/papers/fp-printing- popl16.pd...](https://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pdf)

<comment><USER4> [https://github.com/marcandrysco/Errol](https://github.com/marcandrysco/Errol)

> Our original evaluation of Errol against the prior work of Grisu3 was > erroneous. The evaluation indicates a 2x speed improvement over Grisu3. > However, corrected performance measurements show a 2x speed loss to Grisu3.

<comment><USER3> Yeah, it's unfortunately not the fastest algorithm known, despite what was originally thought, but it is still the fastest accurate one.

<comment><USER5> Grisu isn't accurate?

<comment><USER6> Author here.

Grisu is accurate, but not always optimal. However, it figures out when that happens and lets you bail out to a slower algorithm when that happens. If you want full speed you should use Grisu, and then use Errol as a bailout.

A bit more context: there are 3 important properties when printing floating- point numbers.

\- accurateness: you want the printed number to read back to the same number.

\- shortness: often you want the shortest decimal representation: "0.3" and not "0.2999999999999999889". The latter is more precise, but reads back to the same number as "0.3".

\- closeness: given two decimal representations of the same length, you prefer the one that is closer to the actual number.

I call the combination of these three properties "optimal".

Note that shortness and closeness are not always crucial. For example, a json- encoder could easily drop those, if the encoding is faster without them. Also, some languages drop shortness in favor of printing something closer to the input.

Grisu always produces accurate results. However, it sometimes can't tell if it already has the shortest and closest number. However (by being conservative) it can tell the user when that happens. In that case, one can fall back to another complete algorithm.

The double-conversion library ([http://github.com/google/double- conversion](http://github.com/google/double-conversion)) does exactly that. It uses the slower bignum algorithm in these cases.

</comment></comment></comment></comment></comment></comment><comment><USER7> Previous discussions:

[https://news.ycombinator.com/item?id=10558871](https://news.ycombinator.com/item?id=10558871) (1.5 years ago, 240 comments)

[https://news.ycombinator.com/item?id=1846926](https://news.ycombinator.com/item?id=1846926) (6.5 years ago, 128 comments)

<comment><USER8> Someone should figure out the mean length of time between article repeats on HN. And then find some correlation with university degrees and job tenure.

<comment><USER9> Do you have a hypothesis about what the correlation might be?

</comment></comment></comment><comment><USER10> _It 's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base._

In a way, not so simple (obvious to you? not to me)

<comment><USER11> Modern, lets say, post turn of the century popular languages all support some kind of rational data type allowing native fraction arithmetic.

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

Anyway...

It turns out that humans like numbers that are evenly spaced like 1/10, 2/10 (1/5), 3/10, 4/10\. That all seems pretty evenly spaced to us, but its actually totally arbitrary that we have 10 handy (ugh the puns) appendages. If we chill with space aliens they will think numbers are evenly spaced like 1/14, 2/14 (aka 1/7), 3/14, 4/14 (aka 2/7)... much like jamming a metric socket on an imperial nut to fix your car, the amount of error varies wildly base on size. You can get away with a 9/16 socket on a 10 mm nut most times, but a 15/16th socket will probably require a hammer to fit a 24mm nut. Or just round off all the nuts with a vise-grip pliers. Anyway the space alien's 7/14 is actually a perfect match to our 5/10 but the amount of error varies from not much, to quite a bit, in the other attempts at interplanetary standardization. Likewise if you think of the computer as a space alien (not too far from truth, I sometimes feel) it uses binary and thinks numbers like 1/8, 2/8 (1/4), 3/8, are evenly spaced. Or as some specific example expressing our 1/2 in floating point is pretty easy for most computers while expressing 1/5 or 1/3 is somewhat less successful, or somewhat far in error compared to our closest 1/10th based numbers.

In the old days like half a century ago there were competing software floating point designs with varying levels of success vs speed. Everything is super boring today and standardized. 72 bit pdp-10 floating point was from a romantic adventurous era, like an Indiana Jones movie (well, one of the good ones). IEEE 754 is modern and better in all regards, yet has all the panache and style of a modern econobox commuter car. Think of the glory of PDP8 Fortran floating point spread unevenly across three words of four octal digits, 2 bits of signs, 2 bits MSB of mantissa, and 8 bits of exponent in the first 12 bit octal word, now that is something glorious to wake up to in the morning.

<comment><USER12> Thirty years ago the BASIC languages of the 8-bit computers used non-IEEE 754 floating point math (most typical I've found is 5-byte version---one byte for sign, one for exponent, three for mantissa).

</comment></comment></comment><comment><USER13> Whenver IEEE 754 and its quirks are discussed a potential alternative (but so far without hardware support) called Unum - Universal Numbers - should not go unmentioned:

[https://en.wikipedia.org/wiki/Unum_(number_format)](https://en.wikipedia.org/wiki/Unum_\(number_format\))

Previous discussions (>2y old):

[https://news.ycombinator.com/item?id=9943589](https://news.ycombinator.com/item?id=9943589) and

[https://news.ycombinator.com/item?id=10245737](https://news.ycombinator.com/item?id=10245737)

A slideset: [https://www.slideshare.net/insideHPC/unum-computing-an- energ...](https://www.slideshare.net/insideHPC/unum-computing-an-energy- efficient-and-massively-parallel-approach-to-valid-numerics)

<comment><USER14> Just a heads up - we're moving on from the unums standard.

[https://youtu.be/aP0Y1uAA-2Y](https://youtu.be/aP0Y1uAA-2Y)

<comment><USER15> A note on the posit (aka sigmoid) standard that Gustafson discusses in the video:

1\. Main feasibility benefit: behaves like IEEE 754 numbers in terms of accuracy.

2\. Main performance benefit: able to match IEEE 754 precision & accuracy in fewer bits (~1/2) than IEEE 754.

3\. When the standard is finalized, will specify behavior that in IEEE 754 allows for a degree of interpretation, meaning that behavior may not be reproducible across runs and machines.

4\. IEEE 754 error-handling, that requires extra silicone or cycles, is not implemented. Overflow/underflow not considered errors leading to Inf or NaN, but rounded to nearest representation, hence has uniform treatment (rounding) across numbers with no exact representation. Illegal operations to be handled as general error à la integers rather than giving rise to NaN.

4a. Performance benefit: 4. should mean that less silicone or cycles required to perform arithmetic compared to IEEE 754, so Gustafson believes, though his team has only just finished with an ALU/FPU circuit schematic for posits.

4b. Programming using posits should feel more like programming using integers, versus handling NaN, Inf.

<comment><USER14> A few notes:

1\. Main feasibility benefit: behaves like IEEE 754 numbers in terms of accuracy.

I think you mean "...in terms of allocation and storage"

2\. I would like to disclaim that posits improve over IEEE 754 precision & accuracy _over some value ranges_. Over others, it's worse. The argument though is that you're more likely to be using those value ranges than the ones where you want. It's also not nearly 2x. For 64-bits, for example you'll realistically get about 6-7 extra bits of precision around 1. The standard DOES require features like "exact dot product" operation, which can allow you to do things that are "impossible" with the standard 754 spec; for example, exact solutions of systems of linear equations using convergent methods.

The way I've been thinking about it of late, is that floats and posits are a 'lossy compression of the real number line'; posits make better choices about how to compress this information, but there are of course tradeoffs.

The rest of it is great!

</comment></comment></comment></comment><comment><USER16> Any time you're generating percentage data that should sum to 100, not appreciating floating point math will burn you.

For those interested, the largest remainder method ([https://gist.github.com/hijonathan/e597addcc327c9bd017c](https://gist.github.com/hijonathan/e597addcc327c9bd017c)) is useful for dealing with this.

<comment><USER17> Using tricks to make numbers total what you think they "should" other than using rounding to proper amount of precision is lazy and deceitful.

<comment><USER18> Depends on the application of this, i.e. whether the total is more important or the individual values are more important.

Example: You're filling out a timesheet for a contracting job, and you worked 8 hours on several different tasks for your client, but your client's software rounds things to the nearest hour, then it would make sense to use an algorithm like this if your pay was going to be determined by this data entry. If your pay was not determined by this data entry then it may make sense to just round normally.

</comment></comment></comment><comment><USER19> > Your language isn't broken, it's doing floating point math.

Yes, your language is broken if you have no way out of floating point math. JavaScript, for example, is fundamentally broken.

<comment><USER20> There are a huge pile of libraries for doing bignum, rational, fixed point, decimal, complex, vector, polynomial, symbolic, etc. math in Javascript. If you want you can even write one for 7-adic arithmetic, Eisenstein integers, numbers expressed in the golden ratio base, or points on the surface of a torus.

There's no language that can build in all possible number systems, and it's not really the place of a language to try.

It would be nice if JavaScript made a better type distinction between integers and floats though.

<comment><USER19> Yes, every Turing complete language can build integers and other types of numbers atop floating point numbers if necessary. That doesn't make it any less broken.

</comment></comment></comment><comment><USER21> Here's something that would probably help lessen the confusion: don't allow or atleast warn about implicit conversions in binary floats in source code literals.

        float foo = 0.3;    // warning: invalid binary float value
        float bar = 0.3f;   // ok, converts into nearest bin float
        decimal qux = 0.3m; // ok
        decimal feh = 0.3;  // why not; will be exactly 0.3

All in all, languages go for decimal floats by default but then the implicit conversions ruin it for everybody who's still learning.

<comment><USER22> Good suggestion, but it still wouldn't prevent beginners from just learning the 0.3f notation as an idiom and skipping the explanation. The trouble with floats is that understanding them depends on knowledge of binary, scientific notation, etc. It's a lot for someone who is only just getting to grips with how a program works.

</comment></comment><comment><USER23> C# is missing an example using decimal type:

Decimal uses 128 bits to hold it's data and seems to handle rounding differently to System.Double, e.g. 0.1 and 0.2 using decimals evaulates to 0.3:

> 0.1M + 0.2M 0.3

You can read more about decimal here: [https://msdn.microsoft.com/en- us/library/364x0z75.aspx](https://msdn.microsoft.com/en- us/library/364x0z75.aspx)

</comment><comment><USER24> For people using C or C++ I can recommend using decimal floating point (which may be added to C++20 in the standard).

Contrary to the "default" floating point, which are base 2 and do not support precise presentations of certain numbers, you can use a decimal floating point system which uses base 10 and therefore allows exact and precise presentation and solves the problem mentioned on the page.

Also important: since 2008 this is standardized in IEEE 754-2008 which added support for decimals.

Explanation of decimal floating points: [https://en.m.wikipedia.org/wiki/Decimal_floating_point](https://en.m.wikipedia.org/wiki/Decimal_floating_point)

Libraries:

[https://software.intel.com/en-us/articles/intel-decimal- floa...](https://software.intel.com/en-us/articles/intel-decimal-floating- point-math-library)

[http://www.bytereef.org/mpdecimal/](http://www.bytereef.org/mpdecimal/)

[http://speleotrove.com/decimal/](http://speleotrove.com/decimal/)

C++ Standard Proposals:

[http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2012/n340...](http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html)

[http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3871.ht...](http://open- std.org/JTC1/SC22/WG21/docs/papers/2014/n3871.html)

<comment><USER25> Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

<comment><USER26> This is solved by the Scheme numerical tower, which prefers exact representations (including exact rationals) unless inexact representation is explicitly requested or forced by an operation that doesn't support exact results.

<comment><USER27> The problem is remembering to only input rationals :) So instead of doing (iota 100 0.1 0.1), you do (iota 100 (/ 1 10) (/ 1 10)). That does not work in chicken for some reason.

I don't know if precomputation is ever guaranteed for those things, but otherwise it would be neat to be able to input rationals directly into the source.

Edit: So, this is scheme standard discovery week: apparently inputing 1/10 works just fine. I can't believe I missed this.

</comment></comment></comment></comment><comment><USER28> My personal view is decimal arithmetic should be the default and floating- point should be the library in scripting languages. And probably also Java/C#/Go-type languages.

<comment><USER29> Decimal only takes care of a subset of cases. I.e. those where the source data nicely lines up in decimal. Good for finance (although I think Britain made a mistake when it gave up the old penny and the shilling). But even there, you sometimes have to divide by numbers like 12 and 365.

The point is NO representation is going to be idiot proof. So you just need to make a sufficient set of representations easy to use, and then try to teach the "idiots" what the underling issues are.

<comment><USER30> Decimal does only take care of a subset of cases, true. But 1) it's a very common subset, and 2) when it breaks down, people generally understand how and why, because they've dealt with it elsewhere.

</comment></comment></comment><comment><USER31> >Perl 6, unlike Perl 5, uses rationals by default

I'm not sure this is such a good idea. I love rational datatype, but it's too easy to shoot yourself in the foot with simple numerical procedures resulting in gigantic bignum denominators.

<comment><USER20> Rational numbers are horrible for most numerical computing. The denominators double in length with every multiplication, so computation speed gets slow exponentially.

Any time there's any degree of uncertainty about a quantity (e.g. it comes from a physical measurement) there's also no longer any advantage to using rational arithmetic. This turns out to encompass most practical situations.

Rational arithmetic also breaks down entirely in the face of square roots or trig functions, unless you go for a fully symbolic computation environment, which gets even much slower.

Rational arithmetic is mostly nice when the problems have been carefully chosen so the operations will stay rational and the answers will work out nicely, e.g. in high school homework.

</comment></comment><comment><USER32> Rexx has decimal arithmetics so 0.1+0.2 is 0.3 ...

[http://www.rexxla.org/events/2001/mike/rexxsy01.PDF](http://www.rexxla.org/events/2001/mike/rexxsy01.PDF)

<comment><USER33> Unsurprising considering the IBM affiliation of Rexx and decimal arithmetic being IBM's pet issue.

<comment><USER34> The fact that we do binary floating point by default is an artifact of RAM being expensive way back in the day while arithmetic coprocessors became cheap. Single-precision is 4 bytes and can represent practically every quantity you care about precisely enough.

While IBM has been harping about this for ages, BCD (binary coded decimal) was sufficiently important that it had special instructions on even the earliest microprocessors. The 6800/8080/Z80 series had DAA (decimal adjust accumulator) and the 6502 had SED/CLD (set/clear decimal mode). The 8008 is notable in not having a specific BCD instruction.

And the 4004, which started it all, was a BCD oriented microprocessor from the start.

<comment><USER12> And the 8086 (on up), the 68000 family, and the VAX also had BCD instructions. When I wrote my own 6809 emulator [1] the DAA instruction was the hardest one to get right [2]

[1] [https://github.com/spc476/mc6809](https://github.com/spc476/mc6809)

[2] Specifically the condition code results.

</comment></comment></comment></comment><comment><USER35> The Common Lisp answer is 0.3 and not 0.30000000000000004 because those are single float literals: for double float literals, we have (+ 0.1d0 0.2d0) => 0.30000000000000004d0.

I would imagine this is the case for several of the other examples, too.

<comment><USER36> You can tell Common Lisp to read double-floats by default.

        CL-USER 113 > (+ 0.1 0.2)
        0.3

        CL-USER 114 > *read-default-float-format*
        SINGLE-FLOAT

        CL-USER 115 > (setf *read-default-float-format* 'double-float)
        DOUBLE-FLOAT

        CL-USER 116 > (+ 0.1 0.2)
        0.30000000000000005

Thus if one wants to make sure which float format Lisp should be reading,

a) specify the default format, as above

b) or use s, f, d, and l to specify the format (short float, single float, double-float, long-float). Example 1.0s0, 1.0f0, 1.0d0, 1.0l0

</comment></comment><comment><USER37> These examples all seem to be using double precision floating point, which might be misleading. For example, the C++ snippet is adding two double literals, not floating point literals. The result is even more inaccurate using single precision arithmetic:

        #include <iostream>
        #include <iomanip>

        int main() {
            std::cout << std::setprecision(17) << 0.1  + 0.2  << '\n'; // 0.30000000000000004
            std::cout << std::setprecision(17) << 0.1f + 0.2f << '\n'; // 0.30000001192092896
        }

</comment><comment><USER38> Side anecdote: Many, many years ago, I wrote a lease payment plan calculator for a big bank-linked leasing company when they moved from AS/400 to .Net. I made sure all rounding was policy driven, not only in precision, but also in where roundings would occur during the calculations. 1 cent differences do matter in such environments. Somehow it passed all the extensive regression tests that compared to their mainframe code out of the box with the config based on nothing more than my guesses. AFAIK the code is still in production to this date.

</comment><comment> ayush--s It's stuff that should be a part of very beginning of any CS101. Float arithmetics != Decimal arithmetics

<comment><USER39> It is.

</comment></comment><comment><USER40> Base 2 floating point is perfectly OK. The problem is people using floating point not knowing that IEE754 floating point representation is binary, and not decimal, so most decimal constants will not have an exact match. Said that, many implementations do buggy binary <-> decimal conversions, not because of the limit accuracy in the conversion, but because of "creative" rounding criteria.

</comment><comment><USER41> More interesting is exactly why floating point 0.1 + 0.2 != 0.3, and it's due to the way rounding is defined in the IEEE-754 standard:

> _An implementation of this standard shall provide round to nearest as the > default rounding mode. In this mode the representable value nearest to the > infinitely precise result shall be delivered; if the two nearest > representable values are equally near, the one with its least significant > bit zero shall be delivered._

If we convert from decimal to double precision (64-bit) floating point, here is how they are represented in hexadecimal and binary:

        0.1 -> 0x3FB999999999999A = 0011 1111 1011 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1010
        0.2 -> 0x3FC999999999999A = 0011 1111 1100 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1010
        0.3 -> 0x3FD3333333333333 = 0011 1111 1101 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011
                    ^^^^^^^^^^^^^                  ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^

Taking 0.1 as an example, here is what its binary representation actually means:

        sign exponent    mantissa (marked using ^ in the table above)
           0 01111111011 1001100110011001100110011001100110011001100110011010

The exponent is encoded as its offset from -1023, so in this case we have 01111111011 which is decimal 1019, making the exponent 1019-1023 = -4.

The mantissa (BBBB…) is an encoding of the binary number 1.BBBB…, so with an exponent of -4 that makes the actual number 0.0001BBBB….

Applying this for each of these numbers:

        decimal  binary
        0.1      0.00011001100110011001100110011001100110011001100110011010
        0.2      0.0011001100110011001100110011001100110011001100110011010
        0.3      0.010011001100110011001100110011001100110011001100110011

Then if we add 0.1 + 0.2, this is the result:

          0.00011001100110011001100110011001100110011001100110011010
        + 0.0011001100110011001100110011001100110011001100110011010
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-
          0.01001100110011001100110011001100110011001100110011001110
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However we only have 52 bits to represent the mantissa (again marked with ^), so the result above has to be rounded. Both possibilities for rounding are equidistant from the result:

          0.010011001100110011001100110011001100110011001100110011
          0.010011001100110011001100110011001100110011001100110100 <==
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So according to the specification, the option with the least significant bit of zero is chosen.

Converting this back to floating point format we get 0x3FD3333333333334. Note that the least significant four bits of the mantissa are 0100, which corresponds to the trailing 4 in the hexadecimal representation.

This is not equal to 0x3FD3333333333333 (the result of conversion from decimal 0.3, and also what would have been the result here if the rounding was specified the other way.)

Therefore, floating point 0.1 + 0.2 != 0.3.

</comment><comment><USER42> TXR Lisp:

      > (+ 0.1 0.2)
      0.3

Why is that? Because I made a "populist" decision purely for the sake of better "optics". The default printing precision for floating-point values is set at just enough digits to truncate things in this manner:

      2> *print-flo-precision*
      15

The cost to doing that is that the printed representation of floats isn't guaranteed to have read/print consistency: what we print doesn't always read back as the same value which in other words means that we don't have a unique printed representation for each possible value. That default of 15 isn't my favorite language design decision. It's justifiable and I believe in it, but not as wholeheartedly as in some other design decisions.

In any case, language users who need to record every bit of the IEEE 754 double in the printed representation are not just hung out to dry: they can set or override this special variable to 17.

      3> (let ((*print-flo-precision* 17)) (prinl (+ 0.1 0.2)))
      0.30000000000000004
      0.3

(One value here is the `prinl` output, under the dynamic scope of the special variable override; the other is the result value, printed in the REPL, with the top-level binding of it, still at 15 digits.)

Oh, and by the way, we dohn't have to add 0.1 to 0.2 to demonstrate this. Either of those values by itself will do:

      4> (let ((*print-flo-precision* 17)) (prinl 0.1))
      0.10000000000000001
      0.1
      5> (let ((*print-flo-precision* 17)) (prinl 0.2))
      0.20000000000000001
      0.2

Why 15 is used the default precision rather than, say, 14, is that 15 still assures consistency in one direction: if any number with up to 15 digits of precision is input into the system, upon printing it is reproduced exactly in all 15 digits. And 15 is the highest number of digits for which this is possible with an IEEE 64 bit double.

</comment><comment><USER43> For this reason R has a function for comparing results of floating point math: all.equal()

it is quite tricky as it might show that .1+.2 is 0.3, but this is only due to the fact that default output is a subject of default formatting (i.e. occulting more precision numbers)

</comment><comment><USER26> > Your language isn't broken, it's doing floating point math.

Specifically, it's doing binary floating point math, which is an odd choice for decimal literals that's common only because very few languages choose correctness and clarity over performance when dealing with numbers, which leads to all kinds of problems with the most obvious approaches to addressing common problem domains in industrially popular languages. If I had a dollar for, well, every dollar of errors I'd seen because binary floating point values were used in a monetary calculation, I could afford to stop having to deal with them.

<comment><USER44> "If I had a dime for every time I've seen someone use FLOAT to store currency, I'd have $999.997634"

[https://twitter.com/billkarwin/status/347561901460447232](https://twitter.com/billkarwin/status/347561901460447232)

</comment></comment><comment><USER45> How does Postgres "work" properly? I was wondering this the other day. Is something magical going on behind the scenes that I should know about? I added a ::decimal to be safe, but I wasn't sure

<comment><USER46> If you set extra_float_digits=3 then the output will always be large enough to contain the full precision. pg_dump et al. do so automatically.

</comment></comment><comment><USER47> Not sure if I like or dislike Perl6 decision to use rationals by default; so 0.1 is saved as 1/10 and 0.2 as 2/10 and the calculation is precise. But also possibly slow.

</comment><comment><USER48> I'm not sure why the round-trip formatter is used in the C# example ([https://msdn.microsoft.com/en- us/library/dwhawy9k(v=vs.110)....](https://msdn.microsoft.com/en- us/library/dwhawy9k\(v=vs.110\).aspx#RFormatString)). If you omit it then you get the hoped-for result of 0.3.

</comment><comment><USER49> The fun thing is that in the case of an "accurate" result (0.3), you can't be sure whether the language arrived there by somehow doing accurate floating point math - or by following the PHP way of first rounding in base 2, then rounding _again_ in base 10, thus making the result even more inaccurate.

</comment><comment><USER50> For all those interested in Floating Point Arithmetic, I'd strongly recommend reading this paper:

[http://www.lsi.upc.edu/~robert/teaching/master/material/p5-g...](http://www.lsi.upc.edu/~robert/teaching/master/material/p5-goldberg.pdf)

</comment><comment><USER51> As a (kind of) related matter, thought it'd be interesting to mention JavaScript is most likely getting arbitrary precision ints soon [https://github.com/tc39/proposal-integer](https://github.com/tc39/proposal- integer)

</comment><comment><USER52> The C++ code could use std::numeric_limits<double>:: max_digits10 instead of the magical 17!

<comment><USER53> Similarly, for C it could be:

      printf("%.*f\n", DBL_DECIMAL_DIG, .1+.2)

In both cases, support for a relatively new language standard (C++11, C11) would be required.

<comment><USER54> 2011 was six years ago.

<comment><USER55> In terms of C and C++, that's fairly new. Lots of older code using pre-C11/C++11 standards is out there.

</comment></comment></comment></comment><comment><USER56> The link given to Rust rationals is broken. It should be: [http://rust- num.github.io/num/num_rational/](http://rust-num.github.io/num/num_rational/)

</comment><comment><USER57> Use decimals in c# they are used for exact calculation ( and are slower)

PS. It says: Console.WriteLine("{0:R}", .1 + .2);

But when you do .1 + .2 it is 0.3 :) . With the 0:R he actually converts it to double which give the false result

</comment><comment><USER58> That "digits=18" in R example probably bothers me more than it should.

<comment><USER59> I was literally wondering why R gave an "accurate" result for 0.2 + 0.1 the other night, despite using doubles. The printer has an algorithm to round then stringify

</comment></comment><comment><USER60> I wonder if some of the examples exhibit fixed-point precision calculation, and if they do, it would be great to highlight it.

</comment><comment><USER61> I am surprised that domain was still available

</comment><comment><USER62> Whats going on in the second D example?

<comment><USER53> The "f" suffix means they are single-precision (32-bit) FP numbers.

</comment></comment><comment><USER63> SBCL:

        * (+ (/ 1 10)(/ 2 10))
        3/10

<comment><USER64> It's great that your language of choice has fraction support - but real-world engineering problems rarely involve simple rational fractions exclusively. At some point you're going to run into roundoff error.

Plus, fractional computing has severe problems with expanding denominators, which grow very quickly with non-trivial operands. Although computers are fast, the overhead of dealing with hundred-digit-long arbitrary precision integers eventually makes rationals unwieldy.

<comment><USER65> It's a trade-off between speed and accuracy. Not all software deals with real- world engineering problems, and there are plenty of applications where you would prefer accuracy.

I'd rather make that trade-off myself than have the language decide for me. Most of the time I would start with correctness and if speed is needed and the profiler shows that the bottleneck lies in fractional arithmetic, I'll switch to floating point numbers.

A similar trade-off exists with bignums versus 32 or 64 bit integers. There again, I prefer a language that uses bignums by default. I'll convert the bottlenecks to use fixnums after I've verified that it is safe to do so.

</comment></comment></comment><comment><USER66> Why does PHP produce 0.3 instead?

edit: Not sure how I missed that. Thanks!

<comment><USER67> Third example in the article:

 _PHP converts 0.30000000000000004 to a string and shortens it to "0.3". To achieve the desired floating point result, adjust the precision ini setting: ini_set("precision", 17)._

I remember years ago learning something like this and coming to a horrible realization : "My god, _they 're all strings_!"</comment></comment>