World: r3wp

Would all those problems be solved, if the decimal! datatype actually 
was the money! datatype, and if we then had a real! datatype, that 
did it a fast way and giving results as we see in C and other languages?

As a practical example, if you are doing device-independent rendering 
you work in proportions (floating point ratios) and then convert 
to exact values (integer coordinates) on final rendering to the real 
device. Video games do this all the time - that is why GPUs need 
floating point hardware. Same with sub-pixel rendering. If you are 
working in proportions, your modulus functions will need to handle 
them. And modulus could be used for bounding box calculations on 
textured surfaces too.


In both those cases, the programmer will probably know enough about 
accumulated error to want to control it themselves. The non-rounding 
behavior of // would be a benefit to them then, so rounding can be 
minimized.

I feel, much confusion come from having a decimal! datatype, that 
isn't really that, decimal.

There are two reasons, why it it not feasible, IMO:


1) decimal! was used for IEEE754 as "the most common floating point 
datatype"


2) money! is not as "common", because it is slower, so maybe this 
should not change

Otherwise, I am pretty sure, that the name "decimal!" was unfortunate!

Also, think of the syntax. We have a sigil to denote the current 
money! type, which *was* added for financial calculations. If that 
type was the default, what would the floating-point sigil be?

...but, I guess, that Carl still thinks, that the majority of users 
may be formed by the people, for whom the name "64-bit binary floating 
point number" sounds like insult

I agree that float! would have been a better name than decimal! (not 
real! because they aren't). Too late now.

real! is not that bad either, actually, they are (subset of) real 
numbers, with "just a bit twiddled" arithmetic

That "subset of" is the kicker. Integers are also a subset of real 
numbers.

anyway, money! are implemented to have floating (really decimal in 
that case) point too

yes, but (Rebol) integers are subset of integers too

Brian, regarding graphics, wouldn't it be normal to convert the floats 
to integers before doing the modulus calculation? I may be wrong, 
but I'm not sure, I would need float modulus in such application.

so, integer! datatype comprises some integer numbers, therefore the 
real! datatype could comprise some real number IMO

In Python, they call them reals. In Lua, you just have numbers. Integers 
and floats are the same internally as far as I can see.

Reals surely is a much more appropriate name, than decimals

Thanks! :) I think the same.

...but I bet, that I and Geomol would be OK with IEEE-754! or a similarly 
"ugly" name, which may really scare some people

I still think float! is the most appropriate, due to that significant 
"subset of" thing.

but, if you want be that precise, you cannot use the integer! name 
either

make IEEE-754! exp 1
oh no! :)

I agree on real!

A problem with "float" might be, that many will think 32-bit right 
away. And we have 64 bits to play with.

Geomol, it wouldn't be normal to convert to integers first if you 
are trying to manage rounding and the specific integer values are 
only an end-device approximation of real valued proportions and coordinates. 
In other cases, converting to integers would be appropriate. It varies.

nevertheless, I guess, now it is not real to require real! as the 
real name :-D

A 64bit float is still a float. There are 128bit IEEE754 floats too 
(and perhaps 256bit, I don't know).

:)

No 256bit yet - it will come soon, I'm sure :)

there is a "slight" difference between "real" and "float" - both 
can be used, but "real" is more understandable for a layman than 
"float" - where does it float?

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?

That is what  I like about the name. A programmer will understand 
the difference. REBOL is made for programmers, not laymen. We finally 
disabused ourselves of that delusion.

When do you use e when not doing exponents? Not familiar with e's 
use - I took calculus in 1987 and haven't used most of it since.

yes, but in the above case both "real" and "float" are actually of 
the "same information value" for an expert - not knowing from the 
name neither how many bits they use, nor what is the base (2 or 10)

re E: Rebol has LOG-E, so it would be natural to have E defined, 
the problem I see is, that the name is "too short", so Carl wanted 
to leave it for "common use"

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!.

We could call integers for Integral, like Python have numbers.Integral
(just kiddin)
I like integer! and real!
(I may change my mind.)

Should the hyperbolic math functions be part of REBOL? Like the C 
functions cosh, sinh, tanh. Many languages have them (I've checked 
Lua, Python and Ruby).

Pekr as for HTTPS protocol I agree with the other people here. Lets 
some external developer do the work once the basis is complete.

I was very amazed to read that even Gabriele sometime gets no answers 
from Carl. He is one of the closest developers to RT !

However, if we could summarize 2009, it has been a nice year for 
REBOL. Many things have evolved and I have not seen the development 
blocked for more than a week. I don't know how many people are still 
at RT but I suppose the number is quite low and I think we must congrat 
with Carl.

If we think about the needing for money and time a company and a 
family needs (talking about Carl's Family and RT) I am really suprised 
to see how much work has been spent over REBOL. Sometime I even ask 
myself  how it could be possible ? Has Carl some hidden treasure 
? Has he found a way to split himself so we have 2 Carl and not one 
? :-)

I asked Carl to react on reboltutorial article and to add old R3 
architecture doc I remember from the past. It is on R3 rebol.com 
page now ....

ppl were constantly confusing and merging R3 product with R2 marketing, 
although the model was explained many times ....

I am glad the doc is back ...

Changes to high resolution time in R3 - http://www.rebol.net/r3blogs/0293.html

Is there a way that I can get the number of parameters of a function 
in R3? 
So I can do this:

>> num-of-parameters :print
== 1
>> num-of-parameters :now
== 2

should be: >> num-of-parameters :now
== 0

num-of-parameters: funct [ f [ any-function! ] ] [
    clear find spec: spec-of :f /local

    remove-each element spec [ any [ string? element block? element ] 
    ] 
    length? spec
]

Important - Finalizing read and write - http://www.rebol.net/r3blogs/0294.html

Jerry - you can use words-of instead of spec-of. It doesn't return 
the comments.


>> a: func [b "comment" c "comment"  /local d] []                
        
 
>> b: func [c d e f /local z] []

 >> n-o-p: func [f] [length? copy/part spec: words-of :f find spec 
 /local]
 
>> n-o-p :a
 
== 2


>> n-o-p :b
 
== 4


Sory for the cryptic code. I had to keep it to a single line in the 
R3 console.