World: r3wp
[Core] Discuss core issues
older newer | first last |
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. | |
older newer | first last |