r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Gabriele
9-Sep-2006
[5266]
volker is right, there's no way to remove words from system/words.
Graham
9-Sep-2006
[5267]
if you have a situation where f1:  does [  f2 f3 f4 ] .. where all 
f1 - f4 are functions, is there a way that f2 can cause a return 
to the calling function of f1.  Do I have to throw an error to do 
this?
Ladislav
10-Sep-2006
[5268x2]
Graham: I guess you mean something like: f1: func [[throw]] [f2].
(my TFUNC does this "more comfortably" and for REBOL3 a change in 
that direction is planned)
Graham
10-Sep-2006
[5270]
Ok.
Ladislav
11-Sep-2006
[5271x4]
How RETURN works in R2
let's define the following function:

g: func [f [any-function!]] [f [return 1] 2]
now we may test what happens for different argument functions we 
may supply:
>> g :do ; == 1
== 1
>> g func [blk] [do blk]
== 2
>> g func [[throw] blk] [do blk]
== 1
Ladislav
13-Sep-2006
[5275]
poll: do you find it acceptable that for some numbers load mold number 
is an error?
Anton
13-Sep-2006
[5276]
example ?
Ladislav
13-Sep-2006
[5277x3]
the maximal or minimal possible decimal! values cannot be load molded
(while they can be computed, if you know how)
(do you really want me to present a formula here?)
Rebolek
13-Sep-2006
[5280]
IMO it should be moldable
Ladislav
13-Sep-2006
[5281]
they are moldable, but you cannot load the result back
Anton
13-Sep-2006
[5282]
Are they valid values or not ?
Ladislav
13-Sep-2006
[5283]
they are valid
Anton
13-Sep-2006
[5284x2]
Then they should be loadable, shouldn't they ? There will inevitably 
be a case where they are needed in a program.
Are they molded differently somehow ?
Rebolek
13-Sep-2006
[5286]
OK, so they should be loadable too :)
Ladislav
13-Sep-2006
[5287]
every Decimal! is "molded differently" somehow, no decimal is "exactly 
molded", example: 0.1 is a decimal! , but because the decimal! values 
are IEEE754 binary floating point, 0.1 is represented as the nearest 
IEEE754 number, which is not 0.1, because IEEE754 cannot represent 
0.1 as you probably know
Anton
13-Sep-2006
[5288]
Oh, I see. So to make them loadable you would have to mold them with 
an identifier on the front, (eg.  0d0.1)
Rebolek
13-Sep-2006
[5289x3]
OK so minimal/maximal decimal! values can be molded as nearset loadable 
decimal! or not?
nearset=nearset
grr nearest :)
Ladislav
13-Sep-2006
[5292x2]
The problem is, that there is some "inaccuracy" involved and the 
inaccuracy is so high, that the molded maximum is higher than the 
IEEE754 maximum, i.e. it causes overflow
this means, that 0d0.1 does not help
Anton
13-Sep-2006
[5294x2]
That means the decimal! maximum needs to be pulled back to the highest 
value which does not cause a problem.
But I am still confused - how can it be: "decimal! values are IEEE754 
*binary* floating point"  ?  I thought decimal! where using decimal 
math ?
Ladislav
13-Sep-2006
[5296x3]
the solution is not that easy. The problem is, that if somebody gives 
a number that is higher than all representable numbers, the overflow 
*should* occur. so we may need higher accuracy instead
 I thought decimal! where using decimal math ?
 - my favourite example: 0.3 - 0.1 - 0.1 - 0.1
in decimal math the result is exactly zero as everybody knows
Anton
13-Sep-2006
[5299x4]
Of course, sorry - confused with deci!  ..... (Probably the first 
of many confusions...)
Let me read all that again...
Yes, makes sense now.
Ok, I suppose you asked this poll question because you are looking 
for a way for the highest decimal! to be load moldable and it looks 
difficult / problematic.
Ladislav
13-Sep-2006
[5303]
the problem lies in the accuracy - we would need at least 17 digits 
from mold to be able to load back
Anton
13-Sep-2006
[5304]
How many digits are molded now ?
Ladislav
13-Sep-2006
[5305]
15
Anton
13-Sep-2006
[5306]
Maybe MOLD can be more accurate, and FORM can be less accurate ?
Ladislav
13-Sep-2006
[5307]
The trouble is, that the 16-th and 17-th digits are a bit "nonsensical", 
but they are needed for this purpose
Anton
13-Sep-2006
[5308]
(and this exceptional behaviour can be only for this exceptional 
datatype ?)
Ladislav
13-Sep-2006
[5309]
yes
Anton
13-Sep-2006
[5310x2]
I'd rather have non-sensical digits than not quite orthogonal loading/molding.
I think you can't hide the quirks of the decimal!
Ladislav
13-Sep-2006
[5312]
right
Anton
13-Sep-2006
[5313]
Another idea is that both MOLD and FORM give 17 digits, and it is 
left to another function (perhaps a FORMAT mezz) to cut off the nonsensical 
digits.
JaimeVargas
13-Sep-2006
[5314x2]
Ladislav you are hitting the Serialization/Marshalling barrier. Having 
a language where there is no difference between serialized (molded 
in rebol terms) types and source code types is big plus of Rebol. 
But on the other hand it limits you when you want to marshall the 
data becuase of the assymetry introduce to maintain accuracy for 
some types like decimal.
Usually marshalled (molded) data from other languages like Objective-C, 
Smalltalk or Java is not et all readable as rebol. So this sepparation 
helps when dealing with representation issues at the cost of making 
difficult to change the binary enconding.