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

World: r4wp

[#Red] Red language group

Kaj
29-Jul-2013
[9752x4]
That may indeed very well have been only about macro parameters
You could work around it:
i: MAX-SIZE
my-array/i
Arnold
29-Jul-2013
[9756x2]
Right but then I have a #define macro AND a variable. So I had better 
started of with the variable in this case.
But is really is a constant.
Kaj
30-Jul-2013
[9758]
Yes, it's imperfect
Arnold
30-Jul-2013
[9759]
That is why I created an issue for it #504.
DocKimbel
30-Jul-2013
[9760]
I'm finishing installing the tools I need and migrating all my data 
from old disks, I should be able to get back to full coding tonight....finally.
Kaj
30-Jul-2013
[9761]
Such things always take a lot of time
Arnold
30-Jul-2013
[9762x2]
I reached this:
C code:
hex value 2214165945 is=0x83f97db9

* 1664525 gives 32710463130033 plus j 0 and plus the init_key of 
value 291 
mt[i] 32710463130324 and(&) FFFFFFFFh results in mt[i] 4287171284
Red/Systemcode
-2080801351 which is also (to-hex -2080801351)
== #83F97DB9

multiplied by 1664525:: 1658067045 and then added also 291 and 1 
minus 1
state-array/i: 1658067336
(My) Conclusion the multiplication by 1664525 causes the results 
of the C source and Red/System source to diverge, possible reason 
calculation with long integers in C versus integer calculation in 
Red/System troubled by overflows.
Kaj
30-Jul-2013
[9764]
Is that on a 64 bit machine?
Arnold
30-Jul-2013
[9765x2]
It is my Macbook from 2008.
That is 64 bit but not the core or something, that is why it can't 
upgrade beyond Snow Leopard.
Kaj
30-Jul-2013
[9767x4]
It must be 64 bit, because a long on Mac would probably be 84 bit 
there. Indeed, your multiplication result is 64 bit, so on Red/System, 
it is wrapping around
64
However, the algorithm should also work on 32 bit, shouldn't it?
Or is it using long longs?
Arnold
30-Jul-2013
[9771]
Yes, there is a trick to AND with FFFFFFFFh to bring it back to 32 
bits, but harm to the resulting values has been done then.
Kaj
30-Jul-2013
[9772]
Not if the algorithm is meant to work on 32 bit
Arnold
30-Jul-2013
[9773]
I have no idea how to compile and run the C variant in 32 bit mode
Kaj
30-Jul-2013
[9774]
There would be some compiler option, -32 or something
Arnold
30-Jul-2013
[9775x2]
That was easy on XCode. Getting closer now. (still differences :( 
)
(changing target)
Kaj
30-Jul-2013
[9777]
Shooting rabbits now?
Arnold
30-Jul-2013
[9778x2]
pow pow pow!
all hits now :-)
Arnold
31-Jul-2013
[9780]
There were some more hooks and traps, in the end the same generated 
numbers! Now removing a real truckload of dumps and prints from the 
source.
Kaj
31-Jul-2013
[9781]
So does the C program produce different results in 32 and 64 bit 
versions?
Arnold
31-Jul-2013
[9782]
That is what I concluded Tue 9:52. Still stands.
Kaj
31-Jul-2013
[9783x2]
That's very strange for such an algorithm
Is the code supposed to support 64 bit?
Arnold
31-Jul-2013
[9785x2]
After current test, I conclude otherwise :) Output is the same. Output 
in C source is unsigned, output in R/S is signed.
C: 10 outputs of genrand_int32()
1067595299  955945823  477289528 4107218783 4228976476 
3344332714 3355579695  227628506  810200273 2591290167 
R/S:--- Test 3 10 outputs of genrand-int32 ---
--------------------------------------------
1067595299 955945823 477289528 -187748513 -65990820 
-950634582 -939387601 227628506 810200273 -1703677129 
----------------------------------

(Where the negative values are bitwise equal to their unsigned counterpart 
in the C output.)
I was mislead by an incorrect intermediate result in the Red/System 
source that I expected to be correct already but had not fixed on 
this machine, together with a short blackout overseeing that adding 
nonzerobits to the left of a binary number changes the decimal representation 
in the lower digits too. Lots of output lines, many output terminal 
windows, small laptopscreen.
Same results make sense.
Kaj
31-Jul-2013
[9787]
Syncing problems? Better use Fossil :-)
Bo
31-Jul-2013
[9788]
Kaj made a big breakthrough today on the commercial project we are 
using Red to develop.  That means we are close to getting paid.  
In turn, that means that Doc is close to getting as big a donation 
as we can afford for creating Red and helping us develop the functionality 
we needed in Red.  And if we can successfully market the product, 
Doc will be getting a donation for each one sold.  We are doing a 
presentation of the product on August 19th to people in the Computer-Aided 
Design industry toward that goal.
DocKimbel
31-Jul-2013
[9789]
Wow, congrats to both of you! :-)
amacleod
31-Jul-2013
[9790]
Great
Kaj
31-Jul-2013
[9791]
I'll note that the breakthrough was facilitated by the environment 
set up for me by Bo. It would have been hard to do it without that
Arnold
31-Jul-2013
[9792x2]
SUperprogress guys!
I'll wait for the fossil tutorial video ;-)
Kaj
31-Jul-2013
[9794x3]
https://www.youtube.com/watch?v=ClJ5lwl_wM0
https://www.youtube.com/watch?v=hmJ4ulhZtoQ
https://www.youtube.com/watch?v=53d4txkdeq8
Geomol
31-Jul-2013
[9797]
Congratulations! Good to hear, that these projects are used for something 
real.
Arnold
31-Jul-2013
[9798]
1st video nice song and clip.

2nd video Lizzen vewy cawefully, Eye willl zay zhis oonly whonze... 
is distracting me, trying to watch that tomorrow again
3rd video demo? Demo of the symbolic view in Mac finder :)
Bo
31-Jul-2013
[9799]
Fortunately, Respectech has several cloud servers.  I had my system 
administrator create a couple of Windows 8 x64 virtual machines so 
we could simulate a Windows network environment with Solidworks.
Pekr
1-Aug-2013
[9800]
guys, is your project the surveilance camera related, or a newe stuff? 
As for the breakthrough - some kind of optimisation, or some important 
functionality, etc?
Kaj
1-Aug-2013
[9801]
A new project. The breakthrough is the coming together of the key 
functionality that is the identity of the product