World: r3wp

FORALL rather than FOREACH.

Right, but in some way already covered by an efficient function or 
code pattern.

(If anything.)

Anyone still happens to have R3 A30 binaries? If so, please send 
me a private message.

A109 for Linux has been uploaded.  There was an odd glitch in the 
build that delayed it.

Andreas, A30?

do you have an ETA for A109 host-kit?

I'm about to prepare a package which has a working version of openGL 
in view...

wondering if Its better to wait for A109

I uploaded it for the RMA guys to test out.

ok, so its already done... cool.

The A109 did not focus on host-kit, but on other things... so not 
sure it works. I can give you a copy to try if you want.

yeah, it would be nice, I'll try to update the Custom Gob Rendering 
API to it.

btw have fun at amiwest tomorrow... wish I where there  :-)

www.rebol.com/r3/downloads/r3-host-kit-a109.zip

thx !

so... give it a try, but no promises on this one, not tested

(and perhaps some of the files not quite right either... so, it's 
not official.)

Thanks on AmiWest... my truck is full of really old Amiga stuff to 
take over. Cleaned the basement.

no problem on testing, I'll be diffing it against my modified A107.

Well... hopefully it works. CU later, must go get some sleep.

I can't wait to share the 3d enabled version or R3.... btw, I just 
named my 3d model format...    .R3D    :-)

ciao!

I'm looking forward to it, as I'm sure many others are!

full-screen animation at 10% cpu  ;-)

Carl, a minor glitch in the A109 hostkit, which prevents it from 
compiling with AGG: in reb-lib.h the #ifdef __cplusplus definition 
of RXIEXT is borked.

Should be
#define RXIEXT extern "C" __declspec(dllexport)
instead of
#define extern "C" RXIEXT __declspec(dllexport)
(reb-lib.h, line 68).

Other than that, the hostkit works fine (and hostkit-built binarries 
pass the same number of tests as the RT binaries).

Is this a bug or an expected/justifiable result:
  1x.00000000000000000000000000000000000001
 == 1x9.999999e-39

I thint it may be a specific case of this -- unexpected by me, anyway:
    (second 1x.1) = 0.1
    == false

Ah yes, floating point not being able to represent 0.1 exactly. But 
with the default digits that should work.

The (second 1x.1) <> 0.1 result is caused by:


1) the fact, that binary floating point cannot exactly represent 
1 / 10

2) the fact, that 64-bit IEEE754 (REBOL decimal!) is more accurate 
than 32-bit IEEE754 (REBOL pair coordinate)

Thus, the result is both justifiable, as well as expected.

Thanks, Ladislav.

There are several anomalies, which at least could be noted in the 
documentation under the pair! data type.


Another [anomaly]/[undocumented change from R2 behaviour] is when 
a pair overflows:

....R2 throws an error, or replacee the large number with 0 (itself 
an odd behaviour).

....R3 can generate +/-infinity. As far as I know this is the only 
way in R3 to get a -/-INF; and the value is not usably serialisable:
    xx: as-pair -1e44 1e44
    == -1.#INFx1.#INF
    type? first xx
    == decimal!
    load mold first xx
    ** Syntax error: invalid "integer" -- "-1.#INF"

Thanks, Ladislav.
There are several anomalies, which at least could 
be noted in the documentation under the pair! data type.

Another 
[anomaly]/[undocumented change from R2 behaviour] is when a pair 
overflows:


....or replacee the large number with 0" - which expression do you 
mean?

The infinity may be a problem, but, it looks like a low priority 
issue to me.

I mean sometimes one, sometimes the other:
R2:
>> as-pair 1 1e308
== 1x0
as-pair 1 1e309
** Math Error: Math or number overflow

Thanks, did not notice that

aha, but this behaviour does not have anything in common with pairs, 
in fact

The 1e309 value causes the overflow when loaded

Otherwise, the R2 pairs never overflow, instead they "wrap around"

Thanks for the analysis. I kinda know the reason, but the documentation 
should make the limits clear ro those who do not know (or have not 
thought through the implcations of) the internal representations.

INFs are a low priority.....But they are also an interesting REBOL 
phenomena...Unserialisable values that do not always equal other 
same-sized INFs :)

    xx: array/initial 100 as-pair 1e44  -1e44
    length? unique xx

    == 100   ;; 100 separate infinities ... Cantor would be proud!

    (first xx/1) = (first xx/1)
    == true
    (first xx/1) = (first xx/2)

    == true           ;; or perhaps its just UNIQUE having a bad day

    xx/1 = xx/2     ;; or perhaps not
    == false

To have infinity values would be good, but the current behaviour 
is a bug of course. The positive/negative infinity must be loadable 
as a normal number, not just in pairs.

Thanks Oldes. I've curecoded the inconsistencies I've noticed:
   http://www.curecode.org/rebol3/ticket.rsp?id=1717

Sunanda, you wrote, that INF support was good, not mentioning why. 
Can you explain, why do you want to have it?

INFs (and NANs) are part of the standards REBOL is coded to. It's 
good to match as much of the standard as possible.

Hmm, that reason is not relevant, as far as I can tell. Example: 
IEEE754 standards define comparisons, but REBOL uses a different 
approach.

So, REBOL is not "coded to standards", rather it uses the available 
features of the hardware.

In my opinion, the exclusion of infinities from the decimal! datatype 
was intended, exactly because REBOL was not "coded to standards". 
(I may be wrong, not being Carl, though)

In general, the usage of infinities in programming languages is not 
required by any standards, as far as I can tell. In my opinion, it 
is only "supported".