Were denormals discussed at the TC39 meeting? I can't seem to find them in
the meeting notes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
We didn't get to them at the July meeting. I'll put them on the agenda for
Sept.
The likely proposal will be to provide a Math.demormz(x) function and perhaps
also Math.fdzround(x)
Allen
On Aug 12, 2014, at 9:15 AM, JF Bastien wrote:
Were denormals discussed at the TC39 meeting? I can't
On Tue, Aug 12, 2014 at 9:29 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
We didn't get to them at the July meeting. I'll put them on the agenda
for Sept.
Thanks.
The likely proposal will be to provide a Math.demormz(x) function and
perhaps also Math.fdzround(x)
I'd be interested
Here are a few thoughts about denorms (a.k.a. subnormals as of 2008) from a
discussion a few months ago with John Mccutchan, Dave Herman, Luke Wagner
and Dan Gohman.
A few facts to start off with:
- The current SIMD proposal doesn't specify how denormals behave.
- ECMA-262 specifies
On 10 Jul 2014, at 18:54, JF Bastien j...@chromium.org wrote:
Other hardware like GPUs don't support denormals.
Not true, AMD and nVidia GPUs support denormals. Anything that supports
double-precision in OpenCL will support denormals.
My opinion is that denormals aren't something people are
So: Are there compelling enough use cases for #b and #c that we should
care about them?
I don't think so, but Jens seems to disagree. Simulations and
root-finding problems in my experience use smaller precision numbers
(e.g. i16, f16 or f32) to hillclimb close to the solution faster, and
then
On Jul 4, 2014, at 8:19 AM, Benjamin Bouvier wrote:
Hi,
I would like to emphasize this topic, as it actually matters a lot in
signal processing in general. When one is applying operations like
filters, feedback loops and so on, one isn't interested in very low
values, as they can't be
Hi,
I would like to emphasize this topic, as it actually matters a lot in
signal processing in general. When one is applying operations like
filters, feedback loops and so on, one isn't interested in very low
values, as they can't be perceived by the eyes or the ears anyways.
Ideally, we would
Hi,
Using JavaScript (and more specifically asm.js) code in the context of
ScriptProcessor nodes in the Web Audio API has shown a very problematic issue
related to denormalized float numbers.
We have ported our audio C++ code (audio nodes generated using the Faust audio
DSP language :
9 matches
Mail list logo