Re: PRNG - currently available solutions aren't addressing many use cases

2015-12-05 Thread Raymond Toy 
On Tue, Dec 1, 2015 at 1:45 PM, David Bruant  wrote:

> Le 01/12/2015 20:20, Michał Wadas a écrit :
>
>>
>> As we all know, JavaScript as language lacks builtin randomness related
>> utilities.
>> All we have is Math.random() and environment provided RNG - window.crypto
>> in browser and crypto module in NodeJS.
>> Sadly, these APIs have serious disadvantages for many applications:
>>
>> Math.random
>> - implementation dependant
>> - not seedable
>> - unknown entropy
>> - unknown cycle
>> (...)
>>
>> I'm surprised by the level of control you describe (knowing the cycle,
> seeding, etc.). If you have all of this, then, your PRNG is just a
> deterministic function. Why generating numbers which "look" random if you
> want to control how they're generated?
>

​So I can reproduce a simulation exactly to figure out why it's not
working.  Well, only being able to seed is really required for this.
​


>
> window.crypto
>> - not widely known
>>
> This is most certainly not a good reason to introduce a new API.
>
> As we can see, all these either unreliable or designed mainly for
>> cryptography.
>>
>> That's we need easy to use, seedable random generator
>>
>> Can you provide use cases the current options you listed make impossible
> or particularly hard?
>
>
> Why shouldn't it be provided by library?
>>
>> - average developer can't and don't want to find and verify quality of
>> library - "cryptography is hard" and math is hard too
>>
>> A library or a browser implementation would both need to be "validated"
> by a test suite verifying some statistical properties. My point is that
> it's the same amount of work to validate the "quality" of the
> implementation.
>
> - library size limits it usability on Web
>>
>> How big would the library be?
> How much unreasonable would it be compared to other libraries for other
> use cases?
> I'm not an expert on the topic, but of the few things I know, it's hard to
> imagine a PRNG function would be more than 10k
>
> - no standard interface for PRNG - library can't be replaced as drop-in
>> replacement
>>
>> We've seen in the past that good libraries become de-facto standard (at
> the library level, not the platform level) and candidate to being shimmed
> when the library is useful and there is motivation for a drop-in
> replacement (jQuery > Zepto, underscore > lodash). This can happen.
> We've also seen ES Promises respect the Promise A+ spec or close enough if
> they don't (I'm not very familiar with the details).
>
> David
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Ray
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.log2 applied to powers of 2

2014-09-18 Thread Raymond Toy 
On Thu, Sep 18, 2014 at 3:17 AM, Claude Pache claude.pa...@gmail.com
wrote:

 Just tried in the console of Chrome (with Experimental JavaScript
 features flag enabled).

  Math.log2(8)
  2.9996

 Firefox gives me the correct answer (3).

 Question: Should Math.log2 give exact results for powers of 2?

 The same issue holds for Math.log10 (might be applicable for nonnegative
 powers only): Math.log10(1e15) != 15 in Chrome.


​If you can, please file a bug against v8:
https://code.google.com/p/v8/issues/entry

I consider these to be bugs in the implementation.​



 —Claude

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
Ray
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Strawman proposal] StrictMath variant of Math

2014-08-01 Thread Raymond Toy 
On Fri, Aug 1, 2014 at 11:40 AM, Brendan Eich bren...@mozilla.org wrote:

 Mathias Bynens wrote:

 On 1 Aug 2014, at 09:25, Carl Shapirocarl.shap...@gmail.com  wrote:

Thanks for the suggestion.
 As Ray pointed out, the Math package in Java still has its
 accuracy requirements specified and so it is not analogous to the current
 status of Math package in ES6.  Also, the StrictMath package and the
 strictfp class qualifier came about in Java back when the x87 was the
 predominant FPU.  Because of the idiosyncrasies of the x87 one could not
 compute bit-identical floating point results without additional overhead.
  Nevertheless, the accuracy requirements and conformance was still achieved
 with satisfactory performance.  Much of the history is still available
 on-line
 http://math.nist.gov/javanumerics/reports/jgfnwg-minutes-6-00.html
   http://math.nist.gov/javanumerics/reports/jgfnwg-02.html
 It is unclear how much of these strict modes is still relevant
 given that SSE2 is now the predominant FPU.  The strict modes were always
 effectively a non-issue on other architectures.
 Much of the pressure to relax the accuracy of the special
 functions seems to be coming from their use in various benchmark suites and
 the tireless efforts of the compiler engineers to squeeze out additional
 performance gains.  Requiring bounds on the accuracy of the special
 functions has the additional benefit of putting all the browsers on equal
 ground so nobody has to have their product suffer the indignity of a
 benchmark loss because they try to do the right thing in the name of
 numerical accuracy.


 +1

 Introducing a new global `Math` variant wouldn’t solve the
 interoperability issues. IMHO, the accuracy of the existing `Math` methods
 and properties should be codified in the spec instead.


 Right, we are not going to add StrictMath.

 The notes from this week's TC39 meeting at Microsoft will be published
 soon, some time next week, but to cut to the chase: we agreed to specify
 harder and stop the benchmarketing race to the bottom, as Carl suggested.
 We will need f.p. gurus helping review the work, for sure. Thanks to all of
 you contributing here.


​This is really great news!
​



 /be

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Strawman proposal] StrictMath variant of Math

2014-07-31 Thread Raymond Toy 
On Thu, Jul 31, 2014 at 5:16 PM, Isiah Meadows impinb...@gmail.com wrote:

 I was looking at the number of complaints about the Math object,
 especially regarding the lack of required precision (refer to the thread Re:
 ES6 accuracy of special functions for a lengthy discussion on this).
 Because of this, I propose that a new object, StrictMath, should be added.
 This would be analogous to java.lang.Math (performance) vs
 java.util.StrictMath (accuracy). People could still define their own
 implementations if needed, though.

 Basic specs would be similar to the Math object, but with the following
 caveats:

 1. Fixed-size integer methods such as Math.imul() don't need a StrictMath
 variant.
 2. The input precision must be no more than a Float64 in size (depends on
 how this is spec'd, may not be necessary).
 3. The output should have an error no greater than 1 ulp (the space
 between two adjacent, distinct floating point values, identical to the Java
 spec of an ulp).

 I don't see #2 staying if this is spec'd well, but the rest remain. Java's
 java.lang.StrictMath actually requires the fdlibm semantics and algorithm
 to be used for that class's implementations. java.lang.Math is closer to
 this spec in its own specification.


​Note that, as mentioned in the ES6 accuracy of special functions thread,
java.lang.Math actually specifies accuracy requirements. This differs from
Javascript where there are no requirements.

Math should specify some accuracy requirements and since the spec
specifically mentions fdlibm, the accuracy of fdlibm should be the minimum
requirement.

As for the StrictMath, I would go one step further and say StrictMath must
produce correctly rounded results for the special functions. This might
have been unrealistic a few years ago, but take a look at crlibm
http://lipforge.ens-lyon.fr/www/crlibm/ that implements the C99 special
functions that are correctly rounded (and provably correct) and is also
fairly efficient. One nice side effect of requiring correctly rounded
results is that the spec doesn't have to specify the algorithm.  There is
one and only one correct answer, and implementors are free to do whatever
they want to achieve it.

And finally, if there is to be a package with sloppy accuracy requirements
(or lack there of), it should not be named Math. Call it FastMath or
SloppyMath or whatever as long as it's not Math.  Math has certain
connotations and sloppiness is not one of them. However, I feel that
without some kind of spec, its utility is greatly diminished because every
implementation will be sloppy to a different degree.

Also as mentioned in the ES6 accuracy thread, the people who need
sloppiness know what kind of sloppiness they can tolerate and will do their
own, ignoring any FastMath library.


 --
 Isiah Meadows

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 accuracy of special functions

2014-07-30 Thread Raymond Toy 
On Wed, Jul 30, 2014 at 4:31 AM, Katelyn Gadd k...@luminance.org wrote:

 History has shown that native code developers concerned with
 performance (game devs, graphics devs, etc) will happily use
 approximations of these special functions when performance is
 important, and will pick approximations with suitable accuracy.

 The inverse we have here, where the builtins have unpredictable
 precision, requires developers to test on various os/browser
 combinations to figure out whether they have precision issues, and if
 they do, try to find an accurate high-precision sw implementation of
 these builtins and use that. I think this will lead to a lot of
 unreliable software out there on the web, and worse, lead to existing
 apps breaking when new browser releases reduce precision/accuracy.

 If there's a strong desire for high-performance builtin sin, cos, etc
 it could be reasonable to add Math.fastCos etc but I feel like most
 developers would feel safer with approximations that have known
 characteristics, so you should encourage that instead.


​I think Math.fastCos would be difficult to specify. Only the developer
really knows what the appropriate tradeoff between accuracy and speed
should be. Math.fastCos probably won't satisfy that.​



 On Tue, Jul 29, 2014 at 10:45 PM, Raymond Toy toy.raym...@gmail.com
 wrote:
 
  On Jul 29, 2014 5:47 AM, alawatthe alawat...@googlemail.com wrote:
 
  Clear rules would also help in discussions like this one:
  https://code.google.com/p/v8/issues/detail?id=3006
 
  Background:
  V8 implemented a new version of sin and cos, which is faster, but does
 not
  have the precision many user want.
  One of the comments (#8) said about precision:
 
  - The ECMA script specification clearly states that Math.sin/cos are
  implementation-dependent approximations. There is no guarantees required
  regarding precision.
 
  I think, this feels a little bit odd, because where do we draw the line
  between performance and precision?
  So, again clear rules (even if they are not as strict as in Java), would
  help a lot.
 
  Yes. There are no requirements, but the spirit of the spec is clearly to
 be
  accurate or at least no worse than fdlibm.
 
  Carried to the extreme, this lack of requirements allows implementations
 to
  be conforming even if all functions returned 0 everywhere. Fortunately,
 no
  one does that.
 
 
  All the best
  alex aka alawatthe
 
 
  ___
  es-discuss mailing list
  es-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es-discuss
 
 
 
  ___
  es-discuss mailing list
  es-discuss@mozilla.org
  https://mail.mozilla.org/listinfo/es-discuss
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 accuracy of special functions

2014-07-29 Thread Raymond Toy 
On Jul 29, 2014 5:47 AM, alawatthe alawat...@googlemail.com wrote:

 Clear rules would also help in discussions like this one:
 https://code.google.com/p/v8/issues/detail?id=3006

 Background:
 V8 implemented a new version of sin and cos, which is faster, but does
not have the precision many user want.
 One of the comments (#8) said about precision:

 - The ECMA script specification clearly states that Math.sin/cos are
implementation-dependent approximations. There is no guarantees required
regarding precision.

 I think, this feels a little bit odd, because where do we draw the line
between performance and precision?
 So, again clear rules (even if they are not as strict as in Java), would
help a lot.

Yes. There are no requirements, but the spirit of the spec is clearly to be
accurate or at least no worse than fdlibm.

Carried to the extreme, this lack of requirements allows implementations to
be conforming even if all functions returned 0 everywhere. Fortunately, no
one does that.


 All the best
 alex aka alawatthe


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss