World: r3wp

Yes, but he told  to add 50% of what to 10? That's the missing multiplication.

It's an issue of mathematical intuition, which I do believe is established. 
 "That'll be 19.99... plus 12 percent tax"

Hey, it's early enough, make a proposal and submit it to CureCode. 
Be sure to check first to see if it's already there though.

Well it doesn't matter all that much, easy enough to work around. 
 I just wish Rebol showcased a bit more of its ability to have the 
cross product of behavior across types in examples where people would 
go "whoa, how'd it do that?" then... "oh, I see..."

One decision that I used to not think much of one way or another 
which I now really think is important is the idea that "none" is 
false? while 0 is not.

And remrmber that the mathematical intuituin you mention isn't the 
same if you swap the arguments. Note that Wolfram swaps the arguments 
back if you put the percent first. That is because the intuition 
for 50% + 10 is that it result in 60%.

in -> be

Sorry, I've been getting the AltME freezes again. It's affecting 
my typing.

Regardless of other decisions, I feel like it's important to preserve 
the property that (a + b) = (b + a), as addition is... er, what's 
the word, commutative?

50% + 10% should be 60%, but 50% + 10 should equal 10 + 50% no matter 
what one decides otherwise.

Yes, I had forgotten the word, thanks. Unfortunately, the mathematical 
intuition is not commutative.

Well that sounds more like linguistic intuition than mathematical 
intuition.

I didn't feel like saying percent again

Intuition is a bit of misnomer here. What you are really saying is 
"expected behavior". And that is always in the eye of the peoson 
doing the expecting.

Great, now I have AltME freezes and a cat that is jealous of my computer 
- double whammy to my typing.

Natural programming is an interesting research area: http://www.google.com/search?hl=en&source=hp&q=10+%2B+50%25&aq=f&aqi=h1g10&aql=&oq=&gs_rfai=

They get lots of people in and give them a box of fruit containing 
apples, oranges, pears

And ask like hundreds of people "go to the box and bring me back 
something that's not an apple or a pear"

And no one (who isn't a snarky programmer) brings back a pear.

How much of this is cultural and how much is some deep embedded pattern 
instinct a la X bar theory is tough to say http://en.wikipedia.org/wiki/X-bar_theory

But if things like X bar theory and these studies have merit, one 
actually can say that "right answers" aren't necessarily as fluid 
as being in the eye of a particular beholder as we might guess.

Or who is from a culture with a language that assumes that or is 
inclusive. You haven't worked with many people for whom non-Western 
languages are their primary thought-shaping languages, I take it.

Of course even then it's only right in a context, the context of 
human programmers... a time which will likely be coming to a swift 
end.  :)

Moving to "Chat"

go to the box and bring me back something that's not an apple Nor 
a pear

We need parentheses grouping of statements in English :(

The english language is a bit loose ... and since the incorrect way 
of saying things is so common, one assumes that what's the speaker 
meant

Correctness is in the eye of the beholder :)

Fork, I would consider your desired behavior for an INCR function.

what's the quickest way to determine whether a series is past end 
in R2 and then handle it?

tail?

that is not accurate enough

Why not?
Is
     (index? s) > length? s
any more accurate?

oh well, used this:

all [series? :value greater? index? :value length? head :value]

Sunanda, didn't see your post, but thanks, it's what I use.

Quickest for what you test for might be:

and series? s tail? s

As a side note, I noticed, TAIL? and EMPTY? is the same. So you can 
also write the above as:

and series? s empty? s


Is it wise, that TAIL? and EMPTY? does the same? Maybe EMPTY? should 
return false, if the series holds elements, even if you're at the 
tail.

AND is an op, thus infix, and doesn't have shortcut evaluation. This 
means that you should use AND~ instead of AND if you want prefix, 
but it will still fail if s is a datatype that is not compatible 
with EMPTY? because EMPTY? s will still be called even if SERIES? 
s is false.

Henrik, can you post some code that will make a series reference 
that is past the end of a series? I'm having trouble making one that 
works consistently, and neither your INDEX? method or EMPTY? will 
work. REBGL keeps adjusting the index returned by INDEX?.

>> b: next a: "a"
== ""
>> index? b
== 2
>> remove a
== ""
>> index? b
== 1  ; adjusted
>> insert a "1"
== ""
>> index? b
== 2 ; and back again

In R3 they stay consistent, and there is an action PAST? to tell 
whether an index is past the end.
>> b: next a: "a"
== ""
>> remove a
== ""
>> index? b
== 2  ; not adjusted
>> past? b
== true


In R2 I don't even see how to write this in mezzanine without temporarily 
appending something on the end of the series (a single element will 
do) and seeing if the index adjusts, then removing what you appended. 
Like this:
>> b: next next next a: "abc"
== ""
>> clear a
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b
== true  ; past end
>> b: ""
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b

== false  ; not past end, but Henrik's method, and EMPTY? will both 
return true.

Still, the temporarily appending method would be sufficient to backport 
a PAST? workaround, so I'll write one for R2/Forward.

Here's the source to the backport:
past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series!] ; gob! port!
][
	also (index? :series) < (insert tail :series "1" index? :series)
		clear back tail :series  ; Undo the modification
]

; Note: Native in R3, and non-modifying. No ports because you can't 
undo the

; insert. INDEX? doesn't stay consistent with past-tail references 
in R2.

Submitted to R2/Forward.

Thanks, I had forgotten PAST? :)

I'm not sure I would want the series to be modified as the case where 
PAST? is true could be for an indication of the series in a debug 
UI, rather than the actual use of the series. Interesting that you 
had so much trouble producing the problem.

ah, you had trouble, because you were removing an element before 
the INDEX?, not after the INDEX?.

>> b: "abc"
== "abc"
>> b: next next b
== "c"
>> clear back b ; does not modify INDEX?
== ""
>> b
== ** Script Error: Out of range or past end
** Near: mold b
>> index? b
== 2 ; works every time

You are also removing an element before the index, but not from the 
beginning. Apparently clearing from somewhere other then the beginning 
of the series breaks the auto-adjusting (which shouldn't be happening 
anyways). PAST? works the same either way.

It was unfortunate to adjust the result of INDEX? function, since 
we actually obtain a wrong value this way. Auto-adjusting is not 
broken in the case Henrik posted.

>> b: "abc"
== "abc"
>> b: next next b
== "c"
>> index? b
== 3
>> clear back b
== ""
>> index? b
== 2