World: r3wp

Forbidden access into history error?

Personally, I think that processing BC dates is slightly less banal 
than dates after the year 32677.

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.

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^^

astronomical applications might need to go into extremes with date 
handling. I think Geomol would know about this more than me. :-)

astronomical application would use Julian date anyway I think :)

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.

it cant handle infinite ints too. Somewhere there  hastobe a  tradeoff^^

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

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.

I agree

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?

I think, throwing an error would be better.

But don't think, if it's so important to me

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

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.

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)

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.

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"

<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]

So, my "rule of thumb": REBOL expressions should not yield non-moldable/loadable 
values (#[unset!] and errors aside), what do you think?

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 :-)

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.

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.

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"

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

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 
 ;-)

Ladislav there's problem with files with SPACE on begining (and end 
too I think), it's in RAMBO.

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?

yes, I think so. Little bit messy, I think.

do I understand correctly that you don't like it? (do you want something 
better then?)

we want the whole truth ,   NOW  ,  (sorry... chit chat seems to 
infect me somtimes)

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.

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]
		]

I agree

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).