Micron Confidential
FYI
Micron Confidential
From: ibis-quality-bounce@xxxxxxxxxxxxx <ibis-quality-bounce@xxxxxxxxxxxxx> On
Behalf Of PARET Stefan
Sent: Wednesday, April 28, 2021 2:14 AM
To: ibis-quality@xxxxxxxxxxxxx
Subject: [EXT] [ibis-quality] Bug 216
CAUTION: EXTERNAL EMAIL. Do not click links or open attachments unless you
recognize the sender and were expecting this message.
Hi Mike.
I would like to comment on the discussion about bug 216.
1. In the C programming language, the numbers of type 'int' are *not* a
subset of the numbers of type 'float'. The internal representation of these
number types in computers differ fundamentally. The analogy with integer and
floating numbers in the mathematical sense (where the former are a subset of
the latter) is not valid.
2. The assignment of an int type to a float type, like 'float x = 1;', is
valid because C performs an implicit type conversion. Implicit conversion means
that '1' is converted to '1.' before the value is assigned to x (without any
explicit conversion directive).
3. If the int type is removed from the specification, a strict
interpretation would imply that the IBIS checker should reject int numbers.
4. Rejecting the import of int numbers where float numbers are expected
would require the implementation of a type check for the imported data, which
needs to take place before any implicit type conversion can take place. From
the implementation's point of view allowing int where float is expected is the
easiest solution (thanks to the implicit type conversion).
5. One could of course decide to remove int from the spec but still tolerate
them in the IBIS checker. However, that would introduce a behavioral
discrepancy without any need.
In my opinion, removing the int type from the specification would yield more
trouble than it resolves. I don't see any harm in allowing int types and float
types where float types are supported (except for the additional words in the
spec).
Mit freundlichen Grüßen / Best Regards / Cordialement,
Stefan PARET
EMAG Circuits & Systems R&D Developer Manager
Office: +49 899 6094 8031
stefan.paret@xxxxxxx<mailto:Stefan.PARET@xxxxxxx>
[3DS Logo]
3DS.COM/SIMULIA<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.3ds.com%2FSIMULIA&data=04%7C01%7Crrwolff%40micron.com%7C881937a215d54b238b8808d90a1d93dc%7Cf38a5ecd28134862b11bac1d563c806f%7C0%7C0%7C637551944430975145%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aY2u7rPTqh7kWMCkofisouggQUu1sWx%2Fo9s9p5zvIr8%3D&reserved=0>
DS Deutschland GmbH | Joseph-Wild-Str. 20, Messe-Campus Riem | 81829 Munich |
Germany
Geschäftsführer (Managing Directors): Dominic Kurtaz, Dr. Christian Speth.
Vorsitzender des Aufsichtsrates (Chairman of the Supervisory Board): Olivier
Ribet
Handelsregister (Commercial Register): Amtsgericht Stuttgart HRB 262373
Umsatzsteuer (VAT) ID: DE 147 319 694
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email
and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or
responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data
privacy policy as described on our website. Should you have any questions
related to personal data protection, please contact 3DS Data Protection Officer
at 3DS.compliance-privacy@xxxxxxx<mailto:3DS.compliance-privacy@xxxxxxx>
For other languages, go to https://www.3ds.com/terms/email-disclaimer