About the milliseconds I agree with you. It could have the same API like
setHours( hours [, minutes, seconds, mili-seconds] ) of date instance. I
didn't talked about Idea of doing it per instance since I don't know about
browsers and Nodejs implementations. That's why I need your opinion. But
abou
>
>
> >
> > While a good shuffle should be able to start from the initial state and
> > generate a good shuffled result, it is slightly better to progressively
> > shuffle the previous result array into new positions than to start from
> an
> > initial state and compute a 1-off.
>
> Evidence? (BTW,
Replying inline, so I can target specific points better.
-
Isiah Meadows
m...@isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
On Sun, Apr 29, 2018 at 7:31 PM, J Decker wrote:
> I can see that's certainly somethin
I'll make one big recommendation: before you try to formulate a
solution yourself, please do check this out:
https://github.com/kriskowal/gtor
You really have to understand what the status quo is (I presume you
do) and why the status quo is the way it is (this is much less common)
before you can r
On Sun, Apr 29, 2018 at 4:31 PM, J Decker wrote:
> I can see that's certainly something that can be gotten wrong; the in-place
> sort is kind-of nice; but you end up hitting most numbers twice, and with a
> longer array (say a set of 75 bingo balls) you can move the same number
> multiple times.
>
Yeah, thinking of it a bit more carefully, we would need to define a Standard
Stream Interface in order to have the 3 Standard IO Streams. I can start
putting together some research and a sample interface to present my ideas in
more depth, but it'll take some time to flesh everything out. But we
I can see that's certainly something that can be gotten wrong; the in-place
sort is kind-of nice; but you end up hitting most numbers twice, and with a
longer array (say a set of 75 bingo balls) you can move the same number
multiple times.
which gives numbers at the end a higher chance of being at
BTW, I added this to my list of various proposed array additions (as a
weak one) [1].
I did do a little reading up and found that in general, there's a
major glitch that makes shuffling very hard to get right (issues even
Underscore's `_.shuffle` doesn't address), specifically that of the
size of
Why not create an npm module that represents what you'd like to see as an
interface wrapping node's implementation and propose your new interface?
This way you can try building something with it. You'll first need to
implement how you see a synchronous stream in the first place.
Streams can be a
Nice... And not really surprising. I am slightly surprised async/await is
so close to promises. Which means that improving promises performance
should probably be a priority. I still feel the easier to reason with code
is well worth it, given many apps now scale horizontally.
On Sun, Apr 29, 20
On 29.04.2018 18:34, Naveen Chawla wrote:
I don't think there's such a thing as "real random" in digital algos,
just "pseudo random".
You are right. I meant 'unbiased' pseudo randomness here.
Apart from card games, what's the use case?
There are a lot of potential use cases. The best that come
On Sun, Apr 29, 2018 at 10:01 AM, Isiah Meadows wrote:
> I think this would be better suited for a library function rather than
> a language feature. I could see this also being useful also for
> randomized displays, but that's about it. And I'm not sure what an
> engine could provide here that a
fyi, here are some benchmark results of nodejs' client-based http-request
throughput, employing various async-design-patterns (on a 4gb linode box).
overall, recursive-callbacks seem to ~15% faster than both async/await and
promises (~3000 vs ~2600 client-http-request/s).
```shell
$ REQUESTS_P
I’d love to have this use milliseconds rather than minutes, so that we could
kill two birds with one stone. For example, I currently have my own NTP
integration for a web project I run, and for that the offset from the actual
time could be quite small.
> On 29 Apr 2018, at 18:07, Isiah Meadows
I'd personally prefer this to be settable on the instance, rather than
the global object - you can manage universal dates more easily across
time zones this way, and it still enables developers to have the
fallback in case they need an escape or if they have code that relies
on time zones remaining
I think this would be better suited for a library function rather than
a language feature. I could see this also being useful also for
randomized displays, but that's about it. And I'm not sure what an
engine could provide here that a library couldn't - you can't really
get much faster than what's
To clear things out, I don't mean any changes to the actual Date time of
Javascript. What I want to discuss about is a problem with a very simple
solution.
Issue: Since Javascript code is mainly executed on a device that you might
not have access to timezone and time settings that would be very h
I don't think there's such a thing as "real random" in digital algos, just
"pseudo random".
Apart from card games, what's the use case?
(I'm not in TC39 so I can't vote on this)
I think that this comes after `toObject(keyCallback)`, `takeWhile`,
`skipWhile`, and `forEachReturningOriginalArray` i
Hey all!
Though this proposal was created more than five years ago, it's still
something that should be standardized.
As the algorithm is known and an implementation wouldn't take ages,
bringing in Array.prototype.shuffle is a low-hanging fruit.
Furthermore, it helps to provide a "real" ran
One good area where you don't want heavy streams is in memory-constrained
devices. Also, streams are inherently very OS-dependent, but
hardware-independent, and they aren't very broadly useful.
I'd like this to be solved cohesively out of spec first, given the half
dozen or so existing formalisms.
20 matches
Mail list logo
