I've always been using the -fdefault-real-8 option of gfortran to automatically promote every single REAL declared anywhere in the program to double precision, along with any constant, e.g. 1.23. If I ever wanted to switch back to single precision, I only had to remove that option and recompile, without changing a single character in the source code.
At a point I started using ISO_FORTRAN_ENV module, since it allows me to use constants like INPUT|OUTPUT|ERROR_UNIT, as well as IOSTAT_END and IOSTAT_EOR and others (which seemed to be a good and easy move in the direction of portability, am I wrong?). From then on, I've been seeing and ignoring the following warning
Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-real-8
since such incompatibility seems to have no effect so far.
Now I'd like to get rid of this warning if it is possible and worth it.
If I correctly understood, to avoid this warning I should give up on -fdefault-real-8 option and change every REAL to REAL(real64) and/or to REAL(dp) (provided that, in the latter case, the statement USE, INTRINSIC :: ISO_FORTRAN_ENV, dp => real64 is put in that unit), which is not a difficult task for sed or vim.
Nevertheless, it seems to me that this change wouldn't be the same as using -fdefault-real-8 option, since all constants would stay single precision as long as I don't add d0 to them.
Assumed the -fdefault-real-8 option is removed and ISO_FORTRAN_ENV is used anywhere, is there any way to make any constant across the program behave as each had d0 suffix?
Whether or not this is possible, have I correctly extrapolated that I can put the following lines in a single module which is used by all others program units, each of which can then use dp as kind type parameter?
USE, INTRINSIC :: ISO_FORTRAN_ENV
INTEGER, PARAMETER :: dp = real64
I would prefer this way since I could switch to real32 or real128 or whatever by changing only that line.
If you just want to silence the warning and you do not care about the implications -fdefault-real-8 has on storage association and some Fortran standard requirements, just do not import NUMERIC_STORAGE_SIZE from the module. For example,
USE, INTRINSIC :: ISO_FORTRAN_ENV, only: INPUT_UNIT,OUTPUT_UNIT,ERROR_UNIT
Assumed the -fdefault-real-8 option is removed and ISO_FORTRAN_ENV is used anywhere, is there any way to make any constant across the program behave as each had d0 suffix?
No.
By the way, d0 is exactly the same as double precision, so that doesn't fixate much either, since the meaning of double precision is allowed to vary as much as real.
Whether or not this is possible, have I correctly extrapolated that I can put the following lines in a single module which is used by all others program units, each of which can then use dp as kind type parameter?
Yes. That is a common practice.
Related
If I want to see what an image format can be used for I can do the vkGetPhysicalDeviceImageFormatProperties2() and set the usage flag for the image format. I've noticed if the format isn't supported for those usages and settings the structure I pass in is set to all zero, and I can know if the format supports those uses. So if I want to know if VK_FORMAT_R8G8B8_UINT supports sampling from a shader I set the VK_IMAGE_USAGE_SAMPLED_BIT in the usage flags and call that function.
What I wanted to know is if that's equivalent to calling another function, called vkGetPhysicalDeviceFormatProperties2(), exactly the same name but without 'image' in the name, give that function the format, and check whether the VK_IMAGE_USAGE_SAMPLED_BIT is set.
So using the first method I give the format and usages I want from it, and then check if the values returned are zero max width, max height, etc, meaning those usages aren't supported, versus the second method of passing the format, getting back the flags and then checking the flags.
Are these two methods equivalent?
TL;DR: Do your image format checking properly: ask how you can use the format, then ask what functionality is available from usable format&usage combinations.
If you call vkGetPhysicalDeviceImageFormatProperties2 with usage flags and the like that don't correspond to a supported image type, you get an error: VK_ERROR_FORMAT_NOT_SUPPORTED. It inherits this due to the fact that it is said to "behave similarly to vkGetPhysicalDeviceImageFormatProperties", which has an explicit statement about this error:
If format is not a supported image format, or if the combination of format, type, tiling, usage, and flags is not supported for images, then vkGetPhysicalDeviceImageFormatProperties returns VK_ERROR_FORMAT_NOT_SUPPORTED.
Now normally, a function which gives rise to an error will yield undefined values in any return values. But there is a weird exception:
If the combination of parameters to vkGetPhysicalDeviceImageFormatProperties2 is not supported by the implementation for use in vkCreateImage, then all members of imageFormatProperties will be filled with zero.
However, there's an explicit note saying that this was old, bad behavior and is only preserved for compatibility's sake. Being a compatibility feature means that you can rely on it, but you shouldn't. Also, it only applies to the imageFormatProperties data and not any of the extension structures you can pass.
So it's best to just ignore this and ask your questions in the right order.
I want to integrate the function shown in the graphic that in turn has several functional dependencies as indicated. Is there a way to define the sub-functions $F(x)$, $G(x)$, $H(x)$ , and $p(x)$ in the input without explicitly writing everything out in one line which would be a hideous mess? All of the other symbols except of course, $x$ are constants.
(I doubt that there's a closed form expression, but I don't want it to be for lack of trying!)
I know that by using 0:3 in this code in Pascal will put 3 decimal places to the result
var a,b:real;
begin
a:=23;
b:=7;
writeln(a/b:0:3);
readln;
end.
What I would like to know is if anyone has a source to learn what this : will do with other variables or if adding for example 0:3:4 will make a difference. Basically what : can do to a variable
For the exact definition of write parameters take a look at ISO standards 7185 and 10206, “Standard Pascal” and “Extended Pascal” respectively. These references are useless though if your compiler’s documentation does not make a statement regarding compliance with them. Other compilers have their own non-standard extensions, so the only reliable source of reference is your compiler’s documentation or even its source code if available.
[…] what this : will do with other variables […] Basically what : can do to a variable
As MartynA already noted this language is imprecise: The variables’ values are only read by write/writeLn/writeStr, thus leaving them unmodified.
[…] if adding for example 0:3:4 will make a difference.
To my knowledge a third write parameter is/was only allowed in PXSC, Pascal eXtensions for Scientific Computing. In this case the third parameter would indicate for the rounding mode (nonexistent or 0: closest printable number; greater than zero: round up; less than zero: round down).
Is it legal to use variables in printf without supplying the formatting (such as %d, %f).
for example:
printf("value is ok\r\n",myvalue);
The command compiles without errors nor warning, though I am not absolutely sure if it is legal or dangerous.
This reference says
There should be at least as many of these arguments as the number of values specified in the format specifiers. Additional arguments are ignored by the function.
Base on this information, your statement is perfectly legal, however I don't thinks that this is a good idea, since you code could quickly become confusing, which might lead to bugs.
Edit: The original source does not explicitly mention the case of zero arguments. To add another source, the linux man pages states
The format string is composed of zero or more directives.
This source does not discuss what happens with additional arguments. However, combining these two sources gives a definitive answer.
Howcome some languages like PHP and Python use dynamic name resolution?
The only time I've ever thought of using it is to do something like this Python code, to save me from having to explicitly parameters to format:
"{a} {b} {c} {d}".format(**locals())
but it doesn't really take much work to just be explicit (and is a bit less error-prone):
"{a} {b} {c} {d}".format(a=a, b=b, c=c, d=d)
And for setting/getting locals in the same scope, I don't see why anyone would ever use that instead of a map.
Without dynamic name resolution, typos are caught, and you can automatically rename variables without breaking your program (unless something can still read the names of the variables). With dynamic name resolution, you get something that saves you from typing a line? Am I missing something?
Python documentation says they might remove it in the future. Is it more of a historical thing? What's an actual good use case for dynamic name resolution?
Most dynamically typed languages simply don't have a choice. For an expression like x.y you can't look up y statically, since what fields are available depends on the type of x which is only available at runtime.
There are ways around this (such as type inference or JIT), but since the base language has to have dynamic name lookup, most such languages make it into a feature (see e.g. the power of Lua tables).