• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

Bo
27-Jun-2013
[8877]
OK.  Next enigma about Red/System that I ran into.  Consider the 
two following sets of code and output.  Why are they different?

Code 1:
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

 print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

Output 1:
...
96
99
107
111
105
104
100
99
100
98

Code 2:
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))
	print-line im1

Output 2:
...
4260192
4260451
4260203
4260207
4259945
4259944
4259940
4260451
4260196
4260194
Kaj
27-Jun-2013
[8878]
The example is not complete. How do you get more than one value?
Bo
27-Jun-2013
[8879x3]
This is a loop that processes raw binary image data.  'r, 'g, and 
'b are incremented through an 'until loop until the data is all consumed.
But what is troubling to me is that

print-line im1

is not equal to


print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))
They should be equivalent.
Kaj
27-Jun-2013
[8882x2]
It could be a Red/System bug, or it could be a result of the code 
you're not showing. Can't tell
Are you doing this on the Raspberry? Doc recently made fixes to the 
ARM code emitter. It was less mature than the x86 emitter
Bo
27-Jun-2013
[8884x2]
I am running this on Windows currently.  XP 32-bit.  Here's the complete 
code:

#include #../C-library/ANSI.reds

img1: as-binary 0
size1: 0

img1: read-file-binary "img1.bin" :size1

i: 0
r: 0
g: 0
b: 0
im1: 0
until [
	r: i + 2
	g: i + 3
	b: i + 4
	im1: as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

 print-line im1 ;as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b 
 / 3))
	i: i + 4
	i >= size1
]
If I change the line


 print-line im1 ;as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b 
 / 3))

to


 print-line as-integer ((img1/r / 3) + (img1/g / 3) + (img1/b / 3))

I get the expected output.
PeterWood
27-Jun-2013
[8886x2]
It could be caused by differences in the auto-casting between a simple 
assignment and a call to print-line.

Being conservative I would have written:


im1: (((as integer img1/r ) / 3) + (as integer img1/g) / 3) + (as 
integer img1/b) / 3)
plus one more ) at the end :-)
Bo
27-Jun-2013
[8888x3]
I already tried that and got an error from the compiler saying that 
there was an unnecessary cast from integer to integer.
*** Warning: type casting from integer! to integer! is not necessary
It would then exit.
PeterWood
27-Jun-2013
[8891]
What type is img1/r ?
Bo
27-Jun-2013
[8892x2]
img1 is binary (or byte!) I suppose.
img1 is a pointer to an array of those bytes, I should have said.
Kaj
27-Jun-2013
[8894]
The addition can't result in more than a byte, so it should be no 
problem to do it with bytes
Bo
27-Jun-2013
[8895]
I just can't see how the output I'm seeing is not a bug.  I was hoping 
you could explain it.
PeterWood
27-Jun-2013
[8896]
But it seems as the compiler thinks that img/r is an integer!
Kaj
27-Jun-2013
[8897]
Yes, it looks like a bug
Bo
27-Jun-2013
[8898x3]
Agreed.
Could it be a problem that I'm type casting im1 to an integer in 
the line

	im: 0

??
Forget it, that can't be the problem.
Kaj
27-Jun-2013
[8901]
That's not a cast, just an assignment
Bo
27-Jun-2013
[8902]
I thought maybe the type was cast by the value you assigned to it.
Kaj
27-Jun-2013
[8903]
Declared, but not cast, because it wasn't known yet
Bo
27-Jun-2013
[8904]
The problem I'm trying to solve is to convert two seperate images 
to grayscale and then compare the pixels in each image to each other 
to look for big variations in contrast between the pixels.
Kaj
27-Jun-2013
[8905]
You did upgrade your Red/System, didn't you?
Bo
27-Jun-2013
[8906x2]
If I can't assign the answer of a calculation to a word and then 
use that word in other calculations, then it's a roadblock that I'm 
not sure how to overcome.
Yes, I updated Red/System yesterday from Github.
Kaj
27-Jun-2013
[8908x2]
I found many such bugs in the past, so I would like to think they're 
gone, but it looks like you found another :-)
Doc doesn't do many byte manipulations, so it's up to us to test 
them
Bo
27-Jun-2013
[8910]
OK.  Curecode doesn't work for me for some reason, so how do I submit 
this bug?
Kaj
27-Jun-2013
[8911]
Red is not in Curecode. The tracker is on GitHub
Bo
27-Jun-2013
[8912]
OK. I'll enter it there.
PeterWood
27-Jun-2013
[8913x3]
The calculation is okay.

Code:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + (as integer! green) + (as integer! 
blue)

print [greyscale lf]

OUTPUT:
-= Red/System Compiler =- 
Compiling /Users/peter/VMShare/Code/Red-System/test.reds ...
Script: "Red/System IA-32 code emitter" (none)
Script: "Red/System Mach-O format emitter" (none)

...compilation time:     122 ms
...linking time:         10 ms
...output file size:     16384 bytes
...output file name:     builds/test
260
It may be an issue with the dereferencing.

Could you try by assigning img1/r etc to temporary variables.
Oops, here's the proper code and correct answer:

Red/System []

red: as byte! 240
green: as byte! 120
blue: as byte!  60


greyscale: ((as integer! red) / 3) + ((as integer! green) / 3) + 
((as integer! blue) / 3)

print [greyscale lf]

OUTPUT
...compilation time:     133 ms
...linking time:         13 ms
...output file size:     16384 bytes
...output file name:     builds/test
140
Kaj
27-Jun-2013
[8916x2]
Your immediate problem should be solved if you do
im1: as-byte 0
Bo
27-Jun-2013
[8918x3]
Well, that seems to have worked around the problem!  Thanks guys!
Now I can work on making some real progress! :-)
I'm amazed by how fast Red/System is.
PeterWood
27-Jun-2013
[8921]
Excellent !
Kaj
27-Jun-2013
[8922]
Your code could be optimised a bit :-)
james_nak
27-Jun-2013
[8923]
Kaj, I think there was something to the jarsigner being commented 
out in the file. I'll have to wait for Doc and Pekr to chime in.
Kaj
27-Jun-2013
[8924]
Yes
Bo
27-Jun-2013
[8925]
I'd love to learn how to optimize my code!
Kaj
27-Jun-2013
[8926]
Are you low on memory?