I'm quite new to Mac and XCode and now I have a trivial but weird problem.
I'm calling Izero(2.12), you can see the value of the input argument here, while b contains a random value from memory since it has not been initialized yet.
after x*x is executed and a value is assigned to b, b is corrupted!
Please also notice that there's
long double xsqr = 0;
xsqr = x * x;
if I set 0 to xsqr first and then assign x*x to it, xsqr will get the correct value.
I'm running on Mac OS X 10.7.5 and Xcode 3.2.5, could anyone help to have it solved?
Should you have optimization enabled, the compiler possibly doesn't care to generate code that puts something sensible in b, since b isn't used in the rest of function Izero().
Related
For context: I think I pressed something wrong while writing a command, but didn't pay much attention, then I noticed that if I went back with the up-arrow key, and then used the down-arrow key, the previous commands where concatenated:
(It may be important to note that this only happens using GHCi --Glasgow Haskell Compiler interactive environment)
% ghci
GHCi, version 8.10.7: https://www.haskell.org/ghc/ :? for help
Prelude> x = 2
Prelude> y = 2
Prelude> x + y
4
Prelude> x + y = x = y = x +
The last line was "written" using only the arrow keys, after using them a few times, they can't be deleted, but if I actually write something after it, the previous commands are ignored:
for reference:
{} - concatenated unintentionally with arrow keys
[] - written by me
Prelude> {x + y = x} [2 + 2]
4
^the above, if written only by me, without using arrow keys, would've thrown an error.
Any help is greatly appreciated.
It turns that, quoting a member from the Function Programming Discord, "it's a known issue with haskeline (the library GHCi) uses that been fixed but needs to be back ported into GHC itself"
A workaround suggested by the same person is running TERM=dumb ghci
I am running a model which is written in Fortan (an executable), in some runs it started to deliver constant errors and apparently incoherent results, however when I closely checked the results file (a text with n columns of data) and I realized that when the concentration of certain mineral is very very low, lets say 2.9984199E-306, the code omits the 'E' and the number presented is 2.9984199-306 which of course causes problems. Since I have no access to the source code of the executable file, is there a way to avoid this problem in Windows? I have seen that in other computers these numbers are directly replaced by zero, however I was not able to find the specific configuration to achieve it.
You will need access to code to change the output formatting or you will need to post-process your output. You are seeing standard conforming Fortran behavior. Consider the simple program
program foo
implicit none
real(8) x
integer i
x = 1
do i = 1, 10
x = x / 5.4321e11
write(*,'(ES15.7)') x
end do
end program foo
It's output is
1.8409086E-12
3.3889446E-24
6.2387373E-36
1.1484945E-47
2.1142735E-59
3.8921843E-71
7.1651557E-83
1.3190397E-94
2.4282316-106
4.4701525-118
See Fortran 2018 Standard, 13.7.2.3.3 E and D editing, in particular, Table 13.1.
I've searched on this, and everyone seems to say Ruby always passes by value, but this simple little example is a subset of a much larger program, and I'm a little confused.
a = "J123"
b = a
a.slice!(0)
puts a
puts b
This displays
123
123
And I don't understand why the value of "b" is changing.
Because both a and b are pointers that refer to the same object. They aren't the object itself. You can only pass pointers as arguments in Ruby, and pointers are passed by value.
This is similar to Java, JavaScript and Python, and unlike C++, C#, Haskell and Scala.
The difference is of interest in the following example:
def f(y)
y = 2
end
x = 1
f(x)
puts x # 1, not 2
If x were passed by reference, it would print 2.
It is pass by value. Everything in ruby is an object. Meaning all variables are actually references(pointers) to that item somewhere in memory.
x = 5 # (5 is stored as object in mem location 0x0001)
y = x # (now y also points to mem location 0x0001)
When you pass your variable into a function and it copies that variable by value - it is copying the memory location address, not the actual object at that memory location.
In your example, both a and b's values (memory locations) were copied by value. However they point to the same memory location, so modifying that location in memory through one variable still modifies the value of the other.
EDIT:
There is a great write-up here (for Java which is also pass-by-value), about how to test whether a language truly supports pass-by-reference.
When I compile the following Fortran code with gfortran and run it, it gives me 'signal SIGBUS: Access to undefined portion of a memory object', whenever n>=180. I'm running this on a Mac OSX Mavericks.
PROGRAM almatrix
IMPLICIT NONE
INTEGER :: i,j,n
REAL,ALLOCATABLE :: a(:,:)
READ(*,*)n
ALLOCATE(a(n+1,n+1))
DO i=0,n
DO j=0,n
a(i,j)=0.0
END DO
END DO
DEALLOCATE(a)
END PROGRAM almatrix
I understood that instead of
ALLOCATE(a(n+1,n+1))
this
ALLOCATE(a(n+1,n+1),STAT=err)
IF(err /= 0) STOP
would prevent crashing. It didn't, however. Why?
I tried to look at similar problems, but so far they haven't helped.
I tried to compile with -Wall, -g, -fcheck=all, as suggested in another answer, but those didn't give me warnings.
I've also noticed before, that unlike with C, Fortran usually does not give bus errors when using small dynamic arrays and not deallocating them.
The problem isn't directly with the allocate statement, but with accessing the resulting array. [Note also that that an array 181x181 is not "large".] As there is nothing wrong with the allocation, err will indeed be zero.
From that allocate one is left with an array a which has elements a(1,1), a(2,1), ..., a(n+1,1), ..., a(n+1,n+1). So, a(0,0) (the first access in the loop) is not valid.
There are two options: request that the array elements be a(0,0) to a(n,n) as the loop wants, or change the loop:
allocate(a(0:n,0:n))
or
do i=1,n+1
do j=1,n+1
a(j,i) = 0 ! Note I've changed the order to Fortran-friendly
end od
end do
Finally, those loops aren't even necessary:
allocate(a(0:n,0:n))
a = 0.
or even
allocate(a(0:n,0:n), source=0.)
if you have a compiler later than Fortran 95.
As the title says I'm curious about the difference between "call-by-reference" and "call-by-value-return". I've read about it in some literature, and tried to find additional information on the internet, but I've only found comparison of "call-by-value" and "call-by-reference".
I do understand the difference at memory level, but not at the "conceptual" level, between the two.
The called subroutine will have it's own copy of the actual parameter value to work with, but will, when it ends executing, copy the new local value (bound to the formal parameter) back to the actual parameter of the caller.
When is call-by-value-return actually to prefer above "call-by-reference"? Any example scenario? All I can see is that it takes extra memory and execution time due to the copying of values in the memory-cells.
As a side question, is "call-by-value-return" implemented in 'modern' languages?
Call-by-value-return, from Wikipedia:
This variant has gained attention in multiprocessing contexts and Remote procedure call: if a parameter to a function call is a reference that might be accessible by another thread of execution, its contents may be copied to a new reference that is not; when the function call returns, the updated contents of this new reference are copied back to the original reference ("restored").
So, in more practical terms, it's entirely possible that a variable is in some undesired state in the middle of the execution of a function. With parallel processing this is a problem, since you can attempt to access the variable while it has this value. Copying it to a temporary value avoids this problem.
As an example:
policeCount = 0
everyTimeSomeoneApproachesOrLeaves()
calculatePoliceCount(policeCount)
calculatePoliceCount(count)
count = 0
for each police official
count++
goAboutMyDay()
if policeCount == 0
doSomethingIllegal()
else
doSomethingElse()
Assume everyTimeSomeoneApproachesOrLeaves and goAboutMyDay are executed in parallel.
So if you pass by reference, you could end up getting policeCount right after it was set to 0 in calculatePoliceCount, even if there are police officials around, then you'd end up doing something illegal and probably going to jail, or at least coughing up some money for a bribe. If you pass by value return, this won't happen.
Supported languages?
In my search, I found that Ada and Fortran support this. I don't know of others.
Suppose you have a call by reference function (in C++):
void foobar(int &x, int &y) {
while (y-->0) {
x++;
}
}
and you call it thusly:
int z = 5;
foobar(z, z);
It will never terminate, because x and y are the same reference, each time you decrement y, that is subsequently undone by the increment of x (since they are both really z under the hood).
By contrast using call-by-value-return (in rusty Fortran):
subroutine foobar(x,y):
integer, intent(inout) :: x,y
do while y > 0:
y = y - 1
x = x + 1
end do
end subroutine foobar
If you call this routine with the same variable:
integer, z = 5
call foobar(z,z)
it will still terminate, and at the end z will be changed have a value of either 10 or 0, depending on which result is applied first (I don't remember if a particular order is required and I can't find any quick answers to the question online).
Kindly go to the following link , the program in there can give u an practical idea regarding these two .
Difference between call-by-reference and call-by-value