When I install the ieee754 module from npm, the files in that package all of a timestamp of Jan 1 1970 (or thereabouts, depending on your time zone), using npm version 4.2.0.

This winds up causing an issue with the aws-cli, at least when running in circle-ci, where an error is thrown: ZIP does not support timestamps before 1980. This is detailed in this aws-cli issue: aws/aws-cli#2639. There is a workaround detailed in the aws-cli issue.

Would it be possible for you to address the issue that's causing the 1970 timestamp in the npm module?

Where do the number -24 and -77 come from? They are just like magic code to me.Though I have already learned knowledge about ieee754, i stuck here. Can you explain why it work here or give some tips about it? thanks a lot. @feross

https://github.com/feross/ieee754/blob/master/index.js#L48

I have a node Buffer: <Buffer 42 d9 00 00>.
I am trying ieee754.read(buffer, 0, false, 5832704, 4) but it does not give the expected output of 108.5.

Any chance we could get a sane license on this?

package.json (NPM) claims this is an MIT library, but the LICENSE file says otherwise. It's actually a mish-mash of MIT, 3-clause BSD and a custom footnote. To be clear it's not "dual licensed" as MIT and BSD, it's somehow both at once (with modifications from Brian!)

Could you please contact the original license holders and request the removal of the footnote, then relicense your portion as 3-clause BSD, then there will be just one license for this code.

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 11.0.1 of standard was just published.

This version is covered by your current version range and after updating it in your project the build failed.

standard is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hi,

You forget to tag thus make a release

Hi @feross,

I forked your library here: master...xtuc:master and I was wondering if that's something that could be merged upstream?

Basically, the source is now an ECMAScript Module and uses a Babel to transpile it down to CJS before publishing on npm.

The functions allow specifying the mantissa and the byte length.

When playing around it seems they are always paired like (23, 4) and (52, 8).

Do you know if the mantissa is always tied to the byte length like that?
Or, is there a time when we'd vary the mantissa for some reason?

Thank you

In reviewing the test basic.js, I note that the 4th parameter (mLen) to ieee754.write is 23 for a 4-byte buffer. I thought that the mantissa of a single-precision was 24 bits.

Was altering the ratio of exponent to mantissa the purpose of this code?

The devDependency tape was updated from 4.10.0 to 4.10.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

tape is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴