World: r3wp
[Core] Discuss core issues
older newer | first last |
Maxim 7-Nov-2006 [6002x3] | I can work around it (obviously).. but its just a core REBOL consistency issue. its semantically unacceptable for a function called to-INTEGER to return anything else than an integer. imagine if to-string decided to return words sometimes... its the same dangerous issue. |
many places this can be a total fuck up imagine this: as-integer: func [value][ any [ attempt [to-integer value] 0 ] ] here we end up with a broken logic and impending doom...not of our fault. | |
so for now, we should all do this IMHO: to-integer to-integer value | |
Ladislav 7-Nov-2006 [6005] | how could that help you? |
Maxim 7-Nov-2006 [6006x2] | it raises the error overflow error. |
the way to-integer is implemented right now it should be called to-number | |
Gregg 7-Nov-2006 [6008x2] | to-integer is consistent as long as the value being given to it is within the bounds of 32-bit integer; outside that range, all bets are off. Your solution isn't going to help you, or catch other errors, e.g.: >> to-integer to-integer "2147483646344.0" == -1656 >> to-integer to-integer "2147483648343.0" == 343 |
Only Carl can say why he designed it this way or, indeed, if it's intentional | |
Maxim 7-Nov-2006 [6010x2] | my god this horror is worse than I thought ! |
thanks for catching the 32 bit rollover | |
Gregg 7-Nov-2006 [6012] | I don't know if I'd call it "horror", though it's obviously not what some people will expect. It just means having to deal with those cases differently; use LOAD or TO DECIMAL! and check the range, etc. |
Maxim 7-Nov-2006 [6013x3] | hehe load also returns a decimal... I guess THAT is where the to-integer reaction is comming from deep inside. |
but LOAD's reaction would be open to subjective debate. to-integer cannot return anything else than an integer... it just makes no sense. the primary goal of the function is to have as a return value a specific type. | |
AH HA! I have a fix ! | |
Gregg 7-Nov-2006 [6016] | Yeah, for that one, exact, string of ten characters, it's inconsistent. |
Maxim 7-Nov-2006 [6017x2] | make integer! reacts as it should. |
sourcing 'TO-INTEGER I see that its not using make. | |
Gregg 7-Nov-2006 [6019] | There you go then. :-) All the TO-* funcs are generated auotmatically I think. |
Maxim 7-Nov-2006 [6020] | I just discoverd something quite interesting... is it generally know that the issue datatype is inherently hexadecimal? |
Gregg 7-Nov-2006 [6021] | Hmm, quick test; are you sure it does? |
Maxim 7-Nov-2006 [6022] | >> to-integer #a == 10 |
Gregg 7-Nov-2006 [6023] | Yes, that's known behavior; very handy. |
Maxim 7-Nov-2006 [6024] | I guess its just the 'TO function |
Gregg 7-Nov-2006 [6025] | MAKE does the same thing as TO here. |
Maxim 7-Nov-2006 [6026x4] | 'MAKE already accepts strings and decimals for creating integers... maybe to-integer should be redefined as: to-integer: func [value][make integer! :value] |
oooh this is much worse than I tought ! make integer! "2147483648" == 2147483648.0 | |
but this crashes: make integer! 2147483648.0 ** Math Error: Math or number overflow ** Near: make integer! 2147483648.0 | |
so ignore my 'MAKE suggestion... IT is the culprit, obviously. | |
Anton 7-Nov-2006 [6030] | I agree, some of the TO- datatype functions need to be tightened up. |
Ladislav 8-Nov-2006 [6031x5] | thanks for finding this, guys, I will do my best to convince Carl to correct it |
Max: in RAMBO you wrote: "Some string values will crash to-integer, some decimal values will crash make integer some don't. " - I suppose you meant "cause an error" instead of "crash"? | |
the problem is, that integer arithmetic looks inconsistent - some integer operations "overflow to decimals": to integer! "2147483648" ; == 2147483648.0 1 / 3 ; == 0.333333333333333 log-10 1 ; == 0.0 - some operations "wrap": to integer! "2147483646344.0" ; == -1656 abs -2147483648 ; == -2147483648 - some operations cause errors: 1 + 2147483647 | |
The consistency requrement looks natural, but I don't think that it is easy to be consistent "regardless of the cost". Discussion welcome. | |
...adding to the list of integer operation behaviours. - some operations crash: -2147483648 // -1 | |
Pekr 8-Nov-2006 [6036] | looking into that discussions, I wonder, if Rebol could be EVER considered to be used for the NASA purposes, as e.g. Python was used for some things. Unless things are really predictable and without side effects, I am not sure it is. |
Ladislav 8-Nov-2006 [6037] | I guess, that you are able to articulate your preferences too, so go ahead and speak. What are your preferred behaviours? |
Henrik 8-Nov-2006 [6038] | well, predicable behaviors are preferred :-) Could there be performance hits if behavior is to be 100% consistent? |
Ladislav 8-Nov-2006 [6039x2] | Of course, the "cheapest" is the wrapping behaviour. |
in that case the integer division may be defined as in C | |
Henrik 8-Nov-2006 [6041] | the question is, would there not also be a performance hit if you need to check for wrapping inside your rebol code? |
Pekr 8-Nov-2006 [6042] | Ladislav - dunno in that particular case. But I am just sensible enough to what others say. I reacted to the fact, that Rebol does have side effects. I don't know if it was Erlang or other functional language, where they claimed programmers like it, because of no side effects = predictable. But maybe it is just the case of documentation, but really - many novices just try in console by trial and error .... |
Ladislav 8-Nov-2006 [6043] | performance hit if you need to check for wrapping inside your ... code - that is exactly what every C programmer needs to do |
Henrik 8-Nov-2006 [6044] | ladislav: yep, but isn't that faster to do in C than moving that check out into rebol code? |
Ladislav 8-Nov-2006 [6045x5] | ...and it is the highest performance solution, because you usually don't need to "check..." |
especially when we take into account the fact, that integers will be 64-bit | |
so, performance-wisely speaking the fastest solution *is* wrapping, no doubt | |
OTOH, the safest solution is to either yield a meaningful value when appropriate, or cause an error | |
moreover, "yielding a meaningful value" is faster than "causing an error" | |
Maxim 8-Nov-2006 [6050x2] | but a meaningfull value is subjective. what is meaningfull in one context can be your worst ennemy in another. |
basically, the interpretet at some points "chooses" what it thinks is the best behaviour when it finds something screwy... but really... the fundamental event is that something screwy occured. so for correctness and intuitive consistency, screwy things should error, not try to recover. | |
older newer | first last |