headers
anonymous | 16 Mar 2007 08:15
Picon

[sr #105800] Random number generator builtin


URL:
  <http://savannah.gnu.org/support/?105800>

                 Summary: Random number generator builtin
                 Project: GNU M4
            Submitted by: None
            Submitted on: Friday 03/16/2007 at 07:15 UTC
                Category: None
                Priority: 5 - Normal
                Severity: 1 - Wish
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: alexander.garaga <at> intel.com
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

m4 lacks a random number generator builtin. I think it would be great if such
builtin existed. Currently I use something like:
dnl random(num): Evaluates to a random number from range 0..num-1.
define([random],[eval(esyscmd(printf $RANDOM) % $1)])dnl

    _______________________________________________________
(Continue reading)

Permalink | Reply | 502 comments |
headers
Eric Blake | 24 Mar 2007 22:39
Picon

[sr #105800] Random number generator builtin


Follow-up Comment #1, sr #105800 (project m4):

The idea sounds useful; I'll probably add something along these lines closer
to when M4 2.0 is released.  But the nice part about CVS head (the eventual
M4 2.0) is that you can write your own m4 builtins as a dynamic library, and
extend the power of the m4 language without having to wait for the next
release to implement something as a builtin.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?105800>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 502 comments |
headers
anonymous | 26 Mar 2007 07:11
Picon

[sr #105800] Random number generator builtin


Additional Item Attachment, sr #105800 (project m4):

File name: builtin.c                      Size:57 KB

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?105800>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 4 comments |
headers
Eric Blake | 26 Mar 2007 16:20
Picon

[sr #105800] Random number generator builtin


Follow-up Comment #2, sr #105800 (project m4):

It's too late to add a new feature to the 1.4.x series (which is supposed to
be stable).  Dynamic modules indeed require 2.0 support (well, 1.9x, since
2.0 isn't released yet).  Would you be willing to assign copyright for your
contribution?  Otherwise, I will have to reimplement the suggestion from
scratch rather than relying on your preliminary work (not that I mind, it
just means it will take longer).  Also, in general, it is better to generate
a 'diff -u' style patch, rather than to attach the entire contents of the
changed file; and preferably make the patch against CVS head rather than a
release version, since the file may have changed in CVS since a prior
release.  For that matter, patches are more frequently discussed on the
m4-patches mailing list than on savannah.  Also, any new builtin also
requires documentation and NEWS patches, as well as testsuite additions that
exercise the new builtin.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?105800>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 3 comments |
headers
Eric Blake | 26 Mar 2007 18:06
Picon

[sr #105800] Random number generator builtin


Follow-up Comment #3, sr #105800 (project m4):

By the way, m4 1.4.x already has a pseudo-random generator: mkstemp (or
maketemp, if you want to be portable to 1.4.7 and earlier).  A bit gross, but
you could use something along these lines rather than relying on the bash
extension of $RANDOM that is not in all versions of /bin/sh; unfortunately it
does not reduce the number of forks, and generates only 31 bits (well, 36^6
rather than 2^31) of randomness:

dnl random(num): Evaluates to an unevenly distributed random number from
range 0..num-1
define([random],
[pushdef([_], mkstemp([0XXXXXX]))dnl
syscmd([rm ]_)dnl
eval([0r36:]_[ % $1]popdef([_]))])

To be a good random number generator, though, you need an even distribution. 
Your approach with printf $RANDOM, as well as my approach above, fails that
criteria when you take a modulus that is relatively prime to the number of
psuedo-random inputs.  Any good solution that provides random as a builtin
must make sure that the resulting distribution is evenly distributed.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?105800>

_______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alexander | 27 Mar 2007 13:21
Picon

[sr #105800] Random number generator builtin


Follow-up Comment #4, sr #105800 (project m4):

This solution sometimes gives negative numbers.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?105800>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 1 comment |
headers
Eric Blake | 27 Mar 2007 14:06
Picon

[sr #105800] Random number generator builtin


Follow-up Comment #5, sr #105800 (project m4):

I never claimed it was perfect :)  Besides, a random number generator that
depends on the contents of your disk and creates files in the process is
rather weak; I only listed the idea for completeness of what m4 1.4.x already
provides.

But yes, to avoid negative numbers, since m4's eval is signed, you would need
to add &0x7fffffff in the mix.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?105800>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 0 comments |
headers
Gary V. Vaughan | 28 Mar 2007 18:47
Picon
Gravatar

seekable stdin test failure on OS X

$ make check TESTSUITEFLAGS='-v 68'
[[...]]
## ----------------------- ##
## GNU M4 1.9a test suite. ##
## ----------------------- ##
68. others.at:458: testing ...
../../tests/others.at:467: m4 -b -d  < in.m4
--- -   2007-03-28 17:36:35.000000000 +0100
+++ /Users/gary/Devo/Source/m4--devo--0/+build/tests/testsuite.dir/at- 
stdout   2007-03-28 17:36:35.000000000 +0100
 <at>  <at>  -1,2 +1  <at>  <at> 
-m4exit(15)
../../tests/others.at:467: exit code was 15, expected 0
68. others.at:458:  FAILED (others.at:467)

## ------------- ##
## Test results. ##
## ------------- ##

ERROR: 1 test was run,
1 failed unexpectedly.

I don't know what is being tested here, so I can't debug any further.

Cheers,
	Gary
--

-- 
   ())_.              Email me: gary <at> gnu.org
   ( '/           Read my blog: http://blog.azazil.net
   / )=         ...and my book: http://sources.redhat.com/autobook
(Continue reading)

Permalink | Reply | 41 comments |
headers
blp | 29 Mar 2007 05:37
Picon

Re: undefined macro

On Wed, Mar 28, 2007 at 04:08:30PM -0400, Jason Stover wrote:

> make -f Smake is failing to expand AM_INTL_SUBDIR.  I've been
> struggling with this problem for a while now.  My lack of
> understanding of aclocal and autoconf is hindering progress.

Jason kindly gave me a login on the system that was exhibiting
the problem.  I think I tracked down the problem.  My analysis
follows.

AM_GNU_GETTEXT does the following, in part:

  define([gt_included_intl],
    ifelse([$1], [external],
      ifdef([AM_GNU_GETTEXT_][INTL_SUBDIR], [yes], [no]),
      [yes]))
...
  ifelse(gt_included_intl, yes, [
    AC_REQUIRE([AM_INTL_SUBDIR])dnl
  ])

Thus, if AM_GNU_GETTEXT is passed "external" as its first
argument, and AM_GNU_GETTEXT_INTL_SUBDIR is defined, then
gt_included_intl will be set to "yes" and AM_INTL_SUBDIR will be
invoked.  Nothing in PSPP causes AM_GNU_GETTEXT_INTL_SUBDIR to be
defined, so AM_INTL_SUBDIR should not be invoked.  Yet some
testing revealed that the ifdef was taking the "yes" path.

I eventually figured out that the trace on
AM_GNU_GETTEXT_INTL_SUBDIR was causing m4 to think that it was
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ralf Wildenhues | 30 Mar 2007 00:04
Picon
Picon

Re: undefined macro

Hello Ben,

* blp <at> gnu.org wrote on Thu, Mar 29, 2007 at 05:37:20AM CEST:
> 
> Jason kindly gave me a login on the system that was exhibiting
> the problem.  I think I tracked down the problem.  My analysis
> follows.

I'm sorry that you had to do it for this known bug.  I guess I should
have written more clearly in my earlier response.

> Conclusions:
> 
> 1. Jason: I think you can fix the problem by upgrading to the
>    latest version of GNU m4.

ACK.

> 2. I don't understand why m4 behavior changed.  It doesn't seem
>    to be mentioned explicitly anywhere in NEWS.  I guess it must
>    be related to this item for version 1.4.4b, though:

Yes.

> 3. It seems that Autoconf should more strongly recommend, or even
>    test for and require, a recent version of m4, since older
>    versions can cause such bizarre, difficult-to-debug problems.

Yes, in response to a couple of reports about this bug, CVS Autoconf 
now has this NEWS entry:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane