[GRASS-dev] r.random still broken on Mac

r.random is broken on the Mac at least. It jams all the points into the top edge of the screen instead of actually randomly distributing them. I thought this was fixed months back. If it was, it’s broken again and needs to be fixed for GRASS 6.2.

This happens with both vector and raster points, and both from the GUI and command line.

Michael


Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Hi,

just testing out r.random using the latest 6.3-cvs. (works fine on Linux)

some parser problems:

--o doesn't work

without "--verbose" there are no newlines in the console output!

G63> r.random in=elevation.dem raster_output=rand_test n=1000
Collecting Stats ... Writing raster file [rand_test] ... G63>

G63> r.random in=elevation.dem raster_output=rand_test n=1000 --o
Collecting Stats ... ERROR: r.random: Output raster <rand_test> exists!
G63>

G63> g.gisenv get="OVERWRITE"
0

G63> r.random in=elevation.dem raster_output=rand_test2 n=1000 --v
Collecting Stats ... 100%
Writing raster file [rand_test2] ... 100%
G63>

?

thanks,
Hamish

Works good on x86 GNU/Linux. (Ubuntu Edgy, GRASS 6.2.0RC1)

Maris.

On Thursday 28 September 2006 00:26, Michael Barton wrote:

r.random is broken on the Mac at least. It jams all the points into the top
edge of the screen instead of actually randomly distributing them. I
thought this was fixed months back. If it was, it¹s broken again and needs
to be fixed for GRASS 6.2.

This happens with both vector and raster points, and both from the GUI and
command line.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

hi hamish,

On Thu, Sep 28, 2006 at 06:26:54PM +1200, Hamish wrote:

Hi,

G63> r.random in=elevation.dem raster_output=rand_test n=1000
Collecting Stats ... Writing raster file [rand_test] ... G63>

G63> r.random in=elevation.dem raster_output=rand_test n=1000 --o
Collecting Stats ... ERROR: r.random: Output raster <rand_test> exists!
G63>

G63> g.gisenv get="OVERWRITE"
0

G63> r.random in=elevation.dem raster_output=rand_test2 n=1000 --v
Collecting Stats ... 100%
Writing raster file [rand_test2] ... 100%
G63>

?

thanks,
Hamish

yes, that mostly happens, when do modules use something like

    fprintf(stderr,"raster processing ... ");
    G_percent();

we are slowly walking all modules through and replacing such
constructions for G_message();

jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

Michael Barton wrote:

r.random is broken on the Mac at least. It jams all the points into the top
edge of the screen instead of actually randomly distributing them. I thought
this was fixed months back. If it was, it¹s broken again and needs to be
fixed for GRASS 6.2.

This happens with both vector and raster points, and both from the GUI and
command line.

Probably because the "fix" tries to identify specific platforms rather
than testing the HAVE_DRAND48 macro:

  #if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
  #define lrand48() ((long)((double) rand() * (1<<31) / RAND_MAX))
  #define srand48(sv) (srand((unsigned)(sv)))
  #else
  extern long lrand48();
  extern void srand48();
  #endif

I'm guessing that the OSX compiler doesn't define __APPLE__ any more.

In general: platform tests are a bad idea. Test the features which you
actually want to use. If you need a configure test, and don't know how
to write it yourself, make a request to the list.

--
Glynn Clements <glynn@gclements.plus.com>

Right.

I think it is just a Mac issue (maybe Windows too??)

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Māris Nartišs <maris.gis@gmail.com>
Date: Thu, 28 Sep 2006 10:09:35 +0300
To: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] r.random still broken on Mac

Works good on x86 GNU/Linux. (Ubuntu Edgy, GRASS 6.2.0RC1)

Maris.

On Thursday 28 September 2006 00:26, Michael Barton wrote:

r.random is broken on the Mac at least. It jams all the points into the top
edge of the screen instead of actually randomly distributing them. I
thought this was fixed months back. If it was, it¹s broken again and needs
to be fixed for GRASS 6.2.

This happens with both vector and raster points, and both from the GUI and
command line.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

__APPLE__ is still around. I don't think it'll go away. Handy little trick I found somewhere:

touch foo.h; cpp -dM foo.h

What was the problem before? is *rand48 broken on OS X? I see in my config.h that HAVE_DRAND48 is defined. Or that having drand48 doesn't mean there is lrand48?

If it's broken, I noticed that r.mapcalc's xrand.c also uses lrand48, but it still tests for HAVE_DRAND48 instead of __APPLE__. And it uses a different define for when HAVE_DRAND48 is not defined.

On Sep 28, 2006, at 12:20 PM, Glynn Clements wrote:

Michael Barton wrote:

r.random is broken on the Mac at least. It jams all the points into the top
edge of the screen instead of actually randomly distributing them. I thought
this was fixed months back. If it was, it¹s broken again and needs to be
fixed for GRASS 6.2.

This happens with both vector and raster points, and both from the GUI and
command line.

Probably because the "fix" tries to identify specific platforms rather
than testing the HAVE_DRAND48 macro:

  #if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
  #define lrand48() ((long)((double) rand() * (1<<31) / RAND_MAX))
  #define srand48(sv) (srand((unsigned)(sv)))
  #else
  extern long lrand48();
  extern void srand48();
  #endif

I'm guessing that the OSX compiler doesn't define __APPLE__ any more.

In general: platform tests are a bad idea. Test the features which you
actually want to use. If you need a configure test, and don't know how
to write it yourself, make a request to the list.

--
Glynn Clements <glynn@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

I just did a quick test - removed __APPLE__ from r.random, so it uses the extern lrand48. I now get a random distribution.

On Sep 28, 2006, at 12:58 PM, William Kyngesburye wrote:

__APPLE__ is still around. I don't think it'll go away. Handy little trick I found somewhere:

touch foo.h; cpp -dM foo.h

What was the problem before? is *rand48 broken on OS X? I see in my config.h that HAVE_DRAND48 is defined. Or that having drand48 doesn't mean there is lrand48?

If it's broken, I noticed that r.mapcalc's xrand.c also uses lrand48, but it still tests for HAVE_DRAND48 instead of __APPLE__. And it uses a different define for when HAVE_DRAND48 is not defined.

On Sep 28, 2006, at 12:20 PM, Glynn Clements wrote:

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

Thanks!

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Thu, 28 Sep 2006 13:41:07 -0500
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Michael Barton <michael.barton@asu.edu>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] r.random still broken on Mac

I just did a quick test - removed __APPLE__ from r.random, so it uses
the extern lrand48. I now get a random distribution.

On Sep 28, 2006, at 12:58 PM, William Kyngesburye wrote:

__APPLE__ is still around. I don't think it'll go away. Handy
little trick I found somewhere:

touch foo.h; cpp -dM foo.h

What was the problem before? is *rand48 broken on OS X? I see in
my config.h that HAVE_DRAND48 is defined. Or that having drand48
doesn't mean there is lrand48?

If it's broken, I noticed that r.mapcalc's xrand.c also uses
lrand48, but it still tests for HAVE_DRAND48 instead of __APPLE__.
And it uses a different define for when HAVE_DRAND48 is not defined.

On Sep 28, 2006, at 12:20 PM, Glynn Clements wrote:

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

I found this __APPLE__ test for *rand48 in:

r.random
v.kcv
v.random

For the Mac builds, I can try to get these rebuilt and online Fri morning, but after that, the next 2 weeks I'm on vacation/traveling and will have minimal internet access.

On Sep 28, 2006, at 10:46 PM, Michael Barton wrote:

Thanks!

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Thu, 28 Sep 2006 13:41:07 -0500
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Michael Barton <michael.barton@asu.edu>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] r.random still broken on Mac

I just did a quick test - removed __APPLE__ from r.random, so it uses
the extern lrand48. I now get a random distribution.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect

William Kyngesburye wrote:

I just did a quick test - removed __APPLE__ from r.random, so it uses
the extern lrand48. I now get a random distribution.

So it's the fake lrand48() that's causing problems?

Doh.

#define lrand48() ((long)((double) rand() * (1<<31) / RAND_MAX))

This produces the correct range, but if RAND_MAX is too small, the
bottom bits will all be zero. The result is actually used as:

            if (make_rand() % nc < nt)

so it's the bottom bits which are the most relevant.

Can you try this instead:

#define lrand48() (((long) rand() ^ ((long) rand() << 16)) & 0x7FFFFFFF)

--
Glynn Clements <glynn@gclements.plus.com>

On Sep 30, 2006, at 2:46 AM, Glynn Clements wrote:

William Kyngesburye wrote:

I just did a quick test - removed APPLE from r.random, so it uses
the extern lrand48. I now get a random distribution.

So it’s the fake lrand48() that’s causing problems?

Doh.

Can you try this instead:

#define lrand48() (((long) rand() ^ ((long) rand() << 16)) & 0x7FFFFFFF)

That works.

So, was there some other reason to use the fake lrand48() on OS X, since the real one seems to work?


William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence…

  • the wisdom of Tarzan

William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.

William Kyngesburye wrote:

>> I just did a quick test - removed __APPLE__ from r.random, so it uses
>> the extern lrand48. I now get a random distribution.
>
> So it's the fake lrand48() that's causing problems?
>
> Doh.
>
...

> Can you try this instead:
>
> #define lrand48() (((long) rand() ^ ((long) rand() << 16)) & 0x7FFFFFFF)
>
That works.

OK, I'll use that as the fallback.

So, was there some other reason to use the fake lrand48() on OS X,
since the real one seems to work?

Presumably it wasn't always available. It was originally only used for
Cygwin, but OSX was added in:

  revision 1.2
  date: 2000/12/11 13:35:14; author: markus; state: Exp; lines: +1 -1
  added MacOS X/drand sensivity

This was then followed by changes to the name of the macro:

  revision 1.3
  date: 2000/12/12 09:02:19; author: markus; state: Exp; lines: +1 -1
  changed __MAC_OS_X__ to __MAC_OS (next try)

  revision 1.4
  date: 2001/01/26 12:45:43; author: markus; state: Exp; lines: +1 -1
  changed defined(__MAC_OS_X__) to defined(__APPLE__)

Also, note that lrand48() isn't available if you use -ansi unless you
specifically enable it with e.g. -D_SVID_SOURCE or -D_XOPEN_SOURCE.
This is part of the reason why platform tests should be avoided.

--
Glynn Clements <glynn@gclements.plus.com>