World: r3wp

sorry, 1 second :)

Hm, you may have a serious problem. Let me see...

:) REBOL2 can't do math. Thinking, if a struct! can help.

Hahaha :)

>> arccosine/radians probe round/to (1.48297457491612E-2 + 0.985170254250839) 
1E-15
1.0
** Math Error: Math or number overflow

** Near: arccosine/radians probe round/to (1.48297457491612E-2 + 
0.985170254250839) 1E-15

>> arccosine/radians probe round/to (1.48297457491612E-2 + 0.985170254250839) 
1E-14
1.0
== 0.0

You can look at the internal of decimals in R2 with struct! like 
this:

	d: make struct! [v [decimal!]] none

 i: make struct! [lo [integer!] hi [integer!]] none	; assuming little 
 endian

>> d/v: (1.48297457491612E-2 + 0.985170254250839)
== 1.0
>> change third i third d
== #{}
>> i/lo
== 1
>> d/v: 1.0
== 1.0
>> change third i third d
== #{}
>> i/lo                  
== 0

In first case with the addition, i/lo is 1, and 2nd case, it's 0.

I don't have time to dig into it deeper now. But if you find a simpler 
way to check these things, post it.

You can see the bit patterns with this code:

	do http://www.fys.ku.dk/~niclasen/rebol/libs/bit.r
	enbit i/lo
	enbit i/hi

What does 'third d' actually represent?

Also the bits in some order depending on endianess, I guess.

If I got it correctly, using struct, we get access to the internal 
representation of decimal in R2. Then the third value in the struct 
is the number behind the comma, and we divide it into two section 
using struct! i, which will then reveals the last number. Hope I 
get it right.

Third value is the full 8 bytes (64 bit) for decimals. As integers 
are 32 bit in R2, we split the 8 byte decimal in 2 times 4 byte integers. 
Third i also give the full 8 bytes.

Decimals are in IEEE 754 standard. See: http://rebol.net/wiki/Decimals-64

That doc is meant for R3 though, so things like setting system/options/decimal-digits 
won't work in R2.

Ok, I think I got the idea. Thanks for looking into this! For now 
I'll stick with round/to x 1E-14 for practical reason. But it's very 
nice that I learned deeper about how decimal works and handled.

The PROBE function is not reliable in this case, you can use e.g. 
MOLD/ALL:

>> mold/all 1.48297457491612E-2 + 0.985170254250839
== "1.0000000000000002"

when you're out there at 15-17 digits, you can't count on the last 
one
 - that formulation is rather confusing

exact comparison in R2, comparing 1.48297457491612E-2 + 0.985170254250839 
with 1.0 :

>> 1.48297457491612E-2 + 0.985170254250839 - 1.0
== 2.22044604925031E-16


This demonstrates, that the result of the expression is greater than 
1.0

The whole issue is caused by the fact, that Carl decided to "hide" 
some issues, that are "more honestly exposed" by other programming 
languages. Usually it looks, like the "arithmetic hiding in REBOL" 
helps, but there are cases like this, where the result of hiding 
is worse, than if the arithmetic was "honest".

Thanks, Ladislav. You nailed it better, than I could. About the last 
digits, I meant, that we can count on 15-17 decimal digits of precision. 
I guess, it's more precise to say, that the decimal! datatype has 
15.95 decimal digits of precision.
See: http://en.wikipedia.org/wiki/IEEE_754-2008#Basic_formats


For the new ones, an often used example, where math with IEEE 754 
floats (in all languages) gives unexpected result is:

>> 0.1 + 0.2 - 0.3
== 5.55111512312578E-17

I guess, it's more precise to say, that the decimal! datatype has 
15.95 decimal digits of precision.

 - the most precise is to say, that it has (usually) 53 binary digits 
 of precision. That can be "transformed" to 15.95, but such a "transformation" 
 is quite uniformative, since it ignores some important facts

Fact #1: the representation is binary, and it cannot represent exactly 
even the numbers representable using just one decimal digit

Fact#2: 16-digit decimal numbers cannot be used to represent "exactly 
enough" the IEEE754 binary numbers

(to not confuse the reader, I should have used "precisely enough" 
instead of "exactly enough" in the above fact#2 statement)

why is , not valid word?

>> type? '.
== word!
>> type? ', 
** Syntax Error: Invalid word -- ',
** Near: (line 1) type? ',

Assumably because the opinion was/is, that commas make programs less 
readable. I see no other reason.

I see it absolutely cruicial that there aren't commas between elements 
[ 1 2 3 ] NOT [ 1, 2, 3 ].. but this has nothing to do why , couldn't 
be a valid word of a dialect for example if . ` (for example) are 
IMHO

(I suspect it's used somewhere, but I don't see it .. like % or $ 
is not a valid word since they are part of file / money format ( 
not that parser couldn't be made a little smarter and still allow 
it))

Good question... I was asking as well long time ago http://www.rebol.org/ml-display-message.r?m=rmlDRXJ

Geomol, you are the winner! That is the official reason. Plus, ,0 
is the same as 0.0 since , can be used as a decimal separator.

so any program that has , anywhere is ugly so we ban them.. it's 
no use in complaining, but that doesn't make sense to me.

now my dialect that consumes sql has dots instead of commas [ select 
user.id . user.* from user where id = #myid and name = #name ] .. 
I will surviwe but I will hardly impress any geeks to rebol with 
it as I otherwise could :)

Oldes, I'm on linux where I can't copy poaste that url from altme 
or click it (I don't know why linux doesn't fix dual copy paste and 
istead focuses of various fancy stuff)

So I will reply later when I can

If comma is allowed as word, decision has to be made, what to do 
with things like ,0 as Brian point out. Either anything starting 
with a comma should be words (easy to implement, but might give unpredicted 
result to users trying to writing decimals starting with a comma) 
or a special rule should be made, so it's a decimal, if the comma 
is only followed by digits, else it's a word (harder to implement).

You also need to handle things like:
,000'000e+4
which is simple 0.0 today.

To me, not having comma is a problem in that certain types of data 
become much harder to load.

This is also strange:
b: to-block ";"
length? b
== 0

even:
b: to-block ";;;;;;;"

I think these issues are related to parse, as coma and semicolon 
are default separater for parse.

actually not strange, since to-block converts the string into REBOL 
data, so it's interpreted as an inline comment. I think the behavior 
is correct.

I see, that's correct. I missed that semicolon is for commenting.

TO-BLOCK can be seen as a cheap version of LOAD, AFAIK.

Much cheaper on R3 than R2 - LOAD does a lot of work. Note that TO-BLOCK 
doesn't bind any words in the resulting block, which can come in 
handy sometimes.

thanks, I would I ask what is the difference :)

TO BLOCK! is much safer on untrusted data as well.

what is risk if I use load?

The comma being disallowed as a word does mean you can't use it literally 
i true dialects, but that doesn't prevent you from writing a DSL 
and using string parsing. There have to be lines drawn somewhere.

LOAD used to evaluate headers aggressively, though I don't think 
it does any more under R2. I'm not sure about R3, but I imagine Brian 
has made sure that's safe.