1. [OE vs Phix] assigning atom to a slice is different
- Posted by _tom (admin) Feb 15, 2018
- 1282 views
Why are OE and Phix different?
sequence s s = { 1,2,3,4,5,6 } s[1] = 9 ? s --eui--> {9,2,3,4,5,6} ----p--> {9,2,3,4,5,6} s = { 1,2,3,4,5,6 } s[1..1] = 9 ? s --eui--> {9,2,3,4,5,6} ----p--> {9,1,2,3,4,5}
_tom
2. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by ChrisB (moderator) Feb 15, 2018
- 1245 views
Hi
Looks like Phix is wrong (has shifted the numbers), but the purer response should be to throw an error, as who would ever assign an atom to a slice? (even though this is the special case of a 1 element slice, and pretty sure I have done this myself on occasion).
No access to Phix / eu eu at the moment, but what does a mid sequence 1 element slice assignment do?
Cheers
Chris
3. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by petelomax Feb 15, 2018
- 1260 views
Thanks, you found a bug.
Fix is line 441 of builtins\VM\pRepsN.e (for 32 bit)
--15/2/18: -- lea esi,[esi+eax*4-4] lea esi,[esi+eax*4]
and similar on line 1259 for 64 bit (just after the presumably not very thoroughly tested bugfix dated 29/12/15 of rax*4->rax*8)
--15/2/18: -- lea rsi,[rsi+rax*8-8] lea rsi,[rsi+rax*8]
It will never cease to amaze me how such things can lie undetected for so long.
As mentioned it is perhaps a slightly unusual case, in fact str[1..1]='a', str[1..1]="a", and seq[1..1]={9} were (and still are) all working as they should (flw).
Regards,
Pete
PS I trust you will recall that Phix supports variable length slice substitution, which OE does not, eg
string s = "fed" s[2..2] = "ee" -- s is now "feed"
- which I only mention since you appear to be on a testing path that might stumble over it.
4. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by katsmeow Feb 15, 2018
- 1224 views
PS I trust you will recall that Phix supports variable length slice substitution, which OE does not, eg
string s = "fed" s[2..2] = "ee" -- s is now "feed"
Respectfully, why? Or maybe, how? Doesn't this break things? Can you give a real-world case where this would be useful? Can you please give an url into the readme for this capability? I am not claiming this is a mistake, but praps you have something i cannot wrap my head around yet, and i'd like to understand the how and why of it. Thanks, Pete.
It's a shortcut for inserting a string into a string (queue fights about strings in Eu?), but doesn't it break the idea that a one-dimensional sequence is a sequence of atoms, where s is "fed" then s[2] is an atom, and if you make it a sequence, then you have a two-dimensional (nested) sequence {'f',"ee",'d'}?
Does it work like
string s = "fed" s[2..2] = "ee" -- s is now "feed" -- given seq p = "ee" s[2] = p -- s is now "'f',"ee",'d'" ? s[2..3] = "12" -- s is now "f12" ? s[2..-2] = "12" -- s is now "f21d" ?
I tried using Phix a couple years ago, but it failed to run, i do not remember why. I would be testing this myself if i could, as this post is more work than throwing together the tests.
5. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by _tom (admin) Feb 15, 2018
- 1240 views
Tried to apply the bug fix:
~/phix$ p -c p Check for and shut down any running instances of phix (retry messages are given if required after round 4) Self-host round 1: compiling p.exw Self-host round 1: compiled OK (1.80s), creating pnew (7.15s) ==>system_wait(/home/zeven/phix/pnew -pmkr2): some error!
Kat: the Phix docs are a .chm file you get with a fresh download of Phix.
It looks like the oE way is to replace a slice with a slice of equal length.
The Phix way is a slice can be replaced with anything. In Phix you can use subscripting and slicing to do the job of insert( and splice(.
Until I get a copy of "p" with the bug fix I can't elaborate.
_tom
6. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by euphoric (admin) Feb 15, 2018
- 1226 views
Pete, have you pushed that fix to the Phix repo?
7. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by katsmeow Feb 15, 2018
- 1257 views
The Phix way is a slice can be replaced with anything. In Phix you can use subscripting and slicing to do the job of insert( and splice(.
Thanks Tom, will do a download and rtfm ("read that friendly manual"). And i got the part about the insert functionality, but i question the resultant typecast of what is inserted. Maybe i am being paranoid, but i was so accustomed to type-checking and length-checking every little thing i did in Eu to prevent runtime crashes, that replacing an atom with a sequence sets my hair on end for a crash the next time i do an operation using the modified sequence. Kudos to Pete if he's fixed OE's fragility in this regard!
8. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by petelomax Feb 15, 2018
- 1245 views
Sorry, I forgot that self-hosting is broken on linux (or rather libc.so.6/system is throwing error code 32512 which makes no sense). I've rebuilt and uploaded the compiler, so the following should do the trick:
wget http://phix.x10.mx/p32 mv p32 phix/p
and I have now pushed that change to the repository.
--string s = "fed" seq s = "fed" s[2..2] = "ee" -- s is now "feed" -- given seq p = "ee" s[2] = p -- s is now "'f',"ee",'d'" ? --type check failure, s is {102,"ee",101,100} when s is string ?s -- s is now {'f',"ee",'e','d'} s[2..3] = "12" -- s is now "f12" ? ?s -- s is now {'f','1','2','d'} s[2..-2] = "12" -- s is now "f21d" ? ?s -- s is now {'f','1','2','d'}
Some operations on a string must auto-expand it to a dword-sequence; obviously that proved necessary for compatibility reasons. There is no such thing as an auto-compact.
Note that you can do pretty much anything with {'f','1','2','d'} that you can do with "f12d", obviously apart from storing it in a string variable, and compare({'f','1','2','d'},"f12d") yields 0 (equal), however they are quite different internally.
s[2..-2] is exactly the same as s[2..3] for a length 4 sequence, it does not reverse the slice being copied, dunno what made you think that.
A real-world example of this being useful could be a template letter containing "Dear [name],\nThank you for..." and you want to put the actual name in there.
For some online docs see http://phix.x10.mx/docs/html/slices.htm
Ultimately s[i..j] = rep is just a shorthand for s = s[1..i-1] & rep & s[j+1..$]
If it cannot do it in situ (eg because the lengths differ) then that is pretty much what it does internally, not significantly more difficult than what say a &= b has to do.
9. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by katsmeow Feb 15, 2018
- 1222 views
s[2..-2] is exactly the same as s[2..3] for a length 4 sequence, it does not reverse the slice being copied, dunno what made you think that.
I didn't think that. This form of insert() is an anomaly, so my instinct is to make different offerings to it and see how it responds. As you know in OE sub-sequencing, the negative terms are accepted if in range. However, i do not know beans about Phix, and cannot test this myself, mostly because of my inability to finish the install process.
A real-world example of this being useful could be a template letter containing "Dear [name],\nThank you for..." and you want to put the actual name in there.
Hmm, ok. I'd be using some form of replace("[name]",s[x]) there instead.
10. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by petelomax Feb 15, 2018
- 1196 views
As you know in OE sub-sequencing, the negative terms are accepted if in range.
Really??!
I'd be using some form of replace("[name]",s[x]) there instead.
That should also work.
11. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by katsmeow Feb 15, 2018
- 1178 views
As you know in OE sub-sequencing, the negative terms are accepted if in range.
Really??!
I do not understand your reply. You got onto me for either using a negative index, or you thought i was thinking it did something else odd. Either way, i defended my use of the negative index, and i suspect you are now replying sarcastically. I do not understand how this is turning into "another fight against kat" thread!
12. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by petelomax Feb 15, 2018
- 1196 views
What I meant by "Really??!": running this on 4.1
sequence s = {1,2,3} ?s[-2]
gives me
C:\Program Files (x86)\Phix\f06.exw:2 subscript value -2 is out of bounds, reading from a sequence of length 3 - in subscript #1 of 's'
and running this
sequence s = {1,2,3} ?s[2..-2]
gives me
C:\Program Files (x86)\Phix\f06.exw:2 slice upper index is less than 0 (-2) - in slice/subscript #1 of 's'
which leads me to believe that OE does not support negative subscripts.
Perhaps you mean something else by "negative terms are accepted if in range" - but I have no idea at all what that could be.
13. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by katsmeow Feb 15, 2018
- 1171 views
Well, since i removed Eu and OE almost a year ago, and have not written any code since, i cannot look it up or run any code using any indexes. Let's say my memory is bad and i am a total idiot.
But i found this after a quick random look in the online manual:
Example 2: names = {"fred", "rob", "rob", "george", "mary"} location = rfind("rob", names) -- location is set to 3 location = rfind("rob", names, -4) -- location is set to 2
My appologies. Negative values are only sugar syntax in libs. But, i could be wrong again!
14. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by irv Feb 15, 2018
- 1184 views
Example 2: names = {"fred", "rob", "rob", "george", "mary"} location = rfind("rob", names) -- location is set to 3 location = rfind("rob", names, -4) -- location is set to 2
My appologies. Negative values are only sugar syntax in libs. But, i could be wrong again!
That's one of the things I've never used - probably because it violates the principle of "simple and easy to understand".
A more useful result - as far as I'm concerned - for the example above would be to return a sequence {3,4}. IOW, found "rob" at both positions 3 and 4, counting from the right.
15. Re: [OE vs Phix] assigning atom to a slice is different
- Posted by katsmeow Feb 15, 2018
- 1200 views
Irv, yeas, it's a lil off-topic here, but all the search/find functions presume to start at the left. I've often thought it would save execution time if they could start from the right, if needed. And not just for languages such as Arabic. In a hdd directory listing, seems to me it would be faster to search from the right for "gpj." or "fdp." than look for it from the right. Even subscripting each seq to do
if seq(s) and (len(s)>4) and equal(".pdf",s[$-4..$]) then
smells slow. I have some code that uses reverse() a lot.