AltME groups: search

I guess, we can think of it this way: some values like 0.1 to computer 
floating-point system is like square-root 2 or pi to our human base-ten 
system.

A long time ago, I remember reading something where the author suggested, 
as a shared seed, using a substring of PI.

output res should be at 600dpi.  the trick is to find a print shop 
which has a large-print printer with enough ram in its module... 
most shops top out at 2-3m

Hi, did somebody also notice the speed difference between Vista and 
7 as below?

Benchmark run 27-Aug-2009/16:16:06+2:00. Rebol 2.7.6.3.1
Computer: 100Mega Athlon II X2 250/4G DDR3
OS: Windows Vista 64
Precision: 0.05
Empty block: 104000000.0Hz

Eratosthenes Sieve Prime (size: 8191): 54.0Hz, result: 1899 primes
Four-Banger test (+,-,*,/): 150000.0Hz, result: 10.0

Integral (icount: 10000) of sin(x) 0<=x<=pi/2: 42.7Hz, result: 1.00000000000003

Integral (icount: 10000) of exp(x) 0<=x<=1: 60.2Hz, result: 1.71828182845896
Merge Sort (500 elements): 68.4Hz

Benchmark run 4-Oct-2010/17:00:19+2:00. Rebol 2.7.7.3.1
Computer: 100Mega Athlon II X2 250/4G DDR 3
OS: Windows 7 Professional 64-bit
Precision: 0.05
Empty block: 131000000.0Hz

Eratosthenes Sieve Prime (size: 8191): 69.0Hz, result: 1899 primes
Four-Banger test (+,-,*,/): 188000.0Hz, result: 10.0

Integral (icount: 10000) of sin(x) 0<=x<=pi/2: 49.7Hz, result: 1.00000000000003

Integral (icount: 10000) of exp(x) 0<=x<=1: 74.8Hz, result: 1.71828182845896
Merge Sort (500 elements): 90.4Hz

Benchmark run 4-Oct-2010/17:05:53+2:00. Rebol 2.7.6.3.1
Computer: 100Mega Athlon II 250/4G DDR 3
OS: Windows 7 Professional 64-bit
Precision: 0.05
Empty block: 129000000.0Hz

Eratosthenes Sieve Prime (size: 8191): 71.4Hz, result: 1899 primes
Four-Banger test (+,-,*,/): 188000.0Hz, result: 10.0

Integral (icount: 10000) of sin(x) 0<=x<=pi/2: 51.3Hz, result: 1.00000000000003

Integral (icount: 10000) of exp(x) 0<=x<=1: 75.5Hz, result: 1.71828182845896
Merge Sort (500 elements): 92.5Hz

Maybe refinements for functions are more clear with examples like 
this: Let's say, we want a sine function, which default operate with 
radians, but you can give degrees refinement, if you like, exactly 
opposite of the normal SINE function:


>> sin: func [value /deg] [either deg [sine value] [sine/radians 
value]]
>> sin pi / 6
== 0.5
>> sin/deg 30
== 0.5

New version 0.1.0 of BBC BASIC. Added FOR ... NEXT loop. Example:

>> do http://www.fys.ku.dk/~niclasen/rebol/bbcbasic.r
connecting to: www.fys.ku.dk
Script: "BBC BASIC" (19-Jul-2007)
BASIC v. 0.1.0 

>auto
   10 for a=10 to pi step -2.3
   20 for n%=1 to 3 step 2
   30 print a n%
   40 next
   50 next
   60 0
>run
                  10                   1
                  10                   3
                 7.7                   1
                 7.7                   3
                 5.4                   1
                 5.4                   3

Ashley;  Well I'm more confused than when I started.  I got sick 
of bad Courier and fixed it.  It had to do with the order of 100dpi 
and 75dpi font lists and removing ghostscript font mapping.  Anyway, 
now REBOL/View can't find Serif, Sans Serif or Monospace.  The "real" 
names "DejaVu Serif", "DejaVu Sans", and "DejaVu Sans Mono" work 
in font [name: ] blocks.  So, I can't help much yet.

The short list (and I'll need to look into this more)  is
DejaVu Sans Mono
  for a good font-fixed
DejaVu Serif
 for a good font-serif
DejaVu Sans
 for a good font-sans-serif
These names may be very specific to my setup...not sure yet.


These fonts should map to "Monospace" "Serif" "Sans Serif", which 
I just broke.


And after I mucked around   the stock font names, which on this REBOL/View 
 2.7.5.4.2 18-Mar map to

font-fixed = "courier"  font-serif = "times"  and font-sans-serif 
= "helvetica", all look way better now.


Maybe I'll just let you get on with it, and quit mudding the waters 
 :)

As far i am, i made some useful tiny mezz, perhaps some could be 
in R3.

reuse: funco [b [block!]][head reduce/into b clear []]

** REUSE, reduce a block, but re-use always the same block 

** Actually, 3 time slower than a reduce block, but save memory and 
GC recycles if used massivly.
** I use it to pass small blocks of coordinates.

mulm: func [

 {multiply a matrix [a b c d e f] by coordinates x y, return coordinates 
 [x' y']}
	x y m [block!]
][
	reuse [x * m/1 + (y * m/3) + m/5 x * m/2 + (y * m/4) + m/6]
]

atan2: func [

 {Angle of the vector (0,0)-(x,y) with arctangent y / x. The resulting 
 angle is extended to -pi,+pi}
	x y
][
	if x = 0 [x: 0.0000000001]
	add arctangent y / x pick [0 180] x > 0
]

Project: func [

 {orthogonal projection of a point P on a line AB, return coordinates 
 [x y]}
	ax ay bx by px py
	/local sx sy ux uy ratio
][
	sx: bx - ax
	sy: by - ay
	ux: px - ax
	uy: py - ay
	ratio:  sx * ux + (sy * uy) / (sx * sx + (sy * sy))
	reuse [ratio * sx + ax  ratio * sy + ay]
]


vector-length: func [x1 y1 x2 y2][square-root add x2 - x1 ** 2 y2 
- y1  ** 2]

>> time [loop 1000000 [pi ** 2]]
== 0:00:00.468

How could I generate a random number (a real number) between 2 given 
values, ie between -pi and pi ?

random pi gives me an integer

Now divide by max-decimal (whatever that is) and multiply by desired 
range (eg. pi).

You asked how to make a random number between e.g. pi and -pi. There 
are a number of ULPs (Unit in the Last Place) between those two numbers. 
For 64 bit decimals, it's a large number. The possible decimals in 
computer arithmetic lie closer together around zero than for large 
numbers. If you had a routine, that would give you any possible 64 
bit decimal number between pi and -pi with equal probability, then 
you would get a lot more numbers close to zero than close to either 
pi or -pi. The distribution wouldn't be flat (as you would expect).


It's much better to choose, how many different values between pi 
and -pi, you need, and then make a random integer of that number, 
and do some calc to get the result between pi and -pi.

I hope, it makes sense.

rc: rebcode[][
	setd pi 3.14159265358979
	print pi
	setd freq pi
	print freq
]

will print out ?unset? instead of freq == pi

rc: rebcode[][
print pi
	setd pi 3.14159265358979
	print pi
set freq 0.0
	setd freq pi
	print freq
]
rc

pi is already a decimal..

and a radian is pi / 2, right ?

2 * pi

some example code (in C, but easy to rewrite):

float a = 2.f*(float)sin(Pi*frequency/samplerate);

float s[2];

s[0] = 0.5f;
s[1] = 0.f;

loop:
s[0] = s[0] - a*s[1];
s[1] = s[1] + a*s[0];
output_sine = s[0];
output_cosine = s[1]

The battle is shifting beyond Windows and Linux," he says. "Google 
isn't concerned about what executes down on the client machine, whether 
it's Windows or Linux. The action has moved up a level. The real 
innovation in software is not occurring in the context of the 1980s 
and 1990s PC. It's occurring in applications that reside in the broader 
Web. The interesting innovations are going to occur around different 
ways to organize and share and access information."" -- Paul Maritz 
(once 3rd in comand at Microsoft) regarding his new venture.. PI 
 http://www.forbes.com/technology/2006/06/23/linux_vista_open_cz_dl_0623linux.html

Raspberry Pi computer:

	http://www.youtube.com/watch?v=pQ7N4rycsy4
	http://www.raspberrypi.org/

Raspberry Pi runs Quake 3:

http://www.youtube.com/watch?v=e_mDuJuvZjI

Let's see another example with the extra block:
f: closure [x /local a]Ê[a: 2 * pi] [(sine/radians x) / a]

without:
f: closure [x /local a] [a: 2 * pi (sine/radians x) / a]


Is it something like this, you're thinking about? And will the first 
be faster than the second?

And the third possibility (which maybe not is very REBOLish):
f: closure [x /local a: 2 * pi] [(sine/radians x) / a]

What is the speed of this compared to using closure (with the extra 
block):
o: context [a: 2 * pi f: closure [x] [(sine/radians x) / a]]
And then call it by: o/f 1

Geomol: my guess is, that if you wrote: context [a: 1 / 2 / pi set 
'f closure [x] [a * sine/radians x]], you wouldn't be slower than 
the initialization block can be while retaining the "static nature" 
of the defined variables, that can be even changed when wanted

When investigating the creation of a MAP function in REBOL 2, I found 
that sending functions with refinement to map required some extra 
work (the need for a DO). The rules about get-words as arguments 
has changed in REBOL 3. Maybe I should talk to Carl about it, but 
I could discuss it with you guys first to not disturb Carl too much. 
First a REBOL 2 version of MAP, that can't cope with refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]


f is the function, l the list and r the result. i is an item in the 
list. The critical part is

append r f i


The function f is evaluated taking the argument i. Easy to read and 
understand. But it can't cope with refinements, which are seen as 
the path! datatype. Example:

>> map sine/radians reduce [0 pi / 6 pi / 2]
== [sine radians sine radians sine radians]


This can be fixed by putting a DO before f. Now it works both with 
and without refinements:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

In REBOL 3, the function is not evaluated:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r f 
i] r]
>> map sine [0 30 90]
== [sine sine sine]

Including DO just makes it worse:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
f i] r]
>> map sine [0 30 90]
== [make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]] make native! [[
        "Returns the trigonometric sine."
        value [number!] "In degrees by default"
        /radians "Value is specified in radians"
    ]]]

To make map behave correctly, I have to do something like:


>> map: func [:f l /local r] [r: clear [] foreach i l [append r do 
reduce [f i]] r]
>> map sine [0 30 90]
== [0.0 0.5 1.0]
>> map sine/radians reduce [0 pi / 6 pi / 2]
== [0.0 0.5 1.0]

Is this ok and accepted behaviour? Will it break many scripts?
(Sorry for the long post, but I wanted to be precise.)

I realize these are decimal aproximations (at least on the 32 bit 
machine) 
but rebols mod function returns decimals
for example mod (PI + 50.0) 10 .  

why would these aproximated large values not come back as their nearest 
decimal aproximations if t

Another thing, we have pi:

>> pi
== 3.14159265358979

Would it be an idea to have e equal to:

>> exp 1
== 2.71828182845905

I mean, we can create pi ourselves with

arccosine/radians -1

, so why is pi there? And if it is, why isn't e there?

Ah, but "float" is a keyword for programmers that implies binary 
floating-point numbers (usually IEEE754), while "real" is a keyword 
for what floating point numbers (binary or decimal) *appproximate*. 
You know, the real world. The "real" pi doesn't have a finite binary 
representation. That distinction is why I like "float" instead. All 
moot now though - we are stuck with decimal!.

Maxim: "what's the best way to convert a hex string to a decimal 
value in R3?" - Try this:
>> pi
== 3.14159265358979
>> enbase/base to-binary pi 16
== "400921FB54442D18"
>> to-decimal debase/base "400921FB54442D18" 16
== 3.14159265358979
>> to-decimal debase/base enbase/base to-binary pi 16 16
== 3.14159265358979


You asked for the best way: No method that uses the issue! type for 
binary conversions could be considered the best way.

if it's for storing usage, then restoring, perhaps the base 64 format 
is enough.

>> enbase to-binary pi
== "QAkh+1RELRg="

>> to-decimal debase enbase to-binary pi
== 3.14159265358979

300dpi = 300 ticks in an inch.  if you know the printer edges to 
be 1/2 inch, then you can juste calculate a 2250 wide bitmap (using 
US letter size paper)  and send it .  this works.  simple math .

Graham, Postscript is resolution independant. Certainly capable of 
more than 72dpi

Graham, what I meant is that even to the unit is a *point* the fact 
is that you can more than 72 pixels in a inch. For example laserprinters 
have 300 to 1200. And there is some displays that 96dpi, and I have 
seem e-ink that gives you 150dpi(s).

Found 2 versions in my scripts.
atan2: func [

 {Angle of the vector (0,0)-(x,y) with artangent y / x. The resulting 
 angle is extended to -pi,+pi}
	x y
][
	if x = 0 [x: 0.0000000001]
	add arctangent y / x pick [0 180] x > 0
]

atan2: func [x y][
	x: x + 0.00000001
	either x > 0 [
		arctangent y / x
	][
		180 + arctangent y / x
	]
]

Well, I am not doing the ARM port only for Android, I target also 
iOS and some embedded boards (like e.g. the Raspberry Pi).

Float support so far:

---
Red/System [ ]

#import [
	LIBC-file cdecl [
		cos: "cos" [
			x 		[float!]
			return: [float!]
		]
	]
]

pi: 3.14159265358979
printf ["%.14f" cos pi]
---

outputs: -1.00000000000000

This code will cause an access violation as clock in libc returns 
an integer not a pointer to an integer.

pi: declare pointer! [integer!] 
#import [
	LIBC-FILE cdecl [
	  read-cpu-clock: "clock" [
	    return:    [pointer! [integer!]]
	  ]
    ]
]
pi: read-cpu-clock
pi/value

Raspberry Pi got Fedora Remix yesterday. Can't wait for the release, 
and getting Red running there :-)