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

World: r3wp

[Core] Discuss core issues

Oldes
16-Jan-2007
[6691]
Forbidden access into history error?
PeterWood
16-Jan-2007
[6692]
Personally, I think that processing BC dates is slightly less banal 
than dates after the year 32677.
Oldes
16-Jan-2007
[6693]
I don't think if it's too important, if you are making history application, 
you should be awared of such a issues. But error would be probably 
better than this.
Volker
16-Jan-2007
[6694]
regarding chit-chat, then you  need dates going  back at least  6k 
years, maybe even some billion!^^

regarding  bc,you have to figureoutwhen the  calendars changed. Andhaveto 
 agreewhich calendars to  use^^
Henrik
16-Jan-2007
[6695]
astronomical applications might need to go into extremes with date 
handling. I think Geomol would know about this more than me. :-)
Rebolek
16-Jan-2007
[6696]
astronomical application would use Julian date anyway I think :)
Geomol
16-Jan-2007
[6697x2]
Date handling is difficult! :-) The UNIX command "cal" handle the 
switch from Julian to Gregorian Calendar in 1752. If you have access 
to UNIX, try:
cal 1752

and look at September. Henrik, I'm not sure, what astronomical applications 
do, but I guess, we can look it up.
AFAIK, REBOL can't handle the calendar switch.
Volker
16-Jan-2007
[6699]
it cant handle infinite ints too. Somewhere there  hastobe a  tradeoff^^
Oldes
16-Jan-2007
[6700x2]
But Rebol could be able to work with positive and negative infinity. 
I think, it was one of my "not so important" requests.
IEEE 754 defines formats for representing floating-point numbers 
(including negative zero and denormal numbers) and special values 
(infinities and NaNs) together with a set of floating-point operations 
that operate on these values. http://en.wikipedia.org/wiki/IEEE_floating-point_standard
Geomol
16-Jan-2007
[6702]
I can live with the way, dates are implemented in REBOL, because 
it's fast. If I needed another date handling routine (for example 
for an astronomical application), I would program it. I also think, 
it's ok, that we don't have BC dates. Benefit is, that we have dates 
far into the future.
Oldes
16-Jan-2007
[6703]
I agree
Ladislav
16-Jan-2007
[6704]
I considered 1/1/0000 as an acceptable minimum too. Taking that as 
given do you think that it is OK what 1/1/0000 - 1 does?
Oldes
16-Jan-2007
[6705x2]
I think, throwing an error would be better.
But don't think, if it's so important to me
PeterWood
16-Jan-2007
[6707]
Given that 1/1/0000 is a base is doesn't seem logical to me to able 
to subtract from it . I'd go with a script error or if that's not 
desirable return the base value ie 1/1/0000
Geomol
16-Jan-2007
[6708]
Ladislav, if it slow down the routine to have another value from 
1/1/0000 - 1 as we have today, I wouldn't change it.
Ladislav
16-Jan-2007
[6709x2]
Geomol: originally I felt this might be a viable POV, but I am against 
it, because it means, that some REBOL values are not LOADable/MOLDable 
making REBOL script preprocessing impossible
(or causing strange console crashes)
Maxim
16-Jan-2007
[6711x3]
and we must not forget that REBOL is not C.. datatypes have more 
than just values, they have meaning.
an integer really is a whole number... substracting 1 from the smallest 
value an integer can hold Must raise an error... in any weird twist. 
 otherwise we end up with scripts which have no meaning...  -100 
- 1 =  100  makes no sense to anyone except the cpu, cause its stupid... 
why should such kind of logic end up in a language which does all 
it can to stray from that kind of logic in the first place.
Thus I second Ladislav's POV... a minimum must  not be substractable... 
it makes no sense.  fix your script, detect the error, create your 
own interpretation of out of bounds values, but don't act as if nothing 
is wrong, when its obvious... the intent of the operation has no 
relation with the meaning of the result.
Ladislav
16-Jan-2007
[6714]
actually, I can imagine that a result of x - 1 may be a "useful" 
value, example:

    -2147483648x0 - 1x0 == 2147483647x0

, but I strongly object against obtaining an "illegal value"
Sunanda
16-Jan-2007
[6715]
<datatypes have meaning> But they do not always have predictable 
behaviour when stressed.


For example: ook what happens to the x/2 and x/2 components here. 
Is that what you woudl have guessed?

x: 2x2 loop 40 [print x: x * 2x3]
Ladislav
16-Jan-2007
[6716]
So, my "rule of thumb": REBOL expressions should not yield non-moldable/loadable 
values (#[unset!] and errors aside), what do you think?
Pekr
16-Jan-2007
[6717x2]
correct imo, because if we allow that, how could be bet upon reflectivity 
and self-inspecting code principles?
imo it is that - error you can catch, but non-expected result is 
worse than error :-)
Maxim
16-Jan-2007
[6719x3]
non-expected result is worse than error

 exactly what I mean.   but to consider "what is expected" one has 
 to back away from "computer science" and think about the meaning 
 of most of the types.
x: 2x2 loop 40 [print x: x * 2x3]  getting negative numbers is just 
plain wrong.
maybe in C its ok, cause you (should) understand about CPU registers, 
binary calculus in finite space etc... but for a REBOL application.
Pekr
16-Jan-2007
[6722x2]
if integer (or whatever datatype) space is not sufficient, we should 
forbid overflows. I would expect an error - size/number overflow. 
Then it is up to programmer to accept another technique ...
And maybe part of the documentation should be section about datatypes, 
their ranges, etc.
Maxim
16-Jan-2007
[6724x2]
an int is a number and substracting from a negative value should 
return a negative value, or error if the result is out of bounds. 
  I really think that is the POV of REBOL itself... its meant to 
make programming simple... not complicate thing by re-introducing 
things like overflow causing the carry bit to roll number around, 
like in C...
there is a section on datatypes, but they do not go in depth at the 
limits, the conversion, the "expected" behaviours, the overall line 
of conduct on "strange events"
Ladislav
16-Jan-2007
[6726x2]
another food for thought. What do you think about this?

equal? to file! " " to file! "^(20)"
(the result is == FALSE), while

    equal? mold to file! " " mold to file! "^(20)" ; == TRUE
Maxim
16-Jan-2007
[6728x2]
this is where objectivity is at loss.  they are equal and not depending 
on what you consider equal, or rather if:
- the evaluated human concept is equal (a space)

- the rebol value can be converted to from two types symbiotically.

- they obey a specified set of guidelines like (if converted to string 
both are equal)

- they must be strictly equal (of same type, but not the actually 
same instance)
- the same (actually two references to the same value)
(but you know that... hehe ... you did a thesis on REBOL equality 
 ;-)
Rebolek
16-Jan-2007
[6730]
Ladislav there's problem with files with SPACE on begining (and end 
too I think), it's in RAMBO.
Ladislav
16-Jan-2007
[6731x3]
looking it up in RAMBO...
yes, Rebolek, that is a good suggestion solving the issue
so to file! " " should be %%2520 while to file! "^(20)" should 
be % , right?
Rebolek
16-Jan-2007
[6734]
yes, I think so. Little bit messy, I think.
Ladislav
16-Jan-2007
[6735]
do I understand correctly that you don't like it? (do you want something 
better then?)
Maxim
16-Jan-2007
[6736]
we want the whole truth ,   NOW  ,  (sorry... chit chat seems to 
infect me somtimes)
Geomol
16-Jan-2007
[6737]
Good points here! :-) I now see the problem. It might be best to 
return an error, when subtracting 1 from the lowest value of a date. 
Make sure, you think it through as much as you can, and then be consistent. 
If one datatype return an error in such a situation, another might 
as well.
Ladislav
16-Jan-2007
[6738]
Date again to be specific, I think, that REBOL has to pass this tests 
(and similar):

		any [
			error? try [date-d: 1/Jan/0000 - 1]
			not error? try [load mold date-d]
		]
Maxim
16-Jan-2007
[6739]
I agree
PeterWood
16-Jan-2007
[6740]
On the subject of date! and values having meaning. I think that the 
zone refinement needs to be looked at again:

>> dt: 17-Jan-2007/9:52+25:00
== 17-Jan-2007/9:52+25:00

but 

 >> 17-jan-2007/9:55+5:45
** Syntax Error: Invalid date -- 17-jan-2007/9:55+5:45
** Near: (line 1) 17-jan-2007/9:55+5:45


To the best of my knowledge +25:00 is not a valid time zone offset 
but +5:45 is (Nepal).