Re: [rng] Split and Jump functions
Hello Alex.
>>> [...]
>
> OK so this results in:
>
> /**
> * Some summary.
> */
> public interface JumpableUniformRandomProvider extends
> UniformRandomProvider {
> /**
> * Creates a copy of the UniformRandomProvider and advances the
> state of the copy.
> * The state of the current instance is not altered. The state of
> the copy will be
> * advanced an equivalent of {@code n} sequential calls to a method
> that updates the
> * state of the provider.
> *
> * @return the copy with an advanced state
> */
> JumpableUniformRandomProvider jump();
> }
>
+1
[Clean and lean: and no side-effects to explain...]
>
> This can be documented in an implementation as:
>
> public class MyJumpingRNG implements JumpableUniformRandomProvider {
> /**
> * {@inheritDoc}
> *
> * The jump size {@code n} is the equivalent of {@code 2^64}
> calls to
> * {@link UniformRandomProvider#nextLong() nextLong()}.
> */
> @Override
> public JumpableUniformRandomProvider jump() {
> // TODO Auto-generated method stub
> return null;
> }
> }
+1
>
> Do we add a second interface for LongJumpableUniformRandomProvider?
Sure, if the functionality is provided by some of the algorithms implemented
in [RNG].
But let's have the two functionalities in separate commits.
>
> >> So the options are (in all cases returning the copy):
> >>
> >> 1. createAndJumpCopy
> >> 2. copyAndJumpParent
> >> 3. jumpParentAndCopy
> >> 4. jump and copy separately
> >>
> >> 1. Your preferred option. A copy of the state is made. The state is
> >> advanced in the copy and returned. But when called repeatedly it will get
> >> the same generator and code must be organised appropriately.
> > We could provide a convenience method in "RandomSource":
> >
> > public UniformRandomProvider[] jump(int n,
> > JumpableUniformRandomProvider parent) {
> > final UniformRandomProvider[] rngs = new UniformRandomProvider[n];
> > UniformRandomProvider tmp = parent;
> > for (int i = 0; i < n; i++) {
> > rngs[i] = restrict(tmp);
> > tmp = tmp.jump();
> > }
> > return rngs;
> > }
>
> +1. Remove the need for the user to repeat boiler plate code.
>
> Same sort of idea of longJump() too.
+1
> >> It is not actually possible to jump forward a single instance. Only
> >> children are advanced.
> > A feature: There is only one way to alter the state of an instance
> > (i.e. a call to "next()").
> OK.
Great. :-)
Gilles
> >
>>> [...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
status and release of commons-scxml-2.0?
Hi developers/community, I've received an out-of-band request about the current status of commons-scxml-2.0 and its release schedule. As there might be more (hopefully at least a few) people interested in this, and I don't like answering out-of-band questions, I'm giving a heads-up here for the whole community. To be absolutely clear upfront: I've dropped the ball on this (again) since my last burst of changes early 2018. I simply didn't, and still don't, have the cycles and priority to work on this beyond maybe minimally answering a few questions now and then. Now, there have been only very few questions in the last several years, and luckily Woonsan (who is a remote colleague of mine in our d2d job) stepped in to help with those as well. So practically, there hasn't been much demand or pressure to wrap-up the work and finish the 2.0 release. And neither from my d2d job (we're still happily using the 2.0-M1 release without problems so far). But technically, the current master branch towards the 2.0 release *is* practically done and ready to be tagged and released. If/when a few remaining cleanup and polishing tasks are completed... The current master branch *is* already fully compliant with the W3C SCXML 1.0 specification, including passing all the W3C (IRP) tests for it. At least, when using the jexl or groovy script languages. And the Common SCXML 2.0 engine IMO is pretty cool and convenient to use, for those who like/need a formalized statemachine engine. Only for the javascript language (using Java 8 Nashorn, now deprecated since Java 11...) there are still 3/188 W3C IRP tests failing. And those 3 test failures are really, really difficult to fix, because of limitations/quirks in the Nashorn engine itself. So that is where I got 'stuck'. I honestly lost interest and desire to try fix this, given that Nashorn now is deprecated in Java 11 anyway, I don't think anyone is actually using/waiting for the javascript language support to begin with, and so I rather just/simply rip out the whole javascript language support and be done with it. And then, there is the remaining work to: a) Fix/remove/replace existing documentation, which is still mostly based upon the last 0.9 release from more than a decade ago. To do this properly is/would be a major effort in itself, as the commons-scxml-2.0 API is really, really different now. b) Fix/configure the site generation itself (I'm actually clueless) c) Check/adjust current checkstyle and other build/release reports to be more in line with the common practices for Apache Commons projects? For task a) I assume I'd have to take first responsibility, possible/hopefully with some help from Woonsan, because 80+% of the code and API changes were made by me, the rest by Woonsan. However I honestly don't have the cycles to do this properly right now. But if it is acceptable to only do the bare minimum, and at least remove the out-of-date examples and just have a basic/minimal 'getting started' page, I could pull that off in a few weeks time. For task b) I assume other devs may be able to help out a bit: I just needs some explanation and clarification how this (now) is supposed to work. Lastly, for task c) I don't know what the current/common policy is or should be: the only thing I realized is that the current reporting configuration is extremely old (10+ years) and might need adjusting. I guess this is also something other Commons devs might be able to explain or even help out with? Looking forward to further input, and hopefully some offered help, because I really would like to wrap this up, sometime soon. Regards, Ate - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: status and release of commons-scxml-2.0?
Hi Ate, > On Apr 18, 2019, at 11:23 AM, Ate Douma wrote: > > Only for the javascript language (using Java 8 Nashorn, now deprecated > since Java 11...) there are still 3/188 W3C IRP tests failing. > And those 3 test failures are really, really difficult to fix, because > of limitations/quirks in the Nashorn engine itself. Could you please provide more information on this? Which tests are failing, and what are the limitations and quirks of Nashorn that cause this? Thank you, Jake - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: status and release of commons-scxml-2.0?
Hello Team, I am writing to let you know that like many others I greatly value the work being done on commons-scxml and look forward to release 2.0. Please keep up the good work. Regards, Diptendu Dutta On Thu, Apr 18, 2019 at 9:04 PM Ate Douma wrote: > Hi developers/community, > > I've received an out-of-band request about the current status of > commons-scxml-2.0 and its release schedule. > > As there might be more (hopefully at least a few) people interested in > this, and I don't like answering out-of-band questions, I'm giving > a heads-up here for the whole community. > > To be absolutely clear upfront: I've dropped the ball on this (again) > since my last burst of changes early 2018. > I simply didn't, and still don't, have the cycles and priority to work > on this beyond maybe minimally answering a few questions now and then. > > Now, there have been only very few questions in the last several years, > and luckily Woonsan (who is a remote colleague of mine in our d2d job) > stepped in to help with those as well. > So practically, there hasn't been much demand or pressure to wrap-up > the work and finish the 2.0 release. > And neither from my d2d job (we're still happily using the 2.0-M1 > release without problems so far). > > But technically, the current master branch towards the 2.0 release *is* > practically done and ready to be tagged and released. If/when a few > remaining cleanup and polishing tasks are completed... > > The current master branch *is* already fully compliant with the W3C > SCXML 1.0 specification, including passing all the W3C (IRP) tests for > it. At least, when using the jexl or groovy script languages. > And the Common SCXML 2.0 engine IMO is pretty cool and convenient to > use, for those who like/need a formalized statemachine engine. > > Only for the javascript language (using Java 8 Nashorn, now deprecated > since Java 11...) there are still 3/188 W3C IRP tests failing. > And those 3 test failures are really, really difficult to fix, because > of limitations/quirks in the Nashorn engine itself. > So that is where I got 'stuck'. > I honestly lost interest and desire to try fix this, given that Nashorn > now is deprecated in Java 11 anyway, I don't think anyone is actually > using/waiting for the javascript language support to begin with, and so > I rather just/simply rip out the whole javascript language support and > be done with it. > > And then, there is the remaining work to: > a) Fix/remove/replace existing documentation, which is still mostly > based upon the last 0.9 release from more than a decade ago. > To do this properly is/would be a major effort in itself, as the > commons-scxml-2.0 API is really, really different now. > b) Fix/configure the site generation itself (I'm actually clueless) > c) Check/adjust current checkstyle and other build/release reports to be > more in line with the common practices for Apache Commons projects? > > For task a) I assume I'd have to take first responsibility, > possible/hopefully with some help from Woonsan, because 80+% of the code > and API changes were made by me, the rest by Woonsan. > However I honestly don't have the cycles to do this properly right now. > But if it is acceptable to only do the bare minimum, and at least remove > the out-of-date examples and just have a basic/minimal 'getting > started' page, I could pull that off in a few weeks time. > > For task b) I assume other devs may be able to help out a bit: I just > needs some explanation and clarification how this (now) is supposed to > work. > > Lastly, for task c) I don't know what the current/common policy is or > should be: the only thing I realized is that the current reporting > configuration is extremely old (10+ years) and might need adjusting. > I guess this is also something other Commons devs might be able to > explain or even help out with? > > Looking forward to further input, and hopefully some offered help, > because I really would like to wrap this up, sometime soon. > > Regards, > Ate > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > >
Re: status and release of commons-scxml-2.0?
On 18/04/2019 18.00, Jacob Beard wrote:
Hi Ate,
On Apr 18, 2019, at 11:23 AM, Ate Douma wrote:
Only for the javascript language (using Java 8 Nashorn, now deprecated
since Java 11...) there are still 3/188 W3C IRP tests failing.
And those 3 test failures are really, really difficult to fix, because
of limitations/quirks in the Nashorn engine itself.
Could you please provide more information on this? Which tests are failing, and
what are the limitations and quirks of Nashorn that cause this?
Sure.
Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
that the Nashorn engine by default doesn't fail on referencing a missing
property. Which is tested by W3C IRP test 307.
Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
which make use of XML DOM APIs in a condition, like:
cond="var1.getElementsByTagName('book')[0].getAttribute('title') ==
'title1'"
However Nashorn doesn't provide default/native XML DOM support, and
adding that would be (at least from my perspective) quite an effort, if
even properly doable.
That doesn't feel like worth the effort, with little added value/ROI.
[1] https://issues.apache.org/jira/browse/SCXML-273
Thank you,
Jake
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] Split and Jump functions
> On 18 Apr 2019, at 14:12, Gilles Sadowski wrote:
>
> Hello Alex.
>
[...]
>>
>> OK so this results in:
>>
>> /**
>> * Some summary.
>> */
>> public interface JumpableUniformRandomProvider extends
>> UniformRandomProvider {
>> /**
>> * Creates a copy of the UniformRandomProvider and advances the
>> state of the copy.
>> * The state of the current instance is not altered. The state of
>> the copy will be
>> * advanced an equivalent of {@code n} sequential calls to a method
>> that updates the
>> * state of the provider.
>> *
>> * @return the copy with an advanced state
>> */
>> JumpableUniformRandomProvider jump();
>> }
>>
>
> +1
> [Clean and lean: and no side-effects to explain...]
>
>>
>> This can be documented in an implementation as:
>>
>> public class MyJumpingRNG implements JumpableUniformRandomProvider {
>> /**
>> * {@inheritDoc}
>> *
>> * The jump size {@code n} is the equivalent of {@code 2^64}
>> calls to
>> * {@link UniformRandomProvider#nextLong() nextLong()}.
>> */
>> @Override
>> public JumpableUniformRandomProvider jump() {
>> // TODO Auto-generated method stub
>> return null;
>> }
>> }
>
> +1
>
>>
>> Do we add a second interface for LongJumpableUniformRandomProvider?
>
> Sure, if the functionality is provided by some of the algorithms implemented
> in [RNG].
> But let's have the two functionalities in separate commits.
>
>>
So the options are (in all cases returning the copy):
1. createAndJumpCopy
2. copyAndJumpParent
3. jumpParentAndCopy
4. jump and copy separately
1. Your preferred option. A copy of the state is made. The state is
advanced in the copy and returned. But when called repeatedly it will get
the same generator and code must be organised appropriately.
>>> We could provide a convenience method in "RandomSource":
>>>
>>> public UniformRandomProvider[] jump(int n,
>>> JumpableUniformRandomProvider parent) {
>>> final UniformRandomProvider[] rngs = new UniformRandomProvider[n];
>>> UniformRandomProvider tmp = parent;
>>> for (int i = 0; i < n; i++) {
>>> rngs[i] = restrict(tmp);
>>> tmp = tmp.jump();
>>> }
>>> return rngs;
>>> }
>>
>> +1. Remove the need for the user to repeat boiler plate code.
>>
>> Same sort of idea of longJump() too.
>
> +1
>
It is not actually possible to jump forward a single instance. Only
children are advanced.
>>> A feature: There is only one way to alter the state of an instance
>>> (i.e. a call to "next()").
>> OK.
>
> Great. :-)
>
> Gilles
This sounds like a resolution. I will put the ideas into a Jira ticket for
Jumpable.
I am a bit busy at the moment with other mini-projects (updates to nextInt(int)
being the main one, Poisson samplers (again) being another leading to a family
of log normal based distributions that may be supported using cumulative
probability look-up tables) but will hope to get this done soon. The actual
implementation should be quite easy.
Here’s one for you to think about on the subject of Jumpable. What about
support for the generators that can be advanced by a user specified increment?
For example the SplitMix algorithm is based on a sequence and so can be
advanced from 1 to 2^64-1 steps. It does seem strange to support this (if we
add jumpable to SplitMix) using only one specific jump distance. A Skippable
can do this:
SkippableURP {
public SkippableURP skip(long steps);
// or
public SkippableURP skipPower2(long power);
}
Too much?
>
>>>
[...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
