The actual bit size depends on the computer architecture you are compiling your program for
is there any option to assigning size of a floating point variable based on the computer architecture the sizes are equal to f32 bits on 32-bit platforms and f64 bits on 64-bit platforms.
like in { usize or isize } which are Primitive Data Types. if there exist no such feature adding this type of feature will be a advantage for rust language or is language face an problem if such a feature in added as a Primitive Data Types
You can do
#[cfg(target_pointer_width = "64")]
type Float = f64;
#[cfg(target_pointer_width = "32")]
type Float = f32;
it should defined based on based on computer architecture
consider that i write a rust library in f64 or a library related to some maths or physics computing and the user is using 32 bit based computer if that person use that lib it will result to error in this case he/she can use type casting but it affect it precision and accuracy
or while make the lib i can use generic function which make lib little complicated.
is their any other solution for this problem
AFAIK, most 32-bit architectures do have native support for 64-bit floats, so what is the reason you want to restrict this? If your program is OK with the limited accuracy of f32, then you'd probably benefit from scaling back to that everywhere.
There are many platforms out there that don't have floating point hardware. Think micro-controllers.
One might want to use floats there but it would have to be done in software. Presumably 32 bit floats are a lot faster than 64 bit floats in that world.
In that case, I'd make it conditional on having hard/soft floats, not target pointer size.
consider a new feature in rust language in your imagination
let num:fsize =
3.141592653589793238462643383279502884197169399375105820974944592307816406286 208998628034825342117067982148086513282306647093844609550582231725359408128481 117450284102701938521105559644622948954930381964428810975665933446128475648233 786783165271201909145648566923460348610454326648213393607260249141273724587006 606315588174881520920962829254091715364367892590360011330530548820466521384146 951941511609433057270365759591953092186117381932611793105118548074462379962749 567351885752724891227938183011949129833673362440656643086021394946395224737190 702179860943702770539217176293176752384674818467669405132000568127145263560827 785771342757789609173637178721468440901224953430146549585371050792279689258923 542019956112129021960864034418159813629774771309960518707211349999998372978049 951059731732816096318595024459455346908302642522308253344685035261931188171010 003137838752886587533208381420617177669147303598253490428755468731159562863882 353787593751957781857780532171226806613001927876611195909216420198938095257201 065485863278865936153381827968230301952035301852968995773622599413891249721775 283479131515574857242454150695950829533116861727855889075098381754637464939319 255060400927701671139009848824012858361603563707660104710181942955596198946767 837449448255379774726847104047534646208046684259069491293313677028989152104752 162056966024058038150193511253382430035587640247496473263914199272604269922796 782354781636009341721641219924586315030286182974555706749838505494588586926995;
depends on platform it choose f32 or f64 or in far future f128 if 128 bit harware become common
depends on hardware it take value after . according to capacity of computer
also consider scientific computing in your imagination.
The question is, why do you want floats that are tied to the target pointer size? Common 32-bit architectures like i686 have hardware support for both 32-bit and 64-bit floats. (The same is true for common 64-bit architectures.)
Choosing a floating point width involves various trade-offs, but is usually not related to the pointer width.
In most computer architectures you can't choose a memory address width; it's defined for you by the hardware. Whatever width that is, it's the correct size for address and full-memory indexing operations and computations on that hardware. That's why Rust provides signed and unsigned integer types (usize and isize) corresponding to the computational needs of target hardware.
Choice of floating-point width in a program is often based on algorithmic requirements, such as stability or convergence of an algorithm, as well as on storage size of large arrays, rather than on constraints of the underlying hardware. That's why there are multi-precision packages that provide greater precision in software, for use when the hardware-provided width is insufficient. (Software floating point can be considered to be an instance of that approach where the hardware-provided floating-point width is zero.)
There is never a need for multiple widths of usize and isize for a single hardware target. Conversely, a single hardware target often supports multiple floating-point widths at the same time. For example, a conforming RISC-V CPU might support use of FP16, FP32, FP64 and FP128 all in the same program.
so you are saying that f64 is supported in 32 bit operating system
Usually. In some very low-end machines there might be f32 and not f64, but that was much more common 15 years ago than it is now. Even most software floating-point packages for very low-end hardware often provide f64 so that they can support algorithms that can't afford the cumulative precision loss of a long computation in f32.
Yes, exactly.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.